1 NETWORK WORKING GROUP N. Williams
3 Expires: December 30, 2004 S. Hartman
9 A PRF API extension for the GSS-API
10 draft-williams-gssapi-prf-00.txt
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
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
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."
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt.
38 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html.
42 This Internet-Draft will expire on December 30, 2004.
48 Copyright (C) The Internet Society (2004). All Rights Reserved.
54 This document defines a Pseudo-Random Function (PRF) extension to the
55 GSS-API for keying application protocols given an established GSS-API
66 Williams & Hartman Expires December 30, 2004 [Page 1]
67 Internet-Draft A PRF Extension for the GSS-API July 2004
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
124 Williams & Hartman Expires December 30, 2004 [Page 2]
125 Internet-Draft A PRF Extension for the GSS-API July 2004
129 1. Conventions used in this document
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].
182 Williams & Hartman Expires December 30, 2004 [Page 3]
183 Internet-Draft A PRF Extension for the GSS-API July 2004
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
199 To address this need we define a PRF extension to the GSS-API.
202 At this point EAP may be the primary consumer of this extension.
242 Williams & Hartman Expires December 30, 2004 [Page 4]
243 Internet-Draft A PRF Extension for the GSS-API July 2004
247 3. GSS_Pseudo_random()
253 o context CONTEXT handle,
254 o prf_in OCTET STRING
260 o major_status INTEGER,
261 o minor_status INTEGER,
262 o prf_out OCTET STRING
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
269 o GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
271 o GSS_S_FAILURE indicates failure or lack of support; the minor
272 status code may provide additional information.
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).
283 OM_uint32 gss_pseudo_random(
284 OM_uint32 *minor_status,
285 gss_ctx_id_t context,
286 const gss_buffer_t prf_in,
307 Williams & Hartman Expires December 30, 2004 [Page 5]
308 Internet-Draft A PRF Extension for the GSS-API July 2004
312 4. Security Considerations
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.
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.
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
331 [Question: Should GSS_Pseudo_random() have an input roughly
332 corresponding to the "key usage" used for key derivation in Kerberos
339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
340 Requirement Levels", BCP 14, RFC 2119, March 1997.
343 [RFC2743] Linn, J., "Generic Security Service Application Program
344 Interface Version 2, Update 1", RFC 2743, January 2000.
347 [RFC2744] Wray, J., "Generic Security Service API Version 2 :
348 C-bindings", RFC 2744, January 2000.
362 EMail: Nicolas.Williams@sun.com
367 Massachussets Institute of Technology
376 Williams & Hartman Expires December 30, 2004 [Page 6]
377 Internet-Draft A PRF Extension for the GSS-API July 2004
381 EMail: hartmans@mit.edu
433 Williams & Hartman Expires December 30, 2004 [Page 7]
434 Internet-Draft A PRF Extension for the GSS-API July 2004
438 Intellectual Property Statement
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.
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.
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
467 Disclaimer of Validity
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.
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.
492 Funding for the RFC Editor function is currently provided by the
498 Williams & Hartman Expires December 30, 2004 [Page 8]