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 API extension for the GSS-API 10 draft-williams-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 a Pseudo-Random Function (PRF) extension to the 55 GSS-API for keying application protocols given an established GSS-API 56 security context. 57 58 59 60 61 62 63 64 65 66Williams & Hartman Expires December 30, 2004 [Page 1] 67Internet-Draft A PRF Extension for the GSS-API July 2004 68 69 70 71Table of Contents 72 73 74 1. Conventions used in this document . . . . . . . . . . . . . . 3 75 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. GSS_Pseudo_random() . . . . . . . . . . . . . . . . . . . . . 5 77 3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 79 5. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 81 Intellectual Property and Copyright Statements . . . . . . . . 8 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 Extension for the GSS-API 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 Extension for the GSS-API July 2004 184 185 186 1872. Introduction 188 189 190 A need has arisen for users of the GSS-API to key applications' 191 cryptographic protocols using established GSS-API security contexts. 192 Such applications can use the GSS-API for authentication, but not for 193 transport security (for whatever reasons), and since the GSS-API does 194 not provide a method for obtaining keying material from established 195 security contexts such applications cannot make effective use of the 196 GSS-API. 197 198 199 To address this need we define a PRF extension to the GSS-API. 200 201 202 At this point EAP may be the primary consumer of this extension. 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 240 241 242Williams & Hartman Expires December 30, 2004 [Page 4] 243Internet-Draft A PRF Extension for the GSS-API July 2004 244 245 246 2473. GSS_Pseudo_random() 248 249 250 Inputs: 251 252 253 o context CONTEXT handle, 254 o prf_in OCTET STRING 255 256 257 Outputs: 258 259 260 o major_status INTEGER, 261 o minor_status INTEGER, 262 o prf_out OCTET STRING 263 264 265 Return major_status codes: 266 o GSS_S_COMPLETE indicates no error. 267 o GSS_S_NO_CONTEXT indicates that a null context has been provided 268 as input. 269 o GSS_S_CONTEXT_EXPIRED indicates that an expired context has been 270 provided as input. 271 o GSS_S_FAILURE indicates failure or lack of support; the minor 272 status code may provide additional information. 273 274 275 This function applies the context's mechanism's keyed PRF function to 276 the input data (prf_in), keyed with key material associated with the 277 given security context and outputs the result (prf_out). 278 279 2803.1 C-Bindings 281 282 283 OM_uint32 gss_pseudo_random( 284 OM_uint32 *minor_status, 285 gss_ctx_id_t context, 286 const gss_buffer_t prf_in, 287 gss_buffer_t prf_out 288 ); 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307Williams & Hartman Expires December 30, 2004 [Page 5] 308Internet-Draft A PRF Extension for the GSS-API July 2004 309 310 311 3124. Security Considerations 313 314 315 GSS mechanisms' PRF functions should use a key derived from contexts' 316 session keys and should preserve the forward security properties of 317 the mechanisms' key exchanges. 318 319 320 Care should be taken in properly designing a mechanism's PRF 321 function. Cryptographic hash functions which do not provide strong 322 collision resistance should not be used, except through HMAC. 323 324 325 GSS mechanisms' PRF functions may output fewer octets than the 326 application may need, therefore GSS-API applications that use 327 GSS_Pseudo_random() may require a "PRF+" construction based on 328 GSS_Pseudo_random(). 329 330 331 [Question: Should GSS_Pseudo_random() have an input roughly 332 corresponding to the "key usage" used for key derivation in Kerberos 333 V?] 334 335 3365 Normative 337 338 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 342 343 [RFC2743] Linn, J., "Generic Security Service Application Program 344 Interface Version 2, Update 1", RFC 2743, January 2000. 345 346 347 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 348 C-bindings", RFC 2744, January 2000. 349 350 351 352Authors' Addresses 353 354 355 Nicolas Williams 356 Sun Microsystems 357 5300 Riata Trace Ct 358 Austin, TX 78727 359 US 360 361 362 EMail: Nicolas.Williams@sun.com 363 364 365 366 Sam Hartman 367 Massachussets Institute of Technology 368 ... 369 ..., MA ... 370 US 371 372 373 374 375 376Williams & Hartman Expires December 30, 2004 [Page 6] 377Internet-Draft A PRF Extension for the GSS-API July 2004 378 379 380 381 EMail: hartmans@mit.edu 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433Williams & Hartman Expires December 30, 2004 [Page 7] 434Internet-Draft A PRF Extension for the GSS-API July 2004 435 436 437 438Intellectual Property Statement 439 440 441 The IETF takes no position regarding the validity or scope of any 442 Intellectual Property Rights or other rights that might be claimed to 443 pertain to the implementation or use of the technology described in 444 this document or the extent to which any license under such rights 445 might or might not be available; nor does it represent that it has 446 made any independent effort to identify any such rights. Information 447 on the procedures with respect to rights in RFC documents can be 448 found in BCP 78 and BCP 79. 449 450 451 Copies of IPR disclosures made to the IETF Secretariat and any 452 assurances of licenses to be made available, or the result of an 453 attempt made to obtain a general license or permission for the use of 454 such proprietary rights by implementers or users of this 455 specification can be obtained from the IETF on-line IPR repository at 456 http://www.ietf.org/ipr. 457 458 459 The IETF invites any interested party to bring to its attention any 460 copyrights, patents or patent applications, or other proprietary 461 rights that may cover technology that may be required to implement 462 this standard. Please address the information to the IETF at 463 ietf-ipr@ietf.org. 464 465 466 467Disclaimer of Validity 468 469 470 This document and the information contained herein are provided on an 471 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 472 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 473 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 474 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 475 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 476 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 477 478 479 480Copyright Statement 481 482 483 Copyright (C) The Internet Society (2004). This document is subject 484 to the rights, licenses and restrictions contained in BCP 78, and 485 except as set forth therein, the authors retain all their rights. 486 487 488 489Acknowledgment 490 491 492 Funding for the RFC Editor function is currently provided by the 493 Internet Society. 494 495 496 497 498Williams & Hartman Expires December 30, 2004 [Page 8]