x

git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@22205 ec53bebd-3082-4978-b11e-865c3cabbd6b

doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-03.txt

@@ -0,0 +1,673 @@
+
+
+
+NETWORK WORKING GROUP                                           S. Emery
+Internet-Draft                                          Sun Microsystems
+Updates: 4121 (if approved)                             November 9, 2007
+Intended status: Standards Track
+Expires: May 12, 2008
+
+
+        Kerberos Version 5 GSS-API Channel Binding Hash Agility
+              draft-ietf-krb-wg-gss-cb-hash-agility-03.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on May 12, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 1]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+Abstract
+
+   Currently, the Kerberos Version 5 Generic Security Services
+   Application Programming Interface (GSS-API) mechanism [RFC4121] does
+   not have the ability to utilize better hash algorithms used to
+   generate channel binding identities.  The current mechanism for doing
+   this is hard coded to use MD5 only.  The purpose of this document is
+   to outline changes required to update the protocol so that more
+   secure algorithms can be used to create channel binding identities.
+   The extensibility of this solution also provides an eventual
+   replacement of identities based solely on hash algorithms.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Channel binding hash agility . . . . . . . . . . . . . . . . .  5
+   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 2]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+1.  Introduction
+
+   With the recently discovered weaknesses in the MD5 hash algorithm
+   there is a need to move stronger hash alogrithms.  Kerberos Version 5
+   Generic Security Services Application Programming Interface (GSS-API)
+   mechanism [RFC4121] uses MD5 to calculate channel binding identities
+   that are required to be unique.  This document specifies an update to
+   the mechanism that allows it to create channel binding identities
+   based on negotiating algorithms securely.  This will prevent lengthy
+   standardizations in the future when new attacks arise and will allow
+   an incremental update to the protocol so that this will interoperate
+   with older implementations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 3]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The term "little endian order" is used for brevity to refer to the
+   least-significant-octet-first encoding, while the term "big endian
+   order" is for the most-significant-octet-first encoding.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 4]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+3.  Channel binding hash agility
+
+   When generating a channel binding identifier, Bnd, a hash is computed
+   from the channel binding information.  Initiators MUST populate the
+   Bnd field in order to maintain interoperability with existing
+   acceptors.  In addition, initiators MUST populate the extension
+   field, Exts, with TYPED-DATA as defined in [RFC4120].  The 0x8003 GSS
+   checksum MUST have the following structure:
+
+      Octet     Name       Description
+      -----------------------------------------------------------------
+      0..3      Lgth       Number of octets in Bnd field;  Represented
+                            in little-endian order;  Currently contains
+                            hex value 10 00 00 00 (16).
+      4..19     Bnd        Channel binding information, as described in
+                            section 4.1.1.2 [RFC4121].
+      20..23    Flags      Four-octet context-establishment flags in
+                            little-endian order as described in section
+                            4.1.1.1 [RFC4121].
+      24..25    DlgOpt     The delegation option identifier (=1) in
+                            little-endian order [optional].  This field
+                            and the next two fields are present if and
+                            only if GSS_C_DELEG_FLAG is set as described
+                            in section 4.1.1.1 [RFC4121].
+      26..27    Dlgth      The length of the Deleg field in
+                            little-endian order [optional].
+      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
+      n..last   Exts       Extensions
+
+      where Exts is the concatenation of zero, one or more individual
+      extensions, each of which consists of:
+        type -- big endian order unsigned integer, 32-bits
+        length -- big endian order unsigned integer, 32-bits
+        data -- octet string of length octets
+      in that order
+
+   When channel binding is used the Exts MUST include the following
+   extension:
+
+      data-type 0x00000000
+
+      data-value
+
+         The output obtained by applying the Kerberos V get_mic()
+         operation [RFC3961], using the sub-session key from the
+         authenticator and key usage number TBD, to the channel binding
+         data as described in [RFC4121], section 4.1.1.2 (using get_mic
+         instead of MD5).
+
+
+
+Emery                     Expires May 12, 2008                  [Page 5]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+   Initiators that are unwilling to use a MD5 hash of the channel
+   bindings should set the Bnd field to all ones (1).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 6]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+4.  Security considerations
+
+   Initiators do not know if the acceptor had ignored channel bindings
+   or whether it validated the MD5 hash of the channel bindings
+   [RFC4121].
+
+   Ultimately, it is up to the application whether to use channel
+   binding or not.  This is dependent upon the security policy of these
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 7]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+5.  IANA Considerations
+
+   The IANA is hereby requested to create a new registry of "Kerberos V
+   GSS-API mechanism extension types" with four-field entries (type
+   number, type name, description, and normative reference) and,
+   initially, a single registration: 0x00000000, "Channel Binding MIC,"
+   "Extension for hash function-agile channel binding," <this RFC>.
+
+   Registration of additional extensions SHALL be by IESG Protocol
+   Action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 8]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+6.  Acknowledgements
+
+   Larry Zhu helped in the review of this document overall and provided
+   the suggestions of typed data and server acknowledgement.
+
+   Nicolas Williams and Sam Hartman suggested that the Bnd and Exts
+   fields be populated simultaneously.
+
+   Nicolas Williams and Jeffrey Hutzelman had also suggested a number
+   changes to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 9]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                 [Page 10]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+Author's Address
+
+   Shawn Emery
+   Sun Microsystems
+   500 Eldorado Blvd
+   M/S UBRM05-171
+   Broomfield, CO  80021
+   US
+
+   Email: shawn.emery@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                 [Page 11]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Emery                     Expires May 12, 2008                 [Page 12]
+
+