doc: Add RFC documents

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]
+