NETWORK WORKING GROUP S. Emery
Internet-Draft Sun
Intended status: Standards Track October 2006
Expires: April 4, 2007
Kerberos Version 5 GSS-API Channel Binding Hash Agility
draft-ietf-krb-wg-gss-cb-hash-agility-00.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 April 4, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Emery Expires April 4, 2007 [Page 1]
Internet-Draft Channel Binding Hash Agility October 2006
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. Channel binding hash agility . . . . . . . . . . . . . . . . . 4
3. Channel binding extension hash parameters . . . . . . . . . . 6
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 April 4, 2007 [Page 2]
Internet-Draft Channel Binding Hash Agility October 2006
1. Introduction
With the recently discovered weaknesses in the MD5 (SHA1 based) hash
algorithm there is a need to move to crypto-agility. 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.
Emery Expires April 4, 2007 [Page 3]
Internet-Draft Channel Binding Hash Agility October 2006
2. Channel binding hash agility
When generating a channel binding identifier, Bnd, a hash is computed
from the channel binding information. Newer clients (initiators)
shall continue to populate the Bnd field in order to remain
compatible with older servers (acceptors). In addition, newer
clients shall populate the extension field, Exts, with TYPED-DATA as
defined in [RFC4120]. The 0x8003 GSS checksum would 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 Type Extensions in ASN.1 DER encoding
where Extensions ::= TYPED-DATA -- as defined in [RFC4120]
The TYPED-DATA would have the following information:
data-type
This field specifies the type of channel binding extensions.
TBD is specified when the data-value contains channel binding
hash information.
data-value
This field contains specific channel binding information
relative to data-type. When data-type is TBD then data-value
contains the output obtained from the get_mic() operation as
specified in [RFC3961]. The parameters used are described in
section 2.2.
Emery Expires April 4, 2007 [Page 4]
Internet-Draft Channel Binding Hash Agility October 2006
When a newer server receives a token sent by a newer client the Bnd
field will be ignored. The newer server will then show that it
understands the extension by sending an AP-REP with the following
structure:
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
extensions [4] TYPED-DATA,
...
}
where extensions is the same data-type that the client had
sent in the AP-REQ.
Emery Expires April 4, 2007 [Page 5]
Internet-Draft Channel Binding Hash Agility October 2006
3. Channel binding extension hash parameters
The MAC value used as the channel binding identifier is calculated
with the following parameters:
(1) The session key is used to derive the specific key that is used
exclusively for the channel binding identifiers. The key usage is
a 32 bit integer TBD. The specific key Kc, is therefore derived
as:
Kc = key_generation(session-key, TBD | 0x99)
where key_generation is the key-derivation function
where 0x99 is the octet that is concatenated to the key usage
(2) The message parameter is created the same way as described in
section 4.1.1.2 of [RFC4121].
Emery Expires April 4, 2007 [Page 6]
Internet-Draft Channel Binding Hash Agility October 2006
4. Security considerations
Servers can use a down-grade attack by ignoring the channel binding
extensions, but client policy can prevent these attacks if the client
has specific requirements.
Emery Expires April 4, 2007 [Page 7]
Internet-Draft Channel Binding Hash Agility October 2006
5. IANA Considerations
Question for wg: Do we need to be concerned with typed hole type
values?
Emery Expires April 4, 2007 [Page 8]
Internet-Draft Channel Binding Hash Agility October 2006
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.
Emery Expires April 4, 2007 [Page 9]
Internet-Draft Channel Binding Hash Agility October 2006
7. Normative References
[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 April 4, 2007 [Page 10]
Internet-Draft Channel Binding Hash Agility October 2006
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 April 4, 2007 [Page 11]
Internet-Draft Channel Binding Hash Agility October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 April 4, 2007 [Page 12]
