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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
