lib/gssapi/krb5: split out a arcfour_mic_cksum_iov() function
[heimdal.git] / doc / standardisation / draft-williams-gssapi-prf-00.txt
blob097ce851504f8fe1aa1f45d4f9d0553dd093cd89
1 NETWORK WORKING GROUP                                        N. Williams
2 Internet-Draft                                                       Sun
3 Expires: December 30, 2004                                    S. Hartman
4                                                                      MIT
5                                                                July 2004
9                   A PRF API extension for the GSS-API
10                     draft-williams-gssapi-prf-00.txt
13 Status of this Memo
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.
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.
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.
45 Copyright Notice
48    Copyright (C) The Internet Society (2004).  All Rights Reserved.
51 Abstract
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.
66 Williams & Hartman     Expires December 30, 2004                [Page 1]
67 Internet-Draft      A PRF Extension for the GSS-API            July 2004
71 Table of Contents
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
187 2.  Introduction
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.
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()
250    Inputs:
253    o  context CONTEXT handle,
254    o  prf_in OCTET STRING
257    Outputs:
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
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.
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).
280 3.1  C-Bindings
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    );
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
328    GSS_Pseudo_random().
331    [Question:  Should GSS_Pseudo_random() have an input roughly
332    corresponding to the "key usage" used for key derivation in Kerberos
333    V?]
336 5  Normative
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.
352 Authors' Addresses
355    Nicolas Williams
356    Sun Microsystems
357    5300 Riata Trace Ct
358    Austin, TX  78727
359    US
362    EMail: Nicolas.Williams@sun.com
366    Sam Hartman
367    Massachussets Institute of Technology
368    ...
369    ..., MA  ...
370    US
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
463    ietf-ipr@ietf.org.
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.
480 Copyright Statement
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.
489 Acknowledgment
492    Funding for the RFC Editor function is currently provided by the
493    Internet Society.
498 Williams & Hartman     Expires December 30, 2004                [Page 8]