Internet-Draft | PAKE Usage in TLS 1.3 | September 2024 |
Guo, et al. | Expires 3 April 2025 | [Page] |
This document provides a mechanism that uses password-authenticated key exchange (PAKE) as an authentication and key establishment in TLS 1.3, and that supports PAKE algorithms negotiation.¶
This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 April 2025.¶
Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In some applications, it is desirable to use a pre-shared low-entropy secret, such as a password, to authenticate with each other between a client and a server. Although TLS 1.3 [RFC8446] itself provides an authentication mechanism of pre-shared keys (PSKs), PSKs need to be full-entropy secrets. If a low-entropy password is directly used in this authentication mechanism, then the PSK binder values can be used by a passive adversary to mount an offline dictionary attack on the password, and even if without the PSK binder and the PSK mechanism is combined with Diffie-Hellman (DH) key establishment, an active adversary can still offline enumerate the password through a man-in-the-middle (MITM) attack.¶
Note that there are already some early works about PAKE usage in TLS: the Secure Remote Password (SRP) PAKE protocol has been integrated in prior versions of TLS [RFC5054], but it does not extend to later TLS 1.3; the Dragonfly PAKE protocol has also been integrated in both prior versions of TLS and the latest TLS 1.3 [RFC8492]; the integration of the OPAQUE [I-D.draft-irtf-cfrg-opaque-17] PAKE protocol with TLS 1.3 has been presented in [I-D.draft-sullivan-tls-opaque-01]. However, they all do not consider PAKE algorithms negotiation, which is very important in practice, because some algorithms may be broken in the future and we need some way to negotiate new algorithms. Although PAKE algorithms negotiation has been mentioned in [I-D.draft-barnes-tls-pake-04], it only persents the integration of the SPAKE2+ [RFC9383] PAKE protocol with TLS 1.3 assuming that the PAKE algorithm has been negotiated in advance. This document provides a mechanism that uses PAKE as an authentication and key establishment in TLS 1.3, which supports PAKE algorithms negotiation.¶
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.¶
This document uses terminology such as client, server, connection, handshake, endpoint, and peer that are defined in Section 1.1 of [RFC8446].¶
This section describes details about PAKE usage in TLS 1.3.¶
To use PAKE as an authentication and key establishment mechanism in TLS 1.3, we define three TLS extensions: "pake_algorithms", "pake_share" and "pake_auth_modes".¶
The "pake_algorithms" extension indicates all the PAKE algorithm suites supported by the client, it can only appear in ClientHello and EncryptedExtension messages, otherwise peers MUST abort the handshake with an "illegal_parameter" alert.¶
The "pake_share" extension indicates the specific parameters of PAKE key exchange between both parties, it can only appear in ClientHello, ServerHello, and HelloRetryRequest messages, otherwise peers MUST abort the handshake with an "illegal_parameter" alert.¶
The "pake_auth_modes" extension indicates the mode of PAKE authentication for the server, it can only appear in ClientHello and ServerHello messages, otherwise peers MUST abort the handshake with an "illegal_parameter" alert.¶
When sent by the client, the "pake_algorithms" extension indicates PAKE algorithms which the client supports for authenticated key exchange, ordered from most preferred to least preferred.¶
The "extension_data" field of this extension contains a "PAKEAlgorithmList" value:¶
enum { /* Balanced PAKE algorithms */ 0x0000~0x3FFF /* Augmented PAKE algorithms */ 0x4000~0x7FFF /* Post-Quantum Balanced PAKE algorithms */ 0x8000~0xBFFF /* Post-Quantum Augmented PAKE algorithms */ 0xC000~0xFFFF (0xFFFF) } PAKEAlgorithm;¶
struct { PAKEAlgorithm supported_pake_algorithms<2..2^16-1>; } PAKEAlgorithmList;¶
Here, each PAKE algorithm suite consists of two part, the first part is represented by the first byte and specifies different PAKE algorithms, and the second part is represented by the second byte and specifies different ciphersuites for the fixed PAKE algorithm. For example, the first bytes "0x00" and "0x01" represent CPace [I-D.draft-irtf-cfrg-cpace-12] and SPAKE2 [RFC9382], respectively; and the first bytes "0x40" and "0x41" represent OPAQUE [I-D.draft-irtf-cfrg-opaque-17] and SPAKE2+ [RFC9383], respectively. For the SPAKE2+ algorithm with the first byte "0x41", the second bytes "0x00~0xFF" can be used to represent its different ciphersuites (see Section 4 of [RFC9383]).¶
As of TLS 1.3, servers are permitted to send the "pake_algorithms" extension to the client. Clients MUST NOT act upon any information found in "pake_algorithms" prior to successful completion of the handshake but MAY use the information learned from a successfully completed handshake to change what PAKE algorithms they use in their "pake_share" extension in subsequent connections. If the server has a PAKE algorithm it prefers to the ones in the "pake_share" extension but is still willing to accept the ClientHello, it SHOULD send "pake_algorithms" to update the client’s view of its preferences; this extension SHOULD contain all PAKE algorithms the server supports, regardless of whether they are currently supported by the client.¶
In order to use PAKE, clients MUST also send a "pake_auth_modes" extension. The semantics of this extension are that the client wants to identify which authentication modes will be used, and its content MAY be multiple authentication modes. The "extension_data" field of this extension contains a "PAKEAuthModes" value:¶
enum { pake_auth (0), pake_certificate_auth (1), (255) } PAKEAuthMode;¶
struct { PAKEAuthMode auth_modes<1..255>; } PAKEAuthModes;¶
The "pake_auth" mode indicates PAKE-only authentication. In this mode, the server MUST NOT send the Certificate, CertificateVerify and CertificateRequest messages. The "pake_certificate_auth" mode indicates PAKE authentication combined with certificate authentication. In this mode, the server MUST send the Certificate and CertificateVerify messages to conduct certificate-based server authentication, and optionally sends the CertificateRequest message if certificate-based client authentication is desired.¶
A client MUST provide a "pake_auth_modes" extension if it offers "pake_algorithms" and "pake_share" extensions. If clients offer "pake_algorithms" and "pake_share" without a "pake_auth_modes" extension, servers MUST abort the handshake with an "illegal_parameter" alert. Servers MUST provide only one authentication mode in the "pake_auth_modes" extension to unambiguously identify which mode was selected, but MUST NOT select an authentication mode that is not listed by the client. If servers offer "pake_share" without a "pake_auth_modes" extension, clients MUST abort the handshake with an "illegal_parameter" alert.¶
Based on the PAKE parameters exchanged in the ClientHello and ServerHello, the client and server execute the negotiated PAKE protocol to derive a PAKE shared secret. This secret is used as the "(EC)DHE" input to the TLS 1.3 key schedule, and the remaining process of the key schedule is unchanged.¶
In this mechanism, PAKEs are used for both password authentication and key establishment, the derived PAKE shared secret is fed into the TLS 1.3 key schedule, and PAKE-based authentication is finally confirmed by the validation of the Finished message.¶
Note that PAKE-based authentication is compatible with server-side certificate authentication. If the client specifies a "pake_auth" mode in the "pake_auth_modes" extension, then the server does not need to send Certificate and CertificateVerify messages, and only needs to send a Finished message to perform server-side PAKE authentication. If the client specifies a "pake_certificate_auth" mode in the "pake_auth_modes" extension, or specifies "pake_auth" and "pake_certificate_auth" modes and the server selects the latter one, then the server needs to send Certificate and CertificateVerify messages to conduct server-side certificate authentication, and send a Finished message to perform server-side PAKE authentication.¶
PAKE-based authentication is also compatible with client-side certificate authentication, because the server can optionally send a CertificateRequest message to the client. If the client receives a CertificateRequest message, it needs to send Certificate and CertificateVerify messages to conduct client-side certificate authentication, and send a Finished message to perform client-side PAKE authentication; otherwise only the Finished message needs to be sent.¶
This document defines three new TLS extension types "pake_algorithms", "pake_share" and "pake_auths" with the following contents (see Table 1), and requests that IANA add the three values to the "TLS ExtensionType Values" Registry defined in [RFC8446] and [RFC8447].¶
Value | Extension Name | TLS 1.3 | Reference |
---|---|---|---|
TBD1 | pake_algorithms | CH, EE | PRF XXXX |
TBD2 | pake_share | CH, SH, HRR | PRF XXXX |
TBD3 | pake_auth_modes | CH, SH | PRF XXXX |