[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5929

NETWORK WORKING GROUP                                          J. Altman
Internet-Draft                                          Secure Endpoints
Intended status: Standards Track                             N. Williams
Expires: December 13, 2009                                           Sun
                                                           June 11, 2009


                        Channel Bindings for TLS
                draft-altman-tls-channel-bindings-04.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 December 13, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   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 & Williams       Expires December 13, 2009               [Page 1]

Internet-Draft            TLS Channel Bindings                 June 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  . . . . . . . . . . . . .  3
   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.    The 'tls-unique' Channel Binding Type  . . . . . . . . . . .  5
   4.    The 'tls-server-end-point' Channel Binding Type  . . . . . .  6
   5.    The 'tls-unique-for-telnet' Channel Binding Type . . . . . .  8
   6.    Applicability of TLS Channel Binding Types . . . . . . . . .  9
   7.    Required Application Programming Interfaces  . . . . . . . . 10
   8.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 11
   9.    Security Considerations  . . . . . . . . . . . . . . . . . . 12
   9.1.  Cryptographic Algorithm Agility  . . . . . . . . . . . . . . 12
   9.2.  On Disclosure of Channel Bindings Data by Authentication
         Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 12
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 14
   10.1. Normative References . . . . . . . . . . . . . . . . . . . . 14
   10.2. Normative References for 'tls-server-end-point'  . . . . . . 14
   10.3. Informative References . . . . . . . . . . . . . . . . . . . 14
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15

























Altman & Williams       Expires December 13, 2009               [Page 2]

Internet-Draft            TLS Channel Bindings                 June 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 & Williams       Expires December 13, 2009               [Page 3]

Internet-Draft            TLS Channel Bindings                 June 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 & Williams       Expires December 13, 2009               [Page 4]

Internet-Draft            TLS Channel Bindings                 June 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.

   o  Channel binding unique prefix: tls-unique

   o  Channel binding type: unique

   o  Channel type: TLS [RFC5246]

   o  Published specification: <this document>

   o  Channel binding is secret: no

   o  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).

   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 (ietf@ietf.org)

   o  Note: see the published specification for advice on the
      applicability of this channel binding type.









Altman & Williams       Expires December 13, 2009               [Page 5]

Internet-Draft            TLS Channel Bindings                 June 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.

   o  Channel binding unique prefix: tls-server-end-point

   o  Channel binding type: end-point

   o  Channel type: TLS [RFC5246]

   o  Published specification: <this document>

   o  Channel binding is secret: no

   o  Description: The hash of the TLS server's end entity 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 end
      entity certificate.)  The hash function to be selected is as
      follows: if the certificate's signature hash algorithm is either
      MD5 [RFC1321] or SHA-1 [RFC3174], then use SHA-256 [FIPS-180-2],
      otherwise use the certificate's signature hash algorithm.

      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.

   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 (ietf@ietf.org)

   o  Note: This channel binding is only suitable for use with PKIX
      server certificates [RFC5280], not OpenPGP certificates [RFC5081]
      [RFC4880].




Altman & Williams       Expires December 13, 2009               [Page 6]

Internet-Draft            TLS Channel Bindings                 June 2009


   o  Note: see the published specification for advice on the
      applicability of this channel binding type.

















































Altman & Williams       Expires December 13, 2009               [Page 7]

Internet-Draft            TLS Channel Bindings                 June 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.

   o  Channel binding unique prefix: tls-unique-for-telnet

   o  Channel binding type: unique

   o  Channel type: TLS [RFC5246]

   o  Published specification: <this document>

   o  Channel binding is secret: no

   o  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).

   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 (ietf@ietf.org)

   o  Note: see the published specification for advice on the
      applicability of this channel binding type.








Altman & Williams       Expires December 13, 2009               [Page 8]

Internet-Draft            TLS Channel Bindings                 June 2009


6.  Applicability of TLS Channel Binding Types

   The 'tls-unique-for-telnet' channel binding type is only applicable
   to TELNET [RFC0854].

   The 'tls-unique' channel binding type is always available for TLS
   connections, while 'tls-server-end-point' is only available when TLS
   cipher suites with server certificates are used.  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 are cases where 'tls-server-
   end-point' may interoperate but where 'tls-unique' may not.

   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 a priori 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 prefer 'tls-unique' over 'tls-server-end-
   point'.












Altman & Williams       Expires December 13, 2009               [Page 9]

Internet-Draft            TLS Channel Bindings                 June 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 may obtain the channel
   bindings for a TLS connection.  An implementation MAY provide
   interfaces for obtaining the initial Finished messages of a
   connection separately, letting TELNET [RFC0854] construct 'tls-
   unique-for-telnet' channel bindings from those, or the implementation
   MAY provide an interface specifically for extracting channel bindings
   data from a connection, and for a given channel binding type.

   TLS implementations supporting the use of 'tls-server-end-point'
   channel bindings MUST provide application programming interfaces to
   obtain this channel binding.  Such an interface SHOULD produce the
   'tls-server-end-point' channel bindings data directly, but MAY
   produce the certificate of the server for the connection instead, as
   it appears, octet for octet, in the server's Certificate message.
   When a connection results from TLS session resumption, the
   implementation may need to have cached the server certificate from
   the original connection, but MAY return an error instead of the
   channel binding or server certificate.  Applications wishing to use
   'tls-server-end-point' channel bindings and TLS session resumption
   MUST be prepared to handle the unavailability of 'tls-server-end-
   point' channel bindings in the case of TLS session resumption.


























Altman & Williams       Expires December 13, 2009              [Page 10]

Internet-Draft            TLS Channel Bindings                 June 2009


8.  IANA Considerations

   The IANA is hereby directed to update three existing channel binding
   type registrations.  See the rest of this document.















































Altman & Williams       Expires December 13, 2009              [Page 11]

Internet-Draft            TLS Channel Bindings                 June 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.  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 certificate itself: use SHA-256 if the certificate
   uses MD5 or SHA-1, else use whatever hash function the certificate
   uses.  This construction automatically makes 'tls-server-end-point'
   hash algorithm agile.

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



Altman & Williams       Expires December 13, 2009              [Page 12]

Internet-Draft            TLS Channel Bindings                 June 2009


   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.



























Altman & Williams       Expires December 13, 2009              [Page 13]

Internet-Draft            TLS Channel Bindings                 June 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".

   [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.

10.3.  Informative References

   [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
              Layer Security (TLS) Authentication", RFC 5081,
              November 2007.






Altman & Williams       Expires December 13, 2009              [Page 14]

Internet-Draft            TLS Channel Bindings                 June 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

































Altman & Williams       Expires December 13, 2009              [Page 15]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/