Protocol Action: 'Channel Bindings for TLS' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Channel Bindings for TLS '
   <draft-altman-tls-channel-bindings-10.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Alexey Melnikov.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-10.txt

Technical Summary

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

Working Group Summary

   Although this is an individual submission, it was pseudo-Last Called
   in the SASL and TLS Working Groups.  No dissent was reported.  All
   comments have been addressed.

   Note that in March 2010 an incompatibility was discovered between
   Microsoft's implementation of "tls-unique" channel binding type
   and its IANA registration. After community discussions there was
   SASL mailing list consensus to update the definition to match
   Microsoft implementation.

Document Quality

   There appears to exist at least one implementation of each of the
   tls-server-end-point and tls-unique-for-telnet channel binding types.
   Implementations of tls-unique appear to be in progress.

   Note that "tls-unique" channel binding type is the mandatory to
   implement for SASL SCRAM document which is currently in AUTH48.

Personnel

   Alexey Melnikov is the Responsible Area Director for this document.

RFC Editor Note

Please add the following paragraph at the end of the Abstract:

   Note that based on implementation experience this document changes
   the current definition of 'tls-unique' channel binding type in the
   channel binding type IANA registry.

In Section 2, change the first line of the first sentence to read:

OLD:
   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]

NEW:
   Subsequent to the publication of "On Channel Bindings" [RFC5056],
   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 [RFC5056]

In Section 3.1, please update the 1st sentence of the 1st paragraph to
read:

OLD:
   Description: The first TLS Finished message sent (note: the Finished
   struct) in the most recent TLS handshake of the TLS connection being
   bound to (note: TLS connection, not session, so that the channel
   binding is specific to each connection regardless of whether session
   resumption is used).

NEW:
   Description: The first TLS Finished message sent (note: the Finished
   struct, not the TLS record layer message containing it)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   in the most recent TLS handshake of the TLS connection being
   bound to (note: TLS connection, not session, so that the channel
   binding is specific to each connection regardless of whether session
   resumption is used).


Please update the last sentence of Section 3.1 to read:

OLD:
      Application protocols should be designed in such a way that a
                            ^^^^^^
      server would never need to request TLS re-negotiation immediately
      before or during application-layer authentication.

NEW:
      Application protocols SHOULD be designed in such a way that a
                            ^^^^^^
      server would never need to request TLS re-negotiation immediately
      before or during application-layer authentication.


In Section 4.1, please replace the first paragraph to read:

OLD:
   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).

NEW:
   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.

(i.e. make the note a separate sentence.)

Please replace "<this document>" in Sections 3.2, 4.2, and 5.2 with the
RFC number assigned to this document upon publication.


In Section 6, please replace the 1st sentence in the 5th from the last
paragraph to read:

OLD:
   Therefore 'tls-unique' is generally better than 'tls-server-end-
   point'.

NEW:
   Therefore 'tls-unique' is applicable to more contexts than 'tls-
   server-end-point'.

In Section 6, replace the 3rd from the last paragraph:

OLD:
   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.

NEW:
   For many applications there may be two or more potentially applicable
   TLS channel binding types.  Existing security frameworks (such as the
   GSS-API [RFC2743]) and security mechanisms, generally do not support
   negotiation of channel binding types.  Therefore application peers
   need to agree a priori as to what channel binding type to use (or
   rules for deciding what channel binding type to use).


Please replace the following reference in Section 11.2 (and its uses):

   [FIPS-180-2]
              United States of America, National Institute of Standards
              and Technology, "Secure Hash Standard (Federal Information
              Processing Standard (FIPS) 180-2".

to point to FIPS-180-3.