update .gitignore
[heimdal.git] / doc / standardisation / draft-ietf-krb-wg-gss-cb-hash-agility-05.txt
blob313236dda414cb4d224c0ce7cff08fc472405026
4 NETWORK WORKING GROUP                                           S. Emery
5 Internet-Draft                                          Sun Microsystems
6 Updates: 4121 (if approved)                             November 3, 2008
7 Intended status: Standards Track
8 Expires: May 7, 2009
11         Kerberos Version 5 GSS-API Channel Binding Hash Agility
12               draft-ietf-krb-wg-gss-cb-hash-agility-05.txt
14 Status of this Memo
16    By submitting this Internet-Draft, each author represents that any
17    applicable patent or other IPR claims of which he or she is aware
18    have been or will be disclosed, and any of which he or she becomes
19    aware will be disclosed, in accordance with Section 6 of BCP 79.
21    Internet-Drafts are working documents of the Internet Engineering
22    Task Force (IETF), its areas, and its working groups.  Note that
23    other groups may also distribute working documents as Internet-
24    Drafts.
26    Internet-Drafts are draft documents valid for a maximum of six months
27    and may be updated, replaced, or obsoleted by other documents at any
28    time.  It is inappropriate to use Internet-Drafts as reference
29    material or to cite them other than as "work in progress."
31    The list of current Internet-Drafts can be accessed at
32    http://www.ietf.org/ietf/1id-abstracts.txt.
34    The list of Internet-Draft Shadow Directories can be accessed at
35    http://www.ietf.org/shadow.html.
37    This Internet-Draft will expire on May 7, 2009.
55 Emery                      Expires May 7, 2009                  [Page 1]
57 Internet-Draft        Channel Binding Hash Agility         November 2008
60 Abstract
62    Currently, channel bindings are implemented using a MD5 hash in the
63    Kerberos Version 5 Generic Security Services Application Programming
64    Interface (GSS-API) mechanism [RFC4121].  This document updates
65    RFC4121 to allow channel bindings using algorithms negotiated based
66    on Kerberos crypto framework as defined in RFC3961.  In addition,
67    because this update makes use of the last extensible field in the
68    Kerberos client-server exchange message, extensions are defined to
69    allow future protocol extensions.
72 Table of Contents
74    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
75    2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
76    3.  Channel binding hash agility . . . . . . . . . . . . . . . . .  5
77    4.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
78    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
79    6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
80    7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
81    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
82    Intellectual Property and Copyright Statements . . . . . . . . . . 12
111 Emery                      Expires May 7, 2009                  [Page 2]
113 Internet-Draft        Channel Binding Hash Agility         November 2008
116 1.  Introduction
118    With the recently discovered weaknesses in the MD5 hash algorithm
119    there is a need to use stronger hash algorithms.  Kerberos Version 5
120    Generic Security Services Application Programming Interface (GSS-API)
121    mechanism [RFC4121] uses MD5 to calculate channel binding verifiers.
122    This document specifies an update to the mechanism that allows it to
123    create channel binding information based on negotiated algorithms.
124    This will allow deploying new algorithms incrementally without break
125    interoperability with older implementations, when new attacks arise
126    in the future.
167 Emery                      Expires May 7, 2009                  [Page 3]
169 Internet-Draft        Channel Binding Hash Agility         November 2008
172 2.  Conventions Used in This Document
174    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
175    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
176    document are to be interpreted as described in [RFC2119].
178    The term "little endian order" is used for brevity to refer to the
179    least-significant-octet-first encoding, while the term "big endian
180    order" is for the most-significant-octet-first encoding.
223 Emery                      Expires May 7, 2009                  [Page 4]
225 Internet-Draft        Channel Binding Hash Agility         November 2008
228 3.  Channel binding hash agility
230    When generating a channel binding verifier, Bnd, a hash is computed
231    from the channel binding fields.  Initiators MUST populate the Bnd
232    field in order to maintain interoperability with existing acceptors.
233    In addition, initiators MUST populate the extension field, Exts.  All
234    fields before "Exts" do not change from what is described in
235    [RFC4121], they are listed for convenience.  The 0x8003 GSS checksum
236    MUST have the following structure:
238       Octet     Name       Description
239       -----------------------------------------------------------------
240       0..3      Lgth       Number of octets in Bnd field;  Represented
241                             in little-endian order;  Currently contains
242                             hex value 10 00 00 00 (16).
243       4..19     Bnd        Channel binding information, as described in
244                             section 4.1.1.2 [RFC4121].
245       20..23    Flags      Four-octet context-establishment flags in
246                             little-endian order as described in section
247                             4.1.1.1 [RFC4121].
248       24..25    DlgOpt     The delegation option identifier (=1) in
249                             little-endian order [optional].  This field
250                             and the next two fields are present if and
251                             only if GSS_C_DELEG_FLAG is set as described
252                             in section 4.1.1.1 [RFC4121].
253       26..27    Dlgth      The length of the Deleg field in
254                             little-endian order [optional].
255       28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
256       n..last   Exts       Extensions
258       where Exts is the concatenation of zero, one or more individual
259       extensions, each of which consists of, in order:
261         type -- big endian order unsigned integer, 32-bits, which
262                 contains the type of extension
263         length -- big endian order unsigned integer, 32-bits, which
264                 contains the length, in octets, of the extension data
265                 encoded as an array of octets immediately following this
266                 field
267         data -- octet string of extension information
268       in that order
270       If multiple extensions are present then there MUST be at most one
271       instance of a given extension type.
273    When channel binding is used the Exts MUST include the following
274    extension:
279 Emery                      Expires May 7, 2009                  [Page 5]
281 Internet-Draft        Channel Binding Hash Agility         November 2008
284       data-type 0x00000000
286       data-value
288          The output obtained by applying the Kerberos V get_mic()
289          operation [RFC3961], using the sub-session key from the
290          authenticator and key usage number 43, to the channel binding
291          data as described in [RFC4121], section 4.1.1.2 (using get_mic
292          instead of MD5).
294    Initiators that are unwilling to use a MD5 hash of the channel
295    bindings MUST set the Bnd field to sixteen octets of hex value FF.
335 Emery                      Expires May 7, 2009                  [Page 6]
337 Internet-Draft        Channel Binding Hash Agility         November 2008
340 4.  Security considerations
342    Initiators do not know if the acceptor had ignored channel bindings
343    or whether it validated the MD5 hash of the channel bindings
344    [RFC4121].
346    Ultimately, it is up to the application whether to use channel
347    binding or not.  This is dependent upon the security policy of these
348    applications.
391 Emery                      Expires May 7, 2009                  [Page 7]
393 Internet-Draft        Channel Binding Hash Agility         November 2008
396 5.  IANA Considerations
398    The IANA is hereby requested to create a new registry of "Kerberos V
399    GSS-API mechanism extension types" with four-field entries (type
400    number, type name, description, and normative reference) and,
401    initially, a single registration: 0x00000000, "Channel Binding MIC,"
402    "Extension for the verifier of the channel bindings," <this RFC>.
404    Using the guidelines for allocation as described in [RFC5226], type
405    number assignments are as follows:
407       0x00000000 - 0x000003FF IETF Consensus
409       0x00000400 - 0xFFFFF3FF Specification Required
411       0xFFFFF400 - 0xFFFFFFFF Private Use
447 Emery                      Expires May 7, 2009                  [Page 8]
449 Internet-Draft        Channel Binding Hash Agility         November 2008
452 6.  Acknowledgements
454    Larry Zhu helped in the review of this document overall and provided
455    the suggestions of typed-data.
457    Nicolas Williams and Sam Hartman suggested that the Bnd and Exts
458    fields be populated simultaneously.
460    Nicolas Williams and Jeffrey Hutzelman had also suggested a number
461    changes to this document.
503 Emery                      Expires May 7, 2009                  [Page 9]
505 Internet-Draft        Channel Binding Hash Agility         November 2008
508 7.  Normative References
510    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
511               Requirement Levels", BCP 14, RFC 2119, March 1997.
513    [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
514               Kerberos 5", RFC 3961, February 2005.
516    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
517               Kerberos Network Authentication Service (V5)", RFC 4120,
518               July 2005.
520    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
521               Version 5 Generic Security Service Application Program
522               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
523               July 2005.
525    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
526               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
527               May 2008.
559 Emery                      Expires May 7, 2009                 [Page 10]
561 Internet-Draft        Channel Binding Hash Agility         November 2008
564 Author's Address
566    Shawn Emery
567    Sun Microsystems
568    500 Eldorado Blvd
569    M/S UBRM05-171
570    Broomfield, CO  80021
571    US
573    Email: shawn.emery@sun.com
615 Emery                      Expires May 7, 2009                 [Page 11]
617 Internet-Draft        Channel Binding Hash Agility         November 2008
620 Full Copyright Statement
622    Copyright (C) The IETF Trust (2008).
624    This document is subject to the rights, licenses and restrictions
625    contained in BCP 78, and except as set forth therein, the authors
626    retain all their rights.
628    This document and the information contained herein are provided on an
629    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
630    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
631    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
632    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
633    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
634    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
637 Intellectual Property
639    The IETF takes no position regarding the validity or scope of any
640    Intellectual Property Rights or other rights that might be claimed to
641    pertain to the implementation or use of the technology described in
642    this document or the extent to which any license under such rights
643    might or might not be available; nor does it represent that it has
644    made any independent effort to identify any such rights.  Information
645    on the procedures with respect to rights in RFC documents can be
646    found in BCP 78 and BCP 79.
648    Copies of IPR disclosures made to the IETF Secretariat and any
649    assurances of licenses to be made available, or the result of an
650    attempt made to obtain a general license or permission for the use of
651    such proprietary rights by implementers or users of this
652    specification can be obtained from the IETF on-line IPR repository at
653    http://www.ietf.org/ipr.
655    The IETF invites any interested party to bring to its attention any
656    copyrights, patents or patent applications, or other proprietary
657    rights that may cover technology that may be required to implement
658    this standard.  Please address the information to the IETF at
659    ietf-ipr@ietf.org.
671 Emery                      Expires May 7, 2009                 [Page 12]