Just fail if writing cookies failes [CID-100]
[heimdal.git] / doc / standardisation / draft-williams-krb5-gssapi-prf-00.txt
blobca588cd735c833bc31a606ce97697f76ef95cdd6
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 for the Kerberos V GSS-API Mechanism
10                  draft-williams-krb5-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 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.
66 Williams & Hartman     Expires December 30, 2004                [Page 1]
67 Internet-Draft       A PRF for the Kerberos V Mech             July 2004
71 Table of Contents
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
124 Williams & Hartman     Expires December 30, 2004                [Page 2]
125 Internet-Draft       A PRF for the Kerberos V Mech             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 for the Kerberos V Mech             July 2004
187 2.  Introduction
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).
240 Williams & Hartman     Expires December 30, 2004                [Page 4]
241 Internet-Draft       A PRF for the Kerberos V Mech             July 2004
245 3.  Security Considerations
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.
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.
258 4  Normative
261    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
262               Requirement Levels", BCP 14, RFC 2119, March 1997.
265    [RFC2743]  Linn, J., "Generic Security Service Application Program
266               Interface Version 2, Update 1", RFC 2743, January 2000.
269    [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
270               C-bindings", RFC 2744, January 2000.
274 Authors' Addresses
277    Nicolas Williams
278    Sun Microsystems
279    5300 Riata Trace Ct
280    Austin, TX  78727
281    US
284    EMail: Nicolas.Williams@sun.com
288    Sam Hartman
289    Massachussets Institute of Technology
290    ...
291    ..., MA  ...
292    US
295    EMail: hartmans@mit.edu
308 Williams & Hartman     Expires December 30, 2004                [Page 5]
309 Internet-Draft       A PRF for the Kerberos V Mech             July 2004
313 Intellectual Property Statement
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.
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.
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.
342 Disclaimer of Validity
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.
355 Copyright Statement
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.
364 Acknowledgment
367    Funding for the RFC Editor function is currently provided by the
368    Internet Society.
373 Williams & Hartman     Expires December 30, 2004                [Page 6]