rfc9266.original   rfc9266.txt 
Transport Layer Security S. Whited Internet Engineering Task Force (IETF) S. Whited
Internet-Draft 4 May 2022 Request for Comments: 9266 July 2022
Updates: 5801, 5802, 5929, 7677 (if approved) Updates: 5801, 5802, 5929, 7677
Intended status: Standards Track Category: Standards Track
Expires: 5 November 2022 ISSN: 2070-1721
Channel Bindings for TLS 1.3 Channel Bindings for TLS 1.3
draft-ietf-kitten-tls-channel-bindings-for-tls13-16
Abstract Abstract
This document defines a channel binding type, tls-exporter, that is This document defines a channel binding type, tls-exporter, that is
compatible with TLS 1.3 in accordance with RFC 5056, On Channel compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of
Binding. Furthermore, it updates the default channel binding to the Channel Bindings to Secure Channels". Furthermore, it updates the
new binding for versions of TLS greater than 1.2. This document default channel binding to the new binding for versions of TLS
updates RFC5801, RFC5802, RFC5929, and RFC7677. greater than 1.2. This document updates RFCs 5801, 5802, 5929, and
7677.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 5 November 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9266.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology
2. The 'tls-exporter' Channel Binding Type . . . . . . . . . . . 3 2. The 'tls-exporter' Channel Binding Type
3. TLS 1.3 with SCRAM or GSS-API over SASL . . . . . . . . . . . 3 3. TLS 1.3 with SCRAM or GSS-API over SASL
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations
4.1. Uniqueness of Channel Bindings . . . . . . . . . . . . . 4 4.1. Uniqueness of Channel Bindings
4.2. Use with Legacy TLS . . . . . . . . . . . . . . . . . . . 5 4.2. Use with Legacy TLS
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations
5.1. Registration of Channel Binding Type . . . . . . . . . . 5 5.1. Registration of Channel Binding Type
5.2. Registration of Channel Binding TLS Exporter Label . . . 6 5.2. Registration of Channel Binding TLS Exporter Label
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. References
6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.1. Normative References
6.2. Informative References . . . . . . . . . . . . . . . . . 7 6.2. Informative References
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address
1. Introduction 1. Introduction
The "tls-unique" channel binding type defined in [RFC5929] was found The "tls-unique" channel binding type defined in [RFC5929] was found
to be vulnerable to the "triple handshake vulnerability" to be susceptible to the "triple handshake vulnerability"
[TRIPLE-HANDSHAKE] without the extended master secret extension [TRIPLE-HANDSHAKE] without the extended master secret extension
defined in [RFC7627]. While TLS 1.3 uses a complete transcript hash defined in [RFC7627]. While TLS 1.3 uses a complete transcript hash
akin to the extended master secret procedures, the safety of channel akin to the extended master secret procedures, the safety of channel
bindings with TLS 1.3 was not analyzed as part of the core protocol bindings with TLS 1.3 was not analyzed as part of the core protocol
work, and so the specification of channel bindings for TLS 1.3 was work, so the specification of channel bindings for TLS 1.3 was
deferred. [RFC8446] section C.5 notes the lack of channel bindings deferred. Appendix C.5 of [RFC8446] notes the lack of channel
for TLS 1.3; this document defines such channel bindings, and fills bindings for TLS 1.3; this document defines such channel bindings and
that gap. Furthermore, this document updates [RFC5929] by adding an fills that gap. Furthermore, this document updates [RFC5929] by
additional unique channel binding type, "tls-exporter", that replaces adding an additional unique channel binding type, "tls-exporter",
some usage of "tls-unique". that replaces some usage of "tls-unique".
1.1. Conventions and Terminology 1.1. Conventions and Terminology
Throughout this document the acronym "EKM" is used to refer to Throughout this document, the acronym "EKM" is used to refer to
Exported Keying Material as defined in [RFC5705]. "Exported Keying Material" as defined in [RFC5705].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. The 'tls-exporter' Channel Binding Type 2. The 'tls-exporter' Channel Binding Type
Channel binding mechanisms are not useful until TLS implementations Channel binding mechanisms are not useful until TLS implementations
expose the required data. To facilitate this, "tls-exporter" uses expose the required data. To facilitate this, "tls-exporter" uses
exported keying material (EKM) which is already widely exposed by TLS Exported Keying Material (EKM), which is already widely exposed by
implementations. The EKM is obtained using the keying material TLS implementations. The EKM is obtained using the keying material
exporters for TLS as defined in [RFC5705] and [RFC8446] section 7.5 exporters for TLS, as defined in [RFC5705] and Section 7.5 of
by supplying the following inputs: [RFC8446], by supplying the following inputs:
Label: The ASCII string "EXPORTER-Channel-Binding" with no Label: The ASCII string "EXPORTER-Channel-Binding" with no
terminating NUL. terminating NUL.
Context value: Zero-length string. Context value: Zero-length string.
Length: 32 bytes. Length: 32 bytes.
This channel binding mechanism is defined only when the TLS handshake This channel binding mechanism is defined only when the TLS handshake
results in unique master secrets. This is true of TLS versions prior results in unique master secrets. This is true of TLS versions prior
to 1.3 when the extended master secret extension of [RFC7627] is in to 1.3 when the extended master secret extension of [RFC7627] is in
use, and is always true for TLS 1.3 (see [RFC8446] appendix D). use, and it is always true for TLS 1.3 (see Appendix D of [RFC8446]).
3. TLS 1.3 with SCRAM or GSS-API over SASL 3. TLS 1.3 with SCRAM or GSS-API over SASL
SCRAM ([RFC5802], and [RFC7677]) and GSS-API over SASL [RFC5801] The specifications for Salted Challenge Response Authentication
define "tls-unique" as the default channel binding to use over TLS. Mechanism (SCRAM) [RFC5802] [RFC7677] and Generic Security Service
As "tls-unique" is not defined for TLS 1.3 (and greater), this Application Program Interface (GSS-API) over Simple Authentication
document updates [RFC5801], [RFC5802], and [RFC7677] to use "tls- and Security Layer (SASL) [RFC5801] define "tls-unique" as the
exporter" as the default channel binding over TLS 1.3 (and greater). default channel binding to use over TLS. As "tls-unique" is not
Note that this document does not change the default channel binding defined for TLS 1.3 (and greater), this document updates [RFC5801],
for SCRAM mechanisms over TLS 1.2 [RFC5246], which is still "tls- [RFC5802], and [RFC7677] to use "tls-exporter" as the default channel
unique". binding over TLS 1.3 (and greater). Note that this document does not
change the default channel binding for SCRAM mechanisms over TLS 1.2
[RFC5246], which is still "tls-unique" (also note that RFC 5246 has
been obsoleted by RFC 8446).
Additionally, this document updates the aforementioned documents to Additionally, this document updates the aforementioned documents to
make "tls-exporter" the mandatory to implement channel binding if any make "tls-exporter" the mandatory-to-implement channel binding if any
channel bindings are implemented for TLS 1.3. Implementations that channel bindings are implemented for TLS 1.3. Implementations that
support channel binding over TLS 1.3 MUST implement "tls-exporter". support channel binding over TLS 1.3 MUST implement "tls-exporter".
4. Security Considerations 4. Security Considerations
The channel binding type defined in this document is constructed so The channel binding type defined in this document is constructed so
that disclosure of the channel binding data does not leak secret that disclosure of the channel binding data does not leak secret
information about the TLS channel and does not affect the security of information about the TLS channel and does not affect the security of
the TLS channel. the TLS channel.
skipping to change at page 4, line 13 skipping to change at line 151
information. information.
The Security Considerations sections of [RFC5056], [RFC5705], and The Security Considerations sections of [RFC5056], [RFC5705], and
[RFC8446] apply to this document. [RFC8446] apply to this document.
4.1. Uniqueness of Channel Bindings 4.1. Uniqueness of Channel Bindings
The definition of channel bindings in [RFC5056] defines the concept The definition of channel bindings in [RFC5056] defines the concept
of a "unique" channel binding as being one that is unique to the of a "unique" channel binding as being one that is unique to the
channel endpoints and unique over time, that is, a value that is channel endpoints and unique over time, that is, a value that is
unique to a specific instance of the lower layer security protocol. unique to a specific instance of the lower-layer security protocol.
When TLS is the lower layer security protocol, as for the channel When TLS is the lower-layer security protocol, as for the channel
binding type defined in this document, this concept of uniqueness binding type defined in this document, this concept of uniqueness
corresponds to uniquely identifying the specific TLS connection. corresponds to uniquely identifying the specific TLS connection.
However, a stronger form of uniqueness is possible, which would However, a stronger form of uniqueness is possible, which would
entail uniquely identifying not just the lower layer protocol but entail uniquely identifying not just the lower-layer protocol but
also the upper layer application or authentication protocol that is also the upper-layer application or authentication protocol that is
consuming the channel binding. The distinction is relevant only when consuming the channel binding. The distinction is relevant only when
there are multiple instances of an authentication protocol, or there are multiple instances of an authentication protocol, or
multiple distinct authentication protocols, that run atop the same multiple distinct authentication protocols, that run atop the same
lower layer protocol. Such a situation is rare -- most consumers of lower-layer protocol. Such a situation is rare; most consumers of
channel bindings establish an instance of the lower layer secure channel bindings establish an instance of the lower-layer secure
protocol, run a single application or authentication protocol as the protocol, run a single application or authentication protocol as the
upper layer protocol, then terminate both upper and lower layer upper-layer protocol, then terminate both upper and lower-layer
protocols. In this situation the stronger form of uniqueness is protocols. In this situation, the stronger form of uniqueness is
trivially achieved, given that the channel binding value is unique in trivially achieved, given that the channel binding value is unique in
the sense of [RFC5056]. the sense of [RFC5056].
The channel binding type defined by this document provides only the The channel binding type defined by this document provides only the
weaker type of uniqueness, as per [RFC5056]; it does not achieve the weaker type of uniqueness, as per [RFC5056]; it does not achieve the
stronger uniqueness per upper layer protocol instance described stronger uniqueness per the upper-layer protocol instance described
above. This stronger form of uniqueness would be useful in that it above. This stronger form of uniqueness would be useful in that it
provides protection against cross-protocol attacks for the multiple provides protection against cross-protocol attacks for the multiple
authentication protocols running over the same instance of the lower authentication protocols running over the same instance of the lower-
layer protocol, and it provides protection against replay attacks layer protocol, and it provides protection against replay attacks
that seek to replay a message from one instance of an authentication that seek to replay a message from one instance of an authentication
protocol in a different instance of the same authentication protocol, protocol in a different instance of the same authentication protocol,
again running over the same instance of the lower layer protocol. again running over the same instance of the lower-layer protocol.
Both of these properties are highly desirable when performing formal Both of these properties are highly desirable when performing formal
analysis of upper layer protocols; if these properties are not analysis of upper-layer protocols; if these properties are not
provided, such formal analysis is essentially impossible. In some provided, such formal analysis is essentially impossible. In some
cases one or both of these properties may already be provided by cases, one or both of these properties may already be provided by
specific upper layer protocols, but that is dependent on the specific upper-layer protocols, but that is dependent on the
mechanism(s) in question, and formal analysis requires that the mechanism(s) in question, and formal analysis requires that the
property is provided in a generic manner, across all potential upper property is provided in a generic manner across all potential upper-
layer protocols that exist or might exist in the future. layer protocols that exist or might exist in the future.
Accordingly, applications that make use of the channel binding type Accordingly, applications that make use of the channel binding type
defined in this document MUST NOT use the channel binding for more defined in this document MUST NOT use the channel binding for more
than one authentication mechanism instance on a given TLS connection. than one authentication mechanism instance on a given TLS connection.
Such applications MUST immediately close the TLS connection after the Such applications MUST immediately close the TLS connection after the
conclusion of the upper layer protocol. conclusion of the upper-layer protocol.
4.2. Use with Legacy TLS 4.2. Use with Legacy TLS
While it is possible to use this channel binding mechanism with TLS While it is possible to use this channel binding mechanism with TLS
versions below 1.3, extra precaution must be taken to ensure that the versions below 1.3, extra precaution must be taken to ensure that the
chosen cipher suites always result in unique master secrets. For chosen cipher suites always result in unique master secrets. For
more information see [RFC7627] and the Security Considerations more information, see [RFC7627] and the Security Considerations
section of [RFC5705] (TLS 1.3 always provides unique master secrets, section of [RFC5705] (TLS 1.3 always provides unique master secrets,
as discussed in Appendix D of [RFC8446].) as discussed in Appendix D of [RFC8446]).
When TLS renegotiation is enabled on a connection the "tls-exporter" When TLS renegotiation is enabled on a connection, the "tls-exporter"
channel binding type is not defined for that connection and channel binding type is not defined for that connection, and
implementations MUST NOT support it. implementations MUST NOT support it.
In general, users wishing to take advantage of channel binding should In general, users wishing to take advantage of channel binding should
upgrade to TLS 1.3 or later. upgrade to TLS 1.3 or later.
5. IANA Considerations 5. IANA Considerations
5.1. Registration of Channel Binding Type 5.1. Registration of Channel Binding Type
This document adds the following registration in the "Channel-Binding IANA has registered tls-exporter in the "Channel-Binding Types"
Types" registry: registry:
Subject: Registration of channel binding tls-exporter
Channel binding unique prefix: tls-exporter Channel-binding unique prefix: tls-exporter
Channel binding type: unique Channel-binding type: unique
Channel type: TLS [RFC8446] Channel type: TLS [RFC8446]
Published specification: draft-ietf-kitten-tls-channel-bindings-for- Published specification: RFC 9266
tls13-16
Channel binding is secret: no Channel-binding is secret: no
Description: The EKM value obtained from the current TLS connection. Description: The EKM value obtained from the current TLS connection.
Intended usage: COMMON Intended usage: COMMON
Person and email address to contact for further information: Sam Person and email address to contact for further information: Sam
Whited <sam@samwhited.com>. Whited <sam@samwhited.com>
Owner/Change controller name and email address: IESG. Owner/Change controller name and email address: IESG
Expert reviewer name and contact information: IETF KITTEN or TLS WG Expert reviewer name and contact information: IETF KITTEN WG
(kitten@ietf.org or tls@ietf.org, failing that, ietf@ietf.org). <kitten@ietf.org> or IETF TLS WG <tls@ietf.org>
Note: See the published specification for advice on the Note: See the published specification for advice on the
applicability of this channel binding type. applicability of this channel binding type.
5.2. Registration of Channel Binding TLS Exporter Label 5.2. Registration of Channel Binding TLS Exporter Label
This document adds the following registration in the "TLS Exporter IANA has added the following registration in the "TLS Exporter
Labels" registry, which is part of the "Transport Layer Security Labels" registry under the "Transport Layer Security (TLS)
(TLS) Parameters" group: Parameters" registry:
Value: EXPORTER-Channel-Binding Value: EXPORTER-Channel-Binding
DTLS-OK: Y DTLS-OK: Y
Recommended: Y Recommended: Y
Reference: This document Reference: RFC 9266
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 7, line 43 skipping to change at line 318
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS) Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015, RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>. <https://www.rfc-editor.org/info/rfc7627>.
[TRIPLE-HANDSHAKE] [TRIPLE-HANDSHAKE]
Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
A., and P. Strub, "Password Storage", March 2014, A., and P. Strub, "Triple Handshakes Considered Harmful:
Breaking and Fixing Authentication over TLS", March 2014,
<https://www.mitls.org/pages/attacks/3SHAKE>. <https://www.mitls.org/pages/attacks/3SHAKE>.
Author's Address Author's Address
Sam Whited Sam Whited
Atlanta, GA Atlanta, GA
United States of America United States of America
Email: sam@samwhited.com Email: sam@samwhited.com
URI: https://blog.samwhited.com/ URI: https://blog.samwhited.com/
 End of changes. 42 change blocks. 
107 lines changed or deleted 106 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/