1NETWORK WORKING GROUP N. Williams 2Internet-Draft Sun 3Expires: December 30, 2004 S. Hartman 4 MIT 5 July 2004 6 7 8 9 A PRF for the Kerberos V GSS-API Mechanism 10 draft-williams-krb5-gssapi-prf-00.txt 11 12 13Status of this Memo 14 15 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 20 21 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 26 27 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 32 33 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 36 37 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 40 41 42 This Internet-Draft will expire on December 30, 2004. 43 44 45Copyright Notice 46 47 48 Copyright (C) The Internet Society (2004). All Rights Reserved. 49 50 51Abstract 52 53 54 This document defines the Pseudo-Random Function (PRF) for the 55 Kerberos V GSS-API mechanism, based on the PRF defined for the 56 Kerberos V cryptographic framework, for keying application protocols 57 given an established Kerberos V GSS-API security context. 58 59 60 61 62 63 64 65 66Williams & Hartman Expires December 30, 2004 [Page 1] 67Internet-Draft A PRF for the Kerberos V Mech July 2004 68 69 70 71Table of Contents 72 73 74 1. Conventions used in this document . . . . . . . . . . . . . . . 3 75 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 77 4. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 79 Intellectual Property and Copyright Statements . . . . . . . . . 6 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124Williams & Hartman Expires December 30, 2004 [Page 2] 125Internet-Draft A PRF for the Kerberos V Mech July 2004 126 127 128 1291. Conventions used in this document 130 131 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182Williams & Hartman Expires December 30, 2004 [Page 3] 183Internet-Draft A PRF for the Kerberos V Mech July 2004 184 185 186 1872. Introduction 188 189 190 The GSS-API PRF function for the Kerberos V mechanism shall be the 191 output of the enctype's PRF function keyed with the negotiated 192 session key of the security context (e.g., the acceptor's subkey) and 193 key usage X (TBD). 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240Williams & Hartman Expires December 30, 2004 [Page 4] 241Internet-Draft A PRF for the Kerberos V Mech July 2004 242 243 244 2453. Security Considerations 246 247 248 Kerberos V enctypes' PRF functions should use a key derived from 249 contexts' session keys and should preserve the forward security 250 properties of the mechanisms' key exchanges. 251 252 253 Care should be taken in properly designing a mechanism's PRF 254 function. Cryptographic hash functions which do not provide strong 255 collision resistance should not be used, except through HMAC. 256 257 2584 Normative 259 260 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 264 265 [RFC2743] Linn, J., "Generic Security Service Application Program 266 Interface Version 2, Update 1", RFC 2743, January 2000. 267 268 269 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 270 C-bindings", RFC 2744, January 2000. 271 272 273 274Authors' Addresses 275 276 277 Nicolas Williams 278 Sun Microsystems 279 5300 Riata Trace Ct 280 Austin, TX 78727 281 US 282 283 284 EMail: Nicolas.Williams@sun.com 285 286 287 288 Sam Hartman 289 Massachussets Institute of Technology 290 ... 291 ..., MA ... 292 US 293 294 295 EMail: hartmans@mit.edu 296 297 298 299 300 301 302 303 304 305 306 307 308Williams & Hartman Expires December 30, 2004 [Page 5] 309Internet-Draft A PRF for the Kerberos V Mech July 2004 310 311 312 313Intellectual Property Statement 314 315 316 The IETF takes no position regarding the validity or scope of any 317 Intellectual Property Rights or other rights that might be claimed to 318 pertain to the implementation or use of the technology described in 319 this document or the extent to which any license under such rights 320 might or might not be available; nor does it represent that it has 321 made any independent effort to identify any such rights. Information 322 on the procedures with respect to rights in RFC documents can be 323 found in BCP 78 and BCP 79. 324 325 326 Copies of IPR disclosures made to the IETF Secretariat and any 327 assurances of licenses to be made available, or the result of an 328 attempt made to obtain a general license or permission for the use of 329 such proprietary rights by implementers or users of this 330 specification can be obtained from the IETF on-line IPR repository at 331 http://www.ietf.org/ipr. 332 333 334 The IETF invites any interested party to bring to its attention any 335 copyrights, patents or patent applications, or other proprietary 336 rights that may cover technology that may be required to implement 337 this standard. Please address the information to the IETF at 338 ietf-ipr@ietf.org. 339 340 341 342Disclaimer of Validity 343 344 345 This document and the information contained herein are provided on an 346 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 347 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 348 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 349 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 350 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 351 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 352 353 354 355Copyright Statement 356 357 358 Copyright (C) The Internet Society (2004). This document is subject 359 to the rights, licenses and restrictions contained in BCP 78, and 360 except as set forth therein, the authors retain all their rights. 361 362 363 364Acknowledgment 365 366 367 Funding for the RFC Editor function is currently provided by the 368 Internet Society. 369 370 371 372 373Williams & Hartman Expires December 30, 2004 [Page 6]