]> Huawei Technologies

guowei90@huawei.com

Huawei Technologies

frank.xialiang@huawei.com

Huawei Technologies

liji100@huawei.com

General Internet Engineering Task Force keyword1 keyword2 keyword3 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.

Introduction 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 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 , 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 ; the integration of the OPAQUE PAKE protocol with TLS 1.3 has been presented in . 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 , it only persents the integration of the SPAKE2+ 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.

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 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 .

PAKE Usage in TLS 1.3 This section describes details about PAKE usage in TLS 1.3.

TLS Extensions 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.

PAKE Algorithms 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: ; } 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 and SPAKE2 , respectively; and the first bytes "0x40" and "0x41" represent OPAQUE and SPAKE2+ , 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 ). 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.

PAKE Share The "pake_share" extension contains the endpoint’s PAKE parameters. The "PAKEShareEntry" value is defined as follows: ; } PAKEShareEntry; ]]> The "pake_algorithm" field indicates the PAKE algorithm used. The "pake_message" field indicates the PAKE key exchange information, its contents are determined by the specified PAKE algorithm: Here, the "oprf_message" field indicates the "blinded_message" value or the "evaluated_message" value, which are defined in ; the "dh_share" field indicates a (EC)DH public element that is determined by the underlying group. (1) In the ClientHello message, the "extension_data" field of this extension contains a "PAKEShareClientHello" value: ; PAKEShareEntry client_shares<0..2^16-1>; PAKEExtension pake_extensions<0..2^16-1>; } PAKEShareClientHello; ]]> The "client_identity" field indicates a client's identity used in the PAKE algorithm. The "client_shares" field contains a list of offered PAKEShareEntry values in descending order of client preference. The "pake_extensions" field indicates a list of PAKE extensions allowed in the structure of PAKEShareClientHello, clients can use this field to send data to servers and request extended functionality from servers. The contents of "client_shares" field MAY be empty if the client is requesting a HelloRetryRequest. Each PAKEShareEntry value MUST correspond to a PAKE algorithm offered in the "pake_algorithms" extension and MUST appear in the same order. However, the values MAY be a non-contiguous subset of the "pake_algorithms" extension and MAY omit the most preferred PAKE algorithms. Such a situation could arise if the most preferred PAKE algorithms are new and unlikely to be supported in enough places to make pregenerating PAKE shares for them efficient. Clients can offer as many PAKEShareEntry values as the number of supported PAKE algorithms it is offering, each representing a single set of PAKE key exchange parameters. For instance, a client might offer shares for several PAKE algorithms. The "pake_message" values for each PAKEShareEntry MUST be generated independently. Clients MUST NOT offer multiple PAKEShareEntry values for the same PAKE algorithm. Clients MUST NOT offer any PAKEShareEntry values for PAKE algorithms not listed in the client’s "pake_algorithms" extension. Servers MAY check for violations of these rules and abort the handshake with an "illegal_parameter" alert if one is violated. In addition, servers MUST verify that (1) the list of client shares to see if there is one with the provided "client_identity" value, and (2) if the "pake_message" contents in the "client_shares" field are valid (e.g., valid group elements). If either of these checks fails, then servers MUST abort the handshake with an "illegal_parameter" alert. (2) In a HelloRetryRequest message, the "extension_data" field of this extension contains a "PAKEShareHelloRetryRequest" value: If a client receives a second HelloRetryRequest in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest), it MUST abort the handshake with an "unexpected_message" alert. Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that (1) the "selected_pake_algorithm" field corresponds to a PAKE algorithm which was provided in the "pake_algorithms" extension in the original ClientHello, and (2) the "selected_pake_algorithm" field does not correspond to a PAKE algorithm which was provided in the "pake_share" extension in the original ClientHello. If either of these checks fails, then the client MUST abort the handshake with an "illegal_parameter" alert. Otherwise, when sending the new ClientHello, the client MUST replace the original "pake_share" extension with one containing only a new PAKEShareEntry for the PAKE algorithm indicated in the "selected_pake_algorithm" field of the triggering HelloRetryRequest. (3) In a ServerHello message, the "extension_data" field of this extension contains a PAKEShareServerHello value: ; PAKEShareEntry server_share; PAKEExtension pake_extensions<0..2^16-1>; } PAKEShareServerHello; ]]> The "server_identity" field indicates a server's identity used in the PAKE algorithm. The "server_share" field contains a single PAKEShareEntry value that is in the same PAKE algorithm as one of the client’s shares. The "pake_extensions" field indicates a list of PAKE extensions allowed in the structure of PAKEShareServerHello, servers can use this field to send data to clients and provide extended functionality to clients. If using PAKE key establishment, servers offer exactly one PAKEShareEntry in the ServerHello. This value MUST be in the same PAKE algorithm as the PAKEShareEntry value offered by the client that the server has selected for the negotiated PAKE key exchange. Servers MUST NOT send a PAKEShareEntry for any PAKE algorithm not indicated in the client’s "pake_algorithms" extension. If using PAKE key establishment and a HelloRetryRequest containing a "pake_share" extension was received by the client, the client MUST verify that the selected PAKEAlgorithm in the ServerHello is the same as that in the HelloRetryRequest. If this check fails, the client MUST abort the handshake with an "illegal_parameter" alert. In addition, the client MUST verify that (1) the "server_identity" value to see if it is the target server's name, and (2) if the "pake_message" content in the "server_share" field is valid (e.g., a valid group element). If either of these checks fails, then the client MUST abort the handshake with an "illegal_parameter" alert. (4) In this document, we define a PAKEExtension structure and three PAKE extension types that SHOULD be used in some PAKE algorithms. ; } PAKEExtension; ]]> The "session_identifier" extension indicates a unique session identifier of the CPace algorithm (see ). This extension SHOULD only be presented in the structure of "PAKEShareClientHello" when the CPace algorithm is selected, and MUST NOT be used with other PAKE algorithms that don't need it. The "nonce" extension indicates the "client_nonce" value or "server_nonce" value in the OPAQUE algorithm (see ). This extension SHOULD only be presented in the structure of "PAKEShareClientHello" or "PAKEShareServerHello" when the OPAQUE algorithm is selected, and MUST NOT be used with other PAKE algorithms that don't need it. The "pake_extension_data" field of the "credential_response" extension contains a "CredentialResponse" structure without the "evaluated_message" field in the OPAQUE algorithm (see ). This extension SHOULD only be presented in the structure of "PAKEShareServerHello" when the OPAQUE algorithm is negotiated, and MUST NOT be used with other PAKE algorithms that don't need it.

