summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8472.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8472.txt')
-rw-r--r--doc/rfc/rfc8472.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc8472.txt b/doc/rfc/rfc8472.txt
new file mode 100644
index 0000000..a0a8f8f
--- /dev/null
+++ b/doc/rfc/rfc8472.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Popov, Ed.
+Request for Comments: 8472 M. Nystroem
+Category: Standards Track Microsoft Corp.
+ISSN: 2070-1721 D. Balfanz
+ Google Inc.
+ October 2018
+
+
+ Transport Layer Security (TLS) Extension for
+ Token Binding Protocol Negotiation
+
+Abstract
+
+ This document specifies a Transport Layer Security (TLS) extension
+ for the negotiation of Token Binding protocol version and key
+ parameters. Negotiation of Token Binding in TLS 1.3 and later
+ versions is beyond the scope of this document.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ 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/rfc8472.
+
+Copyright Notice
+
+ Copyright (c) 2018 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
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+Popov, et al. Standards Track [Page 1]
+
+RFC 8472 Token Binding Negotiation TLS Extension October 2018
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
+ 2. Token Binding Negotiation ClientHello Extension . . . . . . . 2
+ 3. Token Binding Negotiation ServerHello Extension . . . . . . . 3
+ 4. Negotiating Token Binding Protocol Version and Key Parameters 4
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
+ 6.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 6
+ 6.2. Triple Handshake Vulnerability in TLS 1.2 and Older TLS
+ Versions . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 7
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
+
+1. Introduction
+
+ In order to use the Token Binding protocol [RFC8471], the client and
+ server need to agree on the Token Binding protocol version and the
+ parameters (signature algorithm and length) of the Token Binding key.
+ This document specifies a new TLS [RFC5246] extension to accomplish
+ this negotiation without introducing additional network round trips
+ in TLS 1.2 and earlier versions. [TOKENBIND-TLS13] addresses Token
+ Binding in TLS 1.3. The negotiation of the Token Binding protocol
+ and key parameters in combination with TLS 1.3 and later versions is
+ beyond the scope of this document. (Note: This document deals with
+ TLS 1.2 and therefore refers to RFC 5246 (which has been obsoleted by
+ RFC 8446). [TOKENBIND-TLS13] addresses Token Binding in TLS 1.3).
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. Token Binding Negotiation ClientHello Extension
+
+ The client uses the "token_binding" TLS extension to indicate the
+ highest supported Token Binding protocol version and key parameters.
+
+ enum {
+ token_binding(24), (65535)
+ } ExtensionType;
+
+
+
+Popov, et al. Standards Track [Page 2]
+
+RFC 8472 Token Binding Negotiation TLS Extension October 2018
+
+
+ The "extension_data" field of this extension contains a
+ "TokenBindingParameters" value.
+
+ struct {
+ uint8 major;
+ uint8 minor;
+ } TB_ProtocolVersion;
+
+ enum {
+ rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255)
+ } TokenBindingKeyParameters;
+
+ struct {
+ TB_ProtocolVersion token_binding_version;
+ TokenBindingKeyParameters key_parameters_list<1..2^8-1>
+ } TokenBindingParameters;
+
+ "token_binding_version" indicates the version of the Token Binding
+ protocol the client wishes to use during this connection. If the
+ client supports multiple Token Binding protocol versions, it SHOULD
+ indicate the latest supported version (the one with the highest
+ TB_ProtocolVersion.major and TB_ProtocolVersion.minor) in
+ TokenBindingParameters.token_binding_version. For example, if the
+ client supports versions {1, 0} and {0, 13} of the Token Binding
+ protocol, it SHOULD indicate version {1, 0}. Please note that the
+ server MAY select any lower protocol version; see Section 3
+ ("Token Binding Negotiation ServerHello Extension") for more details.
+ If the client does not support the Token Binding protocol version
+ selected by the server, then the connection proceeds without Token
+ Binding. [RFC8471] describes version {1, 0} of the protocol.
+
+ Please note that the representation of the Token Binding protocol
+ version using two octets ("major" and "minor") is for human
+ convenience only and carries no protocol significance.
+
+ "key_parameters_list" contains the list of identifiers of the Token
+ Binding key parameters supported by the client, in descending order
+ of preference. [RFC8471] establishes an IANA registry for Token
+ Binding key parameters identifiers.
+
+3. Token Binding Negotiation ServerHello Extension
+
+ The server uses the "token_binding" TLS extension to indicate support
+ for the Token Binding protocol and to select the protocol version and
+ key parameters.
+
+
+
+
+
+
+Popov, et al. Standards Track [Page 3]
+
+RFC 8472 Token Binding Negotiation TLS Extension October 2018
+
+
+ The server that supports Token Binding and receives a ClientHello
+ message containing the "token_binding" extension will include the
+ "token_binding" extension in the ServerHello if all of the following
+ conditions are satisfied:
+
+ 1. The server supports the Token Binding protocol version offered by
+ the client, or a lower version.
+
+ 2. The server finds acceptable Token Binding key parameters in the
+ client's list.
+
+ 3. The server is also negotiating the extended master secret
+ [RFC7627] and renegotiation indication [RFC5746] TLS extensions.
+ This requirement applies when TLS 1.2 or an older TLS version is
+ used (see Section 6 ("Security Considerations") for more
+ details).
+
+ The server will ignore any key parameters that it does not recognize.
+ The "extension_data" field of the "token_binding" extension is
+ structured the same as described above for the client
+ "extension_data".
+
+ "token_binding_version" contains the lower of:
+
+ o the Token Binding protocol version offered by the client in the
+ "token_binding" extension, and
+
+ o the highest Token Binding protocol version supported by the
+ server.
+
+ "key_parameters_list" contains exactly one Token Binding key
+ parameters identifier selected by the server from the client's list.
+
+4. Negotiating Token Binding Protocol Version and Key Parameters
+
+ It is expected that a server will have a list of Token Binding key
+ parameters identifiers that it supports, in preference order. The
+ server MUST only select an identifier that the client offered. The
+ server SHOULD select the most highly preferred key parameters
+ identifier it supports, which is also advertised by the client. In
+ the event that the server supports none of the key parameters that
+ the client advertises, then the server MUST NOT include the
+ "token_binding" extension in the ServerHello.
+
+
+
+
+
+
+
+
+Popov, et al. Standards Track [Page 4]
+
+RFC 8472 Token Binding Negotiation TLS Extension October 2018
+
+
+ The client receiving the "token_binding" extension MUST terminate the
+ handshake with a fatal "unsupported_extension" alert if any of the
+ following conditions are true:
+
+ 1. The client did not include the "token_binding" extension in the
+ ClientHello.
+
+ 2. "token_binding_version" is higher than the Token Binding protocol
+ version advertised by the client.
+
+ 3. "key_parameters_list" includes more than one Token Binding key
+ parameters identifier.
+
+ 4. "key_parameters_list" includes an identifier that was not
+ advertised by the client.
+
+ 5. TLS 1.2 or an older TLS version is used, but the extended master
+ secret [RFC7627] and TLS renegotiation indication [RFC5746]
+ extensions are not negotiated (see Section 6
+ ("Security Considerations") for more details).
+
+ If the "token_binding" extension is included in the ServerHello and
+ the client supports the Token Binding protocol version selected by
+ the server, it means that the version and key parameters have been
+ negotiated between the client and the server and SHALL be definitive
+ for the TLS connection. TLS 1.2 and earlier versions support
+ renegotiation, which allows the client and server to renegotiate the
+ Token Binding protocol version and key parameters on the same
+ connection. The client MUST use the negotiated key parameters in the
+ "provided_token_binding" as described in [RFC8471].
+
+ If the client does not support the Token Binding protocol version
+ selected by the server, then the connection proceeds without Token
+ Binding. There is no requirement for the client to support any Token
+ Binding versions other than the one advertised in the client's
+ "token_binding" extension.
+
+ Client and server applications can choose to handle failure to
+ negotiate Token Binding in a variety of ways: continue using the
+ connection as usual, shorten the lifetime of tokens issued during
+ this connection, require stronger authentication, terminate the
+ connection, etc.
+
+ The Token Binding protocol version and key parameters are negotiated
+ for each TLS connection, which means that the client and server
+ include their "token_binding" extensions in both the full TLS
+ handshake that establishes a new TLS session and the subsequent
+ abbreviated TLS handshakes that resume the TLS session.
+
+
+
+Popov, et al. Standards Track [Page 5]
+
+RFC 8472 Token Binding Negotiation TLS Extension October 2018
+
+
+5. IANA Considerations
+
+ This document updates the "TLS ExtensionType Values" registry. The
+ registration for the "token_binding" TLS extension is as follows:
+
+ Value: 24
+
+ Extension name: token_binding
+
+ Recommended: Yes
+
+ Reference: This document
+
+ This document uses the "Token Binding Key Parameters" registry
+ created by [RFC8471]. This document creates no new registrations in
+ the registry.
+
+6. Security Considerations
+
+6.1. Downgrade Attacks
+
+ The Token Binding protocol version and key parameters are negotiated
+ via the "token_binding" extension within the TLS handshake. TLS
+ detects handshake message modification by active attackers;
+ therefore, it is not possible for an attacker to remove or modify the
+ "token_binding" extension without breaking the TLS handshake. The
+ signature algorithm and key length used in the Token Binding of type
+ "provided_token_binding" MUST match the parameters negotiated via the
+ "token_binding" extension.
+
+6.2. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions
+
+ The Token Binding protocol relies on the TLS exporters [RFC5705] to
+ associate a TLS connection with a Token Binding. The triple
+ handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and
+ older TLS versions; it allows an attacker to synchronize keying
+ material between TLS connections. The attacker can then successfully
+ replay bound tokens. For this reason, the Token Binding protocol
+ MUST NOT be negotiated with these TLS versions, unless the extended
+ master secret [RFC7627] and renegotiation indication [RFC5746] TLS
+ extensions have also been negotiated.
+
+
+
+
+
+
+
+
+
+
+Popov, et al. Standards Track [Page 6]
+
+RFC 8472 Token Binding Negotiation TLS Extension October 2018
+
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246,
+ DOI 10.17487/RFC5246, August 2008,
+ <https://www.rfc-editor.org/info/rfc5246>.
+
+ [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
+ Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
+ March 2010, <https://www.rfc-editor.org/info/rfc5705>.
+
+ [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
+ "Transport Layer Security (TLS) Renegotiation Indication
+ Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
+ <https://www.rfc-editor.org/info/rfc5746>.
+
+ [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
+ Langley, A., and M. Ray, "Transport Layer Security (TLS)
+ Session Hash and Extended Master Secret Extension",
+ RFC 7627, DOI 10.17487/RFC7627, September 2015,
+ <https://www.rfc-editor.org/info/rfc7627>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges,
+ "The Token Binding Protocol Version 1.0", RFC 8471,
+ DOI 10.17487/RFC8471, October 2018,
+ <https://www.rfc-editor.org/info/rfc8471>.
+
+7.2. Informative References
+
+ [TOKENBIND-TLS13]
+ Harper, N., "Token Binding for Transport Layer Security
+ (TLS) Version 1.3 Connections", Work in Progress,
+ draft-ietf-tokbind-tls13-01, May 2018.
+
+
+
+
+
+
+
+Popov, et al. Standards Track [Page 7]
+
+RFC 8472 Token Binding Negotiation TLS Extension October 2018
+
+
+ [TRIPLE-HS]
+ Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
+ A., and P. Strub, "Triple Handshakes and Cookie Cutters:
+ Breaking and Fixing Authentication over TLS", IEEE
+ Symposium on Security and Privacy, DOI 10.1109/SP.2014.14,
+ May 2014.
+
+Acknowledgements
+
+ This document incorporates comments and suggestions offered by Eric
+ Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony
+ Nadalin, Michael B. Jones, Bill Cox, Nick Harper, Brian Campbell,
+ Benjamin Kaduk, Alexey Melnikov, and others.
+
+ This document was produced under the chairmanship of John Bradley and
+ Leif Johansson. The area directors included Eric Rescorla, Kathleen
+ Moriarty, and Stephen Farrell.
+
+Authors' Addresses
+
+ Andrei Popov (editor)
+ Microsoft Corp.
+ United States of America
+
+ Email: andreipo@microsoft.com
+
+
+ Magnus Nystroem
+ Microsoft Corp.
+ United States of America
+
+ Email: mnystrom@microsoft.com
+
+
+ Dirk Balfanz
+ Google Inc.
+ United States of America
+
+ Email: balfanz@google.com
+
+
+
+
+
+
+
+
+
+
+
+
+Popov, et al. Standards Track [Page 8]
+