NETWORK WORKING GROUP J. Altman
Internet-Draft Secure Endpoints
Intended status: Standards Track N. Williams
Expires: April 5, 2010 Sun
L. Zhu
Microsoft Corporation
October 2, 2009
Channel Bindings for TLS
draft-altman-tls-channel-bindings-07.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 5, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Altman, et al. Expires April 5, 2010 [Page 1]
Internet-Draft TLS Channel Bindings October 2009
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Altman, et al. Expires April 5, 2010 [Page 2]
Internet-Draft TLS Channel Bindings October 2009
Abstract
This document defines three channel binding types for Transport Layer
Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-
telnet, in accordance with RFC 5056 (On Channel Binding).
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The 'tls-unique' Channel Binding Type . . . . . . . . . . . 6
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6
4. The 'tls-server-end-point' Channel Binding Type . . . . . . 7
4.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 7
5. The 'tls-unique-for-telnet' Channel Binding Type . . . . . . 9
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Applicability of TLS Channel Binding Types . . . . . . . . . 11
7. Required Application Programming Interfaces . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . 16
9.1. Cryptographic Algorithm Agility . . . . . . . . . . . . . . 16
9.2. On Disclosure of Channel Bindings Data by Authentication
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . . 18
10.2. Normative References for 'tls-server-end-point' . . . . . . 18
10.3. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Altman, et al. Expires April 5, 2010 [Page 3]
Internet-Draft TLS Channel Bindings October 2009
1. 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].
Altman, et al. Expires April 5, 2010 [Page 4]
Internet-Draft TLS Channel Bindings October 2009
2. Introduction
Subsequent to the publication of "On Channel Bindings" [RFC5246],
three channel binding types for Transport Layer Security (TLS) were
proposed, reviewed and added to the IANA channel binding type
registry, all in accordance with [RFC5246]. Those channel binding
types are: 'tls-unique', 'tls-server-end-point', and 'tls-unique-for-
telnet'. It has become desirable to have these channel binding types
re-registered through an RFC so as to make it easier to reference
them. This document does just that. The authors of those three
channel binding types have, or have indicated that they will,
transferred "ownership" of those channel binding types to the IESG.
We also provide some advice on the applicability of these channel
binding types, as well as advice on when to use which. And we
provide an abstract API that TLS implementors should provide, by
which to obtain channel bindings data for a TLS connection.
Altman, et al. Expires April 5, 2010 [Page 5]
Internet-Draft TLS Channel Bindings October 2009
3. The 'tls-unique' Channel Binding Type
IANA is hereby directed to update the registration of the 'tls-
unique' channel binding type to match the following. Note that the
only material changes from the original registration should be: the
"owner" (now the IESG), contacts, the published specfication, and a
clarification to the description by the addition of a parenthetical
note (that is, the first such note in the descritption is a new
addition). We also added a note indicating that this specification
contains applicability advice, and we moved security considerations
notes to the security considerations section of this document. All
other fields of the registration are copied here for the convenience
of readers.
3.1. Description
Description: The client's TLS Finished message (note: the Finished
struct) from the first handshake of the connection (note: connection,
not session, so that the channel binding is specific to each
connection regardless of whether session resumption is used).
3.2. Registration
o Channel binding unique prefix: tls-unique
o Channel binding type: unique
o Channel type: TLS [RFC5246]
o Published specification:
o Channel binding is secret: no
o Description:
o Intended usage: COMMON
o Person and email address to contact for further information: Larry
Zhu (lzhu@microsoft.com), Nicolas Williams
(Nicolas.Williams@sun.com).
o Owner/Change controller name and email address: IESG.
o Expert reviewer name and contact information: IETF TLS WG
(tls@ietf.org, failing that, ietf@ietf.org)
o Note: see the published specification for advice on the
applicability of this channel binding type.
Altman, et al. Expires April 5, 2010 [Page 6]
Internet-Draft TLS Channel Bindings October 2009
4. The 'tls-server-end-point' Channel Binding Type
IANA is hereby directed to update the registration of the 'tls-
server-end-point' channel binding type to match the following. Note
that the only material changes from the original registration should
be: the "owner" (now the IESG), the contacts, the published
specfication, and a note indicating that the published specification
should be consulted for applicability advice. References were added
to the description. All other fields of the registration are copied
here for the convenience of readers.
4.1. Description
Description: The hash of the TLS server's certificate [RFC5280] as it
appears, octet for octet, in the server's Certificate message (note
that the Certificate message contains a certificate_list, the first
element of which is the server's certificate).
The hash function is to be selected as follows:
o if the certificate's signatureAlgorithm uses a single hash
function, and that hash function is either MD5 [RFC1321] or SHA-1
[RFC3174] then use SHA-256 [FIPS-180-2];
o if the certificate's signatureAlgorithm uses a single hash
function and that hash function neither MD5 nor SHA-1, then use
the hash function associated with the certificate's
signatureAlgorithm;
o if the certificate's signatureAlgorithm uses no hash functions or
multiple hash functions, then this channel binding type's channel
bindings are undefined at this time (updates to is channel binding
type may occur to address this issue if it ever arises).
The reason for using a hash of the certificate is that some
implementations need to track the channel binding of a TLS session in
kernel-mode memory, which is often at a premium.
4.2. Registration
o Channel binding unique prefix: tls-server-end-point
o Channel binding type: end-point
o Channel type: TLS [RFC5246]
o Published specification:
Altman, et al. Expires April 5, 2010 [Page 7]
Internet-Draft TLS Channel Bindings October 2009
o Channel binding is secret: no
o Description:
o Intended usage: COMMON
o Person and email address to contact for further information: Larry
Zhu (lzhu@microsoft.com), Nicolas Williams
(Nicolas.Williams@sun.com).
o Owner/Change controller name and email address: IESG.
o Expert reviewer name and contact information: IETF TLS WG
(tls@ietf.org, failing that, ietf@ietf.org)
o Note: see the published specification for advice on the
applicability of this channel binding type.
Altman, et al. Expires April 5, 2010 [Page 8]
Internet-Draft TLS Channel Bindings October 2009
5. The 'tls-unique-for-telnet' Channel Binding Type
IANA is hereby directed to update the registration of the 'tls-
unique-for-telnet' channel binding type to match the following. Note
that the only material changes from the original registration should
be: the "owner" (now the IESG), the contacts, the published
specfication, and a note indicating that the published specification
should be consulted for applicability advice. The description is
also clarified. We also moved security considerations notes to the
security considerations section of this document. All other fields
of the registration are copied here for the convenience of readers.
5.1. Description
Description: There is a proposal for adding a "StartTLS" extension to
TELNET, and a channel binding extension for the various TELNET AUTH
mechanisms whereby each side sends the other a "checksum" (MAC) of
their view of the channel's bindings. The client uses the first TLS
Finished messages (note: the Finished struct) from the client and
server, each concatenated in that order and in their clear text form.
The server does the same but in the opposite concatenation order
(server, then client).
5.2. Registration
o Channel binding unique prefix: tls-unique-for-telnet
o Channel binding type: unique
o Channel type: TLS [RFC5246]
o Published specification:
o Channel binding is secret: no
o Description:
o Intended usage: COMMON
o Person and email address to contact for further information: Jeff
Altman (jaltman@secure-endpoints.com), Nicolas Williams
(Nicolas.Williams@sun.com).
o Owner/Change controller name and email address: IESG.
o Expert reviewer name and contact information: IETF TLS WG
(tls@ietf.org, failing that, ietf@ietf.org)
Altman, et al. Expires April 5, 2010 [Page 9]
Internet-Draft TLS Channel Bindings October 2009
o Note: see the published specification for advice on the
applicability of this channel binding type.
Altman, et al. Expires April 5, 2010 [Page 10]
Internet-Draft TLS Channel Bindings October 2009
6. Applicability of TLS Channel Binding Types
The 'tls-unique-for-telnet' channel binding type is only applicable
to TELNET [RFC0854], and is available for all TLS connections.
The 'tls-unique' channel binding type is available for all TLS
connections, while 'tls-server-end-point' is only available when TLS
cipher suites with server certificates are used, specifically: cipher
suites that use the Certificate handshake message, which typically
involve the use of PKIX [RFC5280]. For example, 'tls-server-end-
point' is available when using TLS ciphers suites such as (this is
not an exhaustive list):
o TLS_DHE_DSS_WITH_*
o TLS_DHE_RSA_WITH_*
o TLS_DH_DSS_WITH_*
o TLS_DH_RSA_WITH_*
o TLS_ECDHE_ECDSA_WITH_*
o TLS_ECDHE_RSA_WITH_*
o TLS_ECDH_ECDSA_WITH_*
o TLS_ECDH_RSA_WITH_*
o TLS_RSA_PSK_WITH_*
o TLS_RSA_WITH_*
o TLS_SRP_SHA_DSS_WITH_*
o TLS_SRP_SHA_RSA_WITH_*
but is not available when using TLS cipher suites such as (this is
not an exhaustive list):
o TLS_DHE_PSK_WITH_*
o TLS_DH_anon_WITH_*
o TLS_ECDHE_PSK_WITH_*
o TLS_ECDH_anon_WITH_*
Altman, et al. Expires April 5, 2010 [Page 11]
Internet-Draft TLS Channel Bindings October 2009
o TLS_KRB5_WITH_*
o TLS_PSK_WITH_*
o TLS_SRP_SHA_WITH_*
Nor is this channel binding type available for use with OpenPGP
server certificates [RFC5081] [RFC4880] (since these don't use the
Certificate handshake message).
Therefore 'tls-unique' is generally better than 'tls-server-end-
point'. However, 'tls-server-end-point' may be used with existing
TLS server-side proxies ("concentrators") without modification to the
proxies, whereas 'tls-unique' may require firmware or software
updates to server-side proxies. Therefore there may be cases where
'tls-server-end-point' may interoperate but where 'tls-unique' may
not.
Also, authentications mechanisms may arise which depend on channel
bindings to contribute entropy, in which case unique channel bindings
would have to always be used in preference to end-point channel
bindings. At this time there are no such mechanisms, though one such
SASL mechanism has been proposed. Whether such mechanisms should be
allowed is out of scope for this document.
In other words, for many applications there may be two potentially
applicable TLS channel binding types. Channel binding is all or
nothing for the GSS-API [RFC2743], and likely other frameworks.
Therefore agreement on the use of channel binding, and a particular
channel binding type is necessary. Such agreement can be obtained a
priori, by convention, or negotiated.
The specifics of whether and how to negotiate channel binding types
are beyond the scope of this document. However, it is RECOMMENDED
that application protocols making use of TLS channel bindings, use
'tls-unique' exclusively, except, perhaps, where server-side proxies
are common in deployments of an application protocol. In the latter
case an application protocol MAY specify that 'tls-server-end-point'
channel bindings must be used when available, with 'tls-unique' being
used when 'tls-server-end-point' channel bindings are not available.
Alternatively, the application may negotiate which channel binding
type to use, or may make the choice of channel binding type
configurable.
Specifically, application protocol specifications MUST indicate at
least one mandatory to implement channel binding type, MAY specify a
negotiation protocol, MAY allow for out-of-band negotiation or
configuration, and SHOULD have a preference for 'tls-unique' over
Altman, et al. Expires April 5, 2010 [Page 12]
Internet-Draft TLS Channel Bindings October 2009
'tls-server-end-point'.
Altman, et al. Expires April 5, 2010 [Page 13]
Internet-Draft TLS Channel Bindings October 2009
7. Required Application Programming Interfaces
TLS implementations supporting the use of 'tls-unique' and/or 'tls-
unique-for-telnet' channel binding types, MUST provide application
programming interfaces by which applications (clients and servers
both) may obtain the channel bindings for a TLS connection. Such
interfaces may be expressed in terms of extracting the channel
bindings data for a given connection and channel binding type.
Alternatively the implementor may provide interfaces by which to
obtain the initial client Finished message, the initial server
Finished message and/or the server certificate (in a form that
matches the description of the 'tls-server-end-point' channel binding
type). In the latter case the application has to have knowledge of
the channel binding type descriptions from this document. This
document takes no position on which form these application
programming interfaces must take.
Altman, et al. Expires April 5, 2010 [Page 14]
Internet-Draft TLS Channel Bindings October 2009
8. IANA Considerations
The IANA is hereby directed to update three existing channel binding
type registrations. See the rest of this document.
Altman, et al. Expires April 5, 2010 [Page 15]
Internet-Draft TLS Channel Bindings October 2009
9. Security Considerations
The Security Considerations section of [RFC5056] applies to this
document.
The TLS Finished messages (see section 7.4.9 of [RFC5246]) are known
to both endpoints of a TLS connection, and are cryptographycally
bound to it. Therefore the TLS Finished messages can be safely used
as a channel binding provided that the authentication mechanism doing
the channel binding conforms to the requirements in [RFC5056].
The server certificate, when present, is also cryptographically bound
to the TLS connection through its use in key transport and/or
authentication of the server (either by dint of its use in key
transport, by its use in signing key agreement, or by its use in key
agreement). Therefore the server certificate is suitable as an end-
point channel binding as described in [RFC5056].
9.1. Cryptographic Algorithm Agility
The 'tls-unique' and 'tls-unique-for-telnet' channel binding types do
not add any use of cryptography beyond that used by TLS itself.
Therefore these two channel binding types add no considerations with
respect to cryptographic algorithm agility.
The 'tls-server-end-point' channel binding type consist of a hash of
a server certificate. The reason for this is to produce manageably
small channel binding data, as some implementations will be using
kernel-mode memory (which is typically scarce) to store these. This
use of a hash algorithm is above and beyond TLS's use of
cryptography, therefore the 'tls-server-end-point' channel binding
type has a security consideration with respect to hash algorithm
agility. The algorithm to be used, however, is derived from the
server certificate's signature algorithm as described in Section 4.1;
to recap: use SHA-256 if the certificate signature algorithm uses MD5
or SHA-1, else use whatever hash function the certificate uses
(unless the signature algorithm uses no hash functions or more than
one hash function, in which case 'tls-server-end-point' is
undefined). This construction automatically makes 'tls-server-end-
point' hash algorithm agile, with a dependency on PKIX and TLS for
hash agility.
Current proposals for randomized signatures algorithms
[I-D.irtf-cfrg-rhash] [NIST-SP.800-106.2009] use hash functions in
their construction -- a single hash function in each algorithm.
Therefore the 'tls-server-end-point' channel binding type should be
available even in cases where new signatures algorithms are used that
are based on current randomized hashing proposals (but we cannot
Altman, et al. Expires April 5, 2010 [Page 16]
Internet-Draft TLS Channel Bindings October 2009
guarantee this, of course).
9.2. On Disclosure of Channel Bindings Data by Authentication
Mechanisms
When these channel binding types were first considered, one issue
that some commenters were concerned about was the possible impact on
the security of the TLS channel, of disclosure of the channel
bindings data by authentication mechanisms. This can happen, for
example, when an authentication mechanism transports the channel
bindings data, with no confidentiality protection, over other
transports (for example, in communicating with a trusted third
party), or when the TLS channel provides no confidentiality
protection and the authentication mechanism does not protect the
confidentiality of the channel bindings data. This section considers
that concern.
When the TLS connection uses a cipher suite that does not provide
confidentiality protection, the TLS Finished messages will be visible
to eavesdroppers, regardless of what the authentication mechanism
does. The same is true of the server certificate which, in any case,
is generally visible to eavesdroppers. Therefore we must consider
our choices of TLS channel bindings here to be safe to disclose by
definition -- if that were not the case then TLS with cipher suites
that don't provide confidentiality protection would be unsafe.
Furthermore, the TLS Finished message construction depends on the
security of the TLS PRF, which in turn needs to be resistant to key
recovery attacks, and we think that it is, as it is based on HMAC,
and the master secret is, well, secret (and the result of key
exchange).
Note too that in the case of an attempted active man-in-the-middle
attack, the attacker will already possess knowledge of the TLS
finished messages for both inbound and outbound TLS channels (which
will differ, given that the attacker cannot force them to be the
same). No additional information is obtained by the attacker from
the authentication mechanism's disclosure of channel bindings data --
the attacker already has it, even when cipher suites providing
confidentiality protection are provided.
None of the channel binding types defined herein produce channel
bindings data that must be kept secret. Moreover, none of the
channel binding types defined herein can be expected to be private
(known only to the end-points of the channel), except that the unique
TLS channel binding types can be expected to be private when a cipher
suite that provides confidentiality protection is used to protect the
Finished message exchanges and the application data records
containing application-layer authentication messages.
Altman, et al. Expires April 5, 2010 [Page 17]
Internet-Draft TLS Channel Bindings October 2009
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
10.2. Normative References for 'tls-server-end-point'
[FIPS-180-2]
United States of America, National Institute of Standards
and Technology, "Secure Hash Standard (Federal Information
Processing Standard (FIPS) 180-2".
10.3. Informative References
[I-D.irtf-cfrg-rhash]
Halevi, S. and H. Krawczyk, "Strengthening Digital
Signatures via Randomized Hashing",
draft-irtf-cfrg-rhash-01 (work in progress), October 2007.
[NIST-SP.800-106.2009]
National Institute of Standards and Technology, "NIST
Special Publication 800-106: Randomized Hashing for
Digital Signatures", February 2009.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
Altman, et al. Expires April 5, 2010 [Page 18]
Internet-Draft TLS Channel Bindings October 2009
Layer Security (TLS) Authentication", RFC 5081,
November 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
Altman, et al. Expires April 5, 2010 [Page 19]
Internet-Draft TLS Channel Bindings October 2009
Authors' Addresses
Jeff Altman
Secure Endpoints
255 W 94TH ST PHB
New York, NY 10025
US
Email: jaltman@secure-endpoints.com
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: lzhu@microsoft.com
Altman, et al. Expires April 5, 2010 [Page 20]