PAKE Authentication Modes 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: ; } 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.

Key Schedule 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.

Authentication Messages 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.

IANA Considerations This document defines three new TLS extension types "pake_algorithms", "pake_share" and "pake_auths" with the following contents (see ), and requests that IANA add the three values to the "TLS ExtensionType Values" Registry defined in and . New TLS Extension Types

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

References Normative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. This memo provides information for the Internet community. This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificateless, secure authentication using only a simple, low-entropy password. The exchange is called "TLS-PWD". The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to offline dictionary attacks. This document describes SPAKE2+, a Password-Authenticated Key Exchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime-order group, and computationally efficient. This document was produced outside of the IETF and IRTF and represents the opinions of the authors. Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement of SPAKE2+ by the IETF or IRTF. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes SPAKE2, which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password. This method is compatible with any group, is computationally efficient, and has a security proof. This document predated the Crypto Forum Research Group (CFRG) password-authenticated key exchange (PAKE) competition, and it was not selected; however, given existing use of variants in Kerberos and other applications, it was felt that publication was beneficial. Applications that need a symmetric PAKE, but are unable to hash onto an elliptic curve at execution time, can use SPAKE2. This document is a product of the Crypto Forum Research Group in the Internet Research Task Force (IRTF). This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. Informative References AWS Meta Cloudflare, Inc. This document describes the OPAQUE protocol, an augmented (or asymmetric) password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol and one instantiation based on 3DH. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Cloudflare IBM Research Cisco Cisco This document describes two mechanisms for enabling the use of the OPAQUE password-authenticated key exchange in TLS 1.3. Cisco Cisco The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. Nexus - San Francisco Endress + Hauser Liquid Analysis - Gerlingen IBM Research Europe - Zurich This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order.