TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key
RFC 8773
Document | Type | RFC - Experimental (March 2020; No errata) | |
---|---|---|---|
Author | Russ Housley | ||
Last updated | 2020-03-29 | ||
Replaces | draft-housley-tls-tls13-cert-with-extern-psk | ||
Stream | IETF | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Joseph Salowey | ||
Shepherd write-up | Show (last changed 2019-07-01) | ||
IESG | IESG state | RFC 8773 (Experimental) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Benjamin Kaduk | ||
Send notices to | Joseph Salowey <joe@salowey.net> | ||
IANA | IANA review state | IANA OK - Actions Needed | |
IANA action state | RFC-Ed-Ack | ||
IANA expert review state | Expert Reviews OK | ||
IANA expert review comments | Registration has been made. |
Internet Engineering Task Force (IETF) R. Housley Request for Comments: 8773 Vigil Security Category: Experimental March 2020 ISSN: 2070-1721 TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key Abstract This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see 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/rfc8773. Copyright Notice Copyright (c) 2020 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. Table of Contents 1. Introduction 2. Terminology 3. Motivation and Design Rationale 4. Extension Overview 5. Certificate with External PSK Extension 5.1. Companion Extensions 5.2. Authentication 5.3. Keying Material 6. IANA Considerations 7. Security Considerations 8. Privacy Considerations 9. References 9.1. Normative References 9.2. Informative References Acknowledgments Author's Address 1. Introduction The TLS 1.3 [RFC8446] handshake protocol provides two mutually exclusive forms of server authentication. First, the server can be authenticated by providing a signature certificate and creating a valid digital signature to demonstrate that it possesses the corresponding private key. Second, the server can be authenticated by demonstrating that it possesses a pre-shared key (PSK) that was established by a previous handshake. A PSK that is established in this fashion is called a resumption PSK. A PSK that is established by any other means is called an external PSK. This document specifies a TLS 1.3 extension permitting certificate-based server authentication to be combined with an external PSK as an input to the TLS 1.3 key schedule. Several implementors wanted to gain more experience with this specification before producing a Standards Track RFC. As a result, this specification is being published as an Experimental RFC to enable interoperable implementations and gain deployment and operational experience. 2. Terminology 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. 3. Motivation and Design Rationale The development of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today, including the digital signature algorithms that are used to authenticate the server in the TLS 1.3 handshake protocol. It is an open question whether or not it is feasible to build a large-scale quantum computer, and if so, when that might happen. However, if such a quantum computer is invented, many of the cryptographic algorithms and the security protocols that use them would become vulnerable. The TLS 1.3 handshake protocol employs key agreement algorithms and digital signature algorithms that could be broken by the development of a large-scale quantum computer [TRANSITION]. The key agreement algorithms include Diffie-Hellman (DH) [DH1976] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital signature algorithms include RSA [RFC8017] and the Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS186]. As a result, an adversary that stores aShow full document text