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.