]> Huawei Technologies

guowei90@huawei.com

Huawei Technologies

frank.xialiang@huawei.com

Huawei Technologies

liji100@huawei.com

Huawei Technologies

Yong.Li1@huawei.com

General Internet Engineering Task Force keyword1 keyword2 keyword3 This document provides a mechanism that enables the use of password-authenticated key exchange (PAKE) with TLS Exported Authenticator, and that supports PAKE algorithm negotiation.

Introduction In some cases, it is desirable to enable one party and its peers of a TLS or DTLS connection to authenticate mutually using password-authenticated key exchange (PAKE) protocols after the connection has been established. This not only can defend against password leakages caused by PKI failures (e.g., phishing attacks) when passwords are transmitted in plaintext over the (D)TLS connection, but also can make changes to the TLS layer as small as possible when compared to using PAKEs to establish the (D)TLS connection. This strategy is often called defense-in-depth, the security of application-layer password authentication is still guaranteed even if some failures occur at the underlying (D)TLS layer. Note that the use of OPAQUE with Exported Authenticator has been discussed in . However, it does 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. This document provides a mechanism that uses a PAKE extension for (D)TLS Exported Authenticator to execute application-layer password authentication at any time after the (D)TLS handshake has completed, which supports PAKE algorithm negotiation. The minimum version of TLS and DTLS required to implement the mechanism described in this document are TLS 1.2 and DTLS 1.2 . (These were obsoleted by TLS 1.3 and DTLS 1.3 .)

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 Algorithm Negotiation This document defines a new TLS extension type "pake_algorithm". This extension can only appear in ClientHello and EncryptedExtensions messages, otherwise peers MUST abort the handshake with an "illegal_parameter" alert. The "extension_data" field of this extension contains a "PAKEAlgorithmList" value. ; } PAKEAlgorithmList; ]]> In this document, two PAKE algorithms are considered: SPAKE2 and SPAKE2+ . The former is a symmetric PAKE algorithm and the latter is an asymmetric PAKE algorithm. 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 some PAKE algorithm. For example, the first bytes "0x01" and "0x41" represent SPAKE2 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 ). The "pake_algorithm" extension MAY be included by the client in its ClientHello message, and the corresponding "extension_data" field contains a list of PAKE algorithm suites supported by the client, ordered from most preferred to least preferred. After receiving a ClientHello message containing the "pake_algorithm" extension, the server MAY return a suitable PAKE algorithm selection response to the client. The server will ignore any algorithm that it does not support. The "pake_algorithm" extension MAY be returned by the server in its EncryptedExtensions message, and the corresponding "extension_data" field MUST contain exactly one "PAKEAlgorithm". Therefore, a full handshake with the "pake_algorithm" extension in the ClientHello and EncryptedExtensions messages has the following flow (see ).

Message Flow for a Full TLS Handshake with the pake_algorithm Extension ServerHello ^ Key + key_share* v Exch {EncryptedExtensions} ^ + pake_algorithm | Server (selected algorithm) | Params {CertificateRequest*} v {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] ]]>

PAKE with TLS Exported Authenticator

TLS CertificateRequest Message Extension This document also defines a new TLS extension type "pake_share". This extension can only appear in CertificateRequest (or ClientCertificateRequest) message during Exported Authenticator-based post-handshake authentication, otherwise peers MUST abort the handshake with an "illegal_parameter" alert. 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, as shown below.

• The "dh_share" field indicates a (EC)DH public element that is determined by the specified PAKE algorithm and the underlying group. 1) for SPAKE2, this field indicates the value pA or pB in ; 2) for SPAKE2+, this field indicates the value shareP or shareV in .

(1) In a ClientCertificateRequest message, the "extension_data" field of this extension contains a "ClientPAKEShare" value. ; PAKEShareEntry client_share; } ClientPAKEShare; ]]>

• The "client_identity" field indicates a client's identity used in the PAKE algorithm.
• The "client_share" field contains a single "PAKEShareEntry" value, where the "pake_algorithm" field is set to the negotiated PAKE algorithm in the (D)TLS handshake.

(2) In a CertificateRequest message, the "extension_data" field of this extension contains a "ServerPAKEShare" value.

• The "server_share" field contains a single "PAKEShareEntry" value, where the "pake_algorithm" field is also set to the negotiated PAKE algorithm in the (D)TLS handshake.

Message Sequence Note that two messages are defined in : authenticator requests and authenticators. After the (D)TLS handshake (with the "pake_algorithm" extension) has completed, these messages can be combined in the following sequence to achieve PAKE-based mutual authentication at the application layer.

• The client generates an authenticator request (ClientCertificateRequest with the "pake_share" extension).
• The server generates an authenticator request (CertificateRequest with the "pake_share" extension) and an authenticator (server Finished) corresponding to the client's authenticator request.
• The client validates the server's authenticator and generates an authenticator (client Finished) corresponding to the server's authenticator request.
• The server validates the client's authenticator.

shows a full message sequence of using PAKE with TLS Exported Authenticator, followed by a detailed description.

Message Sequence of Using PAKE with TLS Exported Authenticator | | | | | | Authenticator Request (ClientCertificateRequest with pake_share) | |------------------------------------------------------------------->| | | | Authenticator Request (CertificateRequest with pake_share) | | Authenticator (server Finished) | |<-------------------------------------------------------------------| | | | Authenticator (client Finished) | |------------------------------------------------------------------->| | | ]]>

(1) When PAKE-based mutual authentication at the application layer needs to be performed, it is REQUIRED to generate a ClientCertificateRequest message. The client sets the "certificate_request_context" field to a randomly generated string, and sets the "pake_share" extension to a "ClientPAKEShare" value, where the "client_identity" is its identity used to authenticate and the "client_share" field is constructed by setting the negotiated PAKE algorithm suite and computing its corresponding PAKE share. The computation of PAKE share SHOULD conform to the specification of the used PAKE algorithm. The client then sends the ClientCertificateRequest message to the server. (2) After receiving the ClientCertificateRequest message, the server first parses it to obtain "certificate_request_context", "client_identity" and "client_share" fields, uses the "client_identity" value to search a match password or password file. To generate a CertificateRequest message, the server sets the "certificate_request_context" field to a randomly generated string, and sets the "pake_share" extension to a "ServerPAKEShare" value, where the "server_share" field is constructed by setting the negotiated PAKE algorithm suite and computing its corresponding PAKE share. Based on the received client's share and its own secret, the server first derives a PAKE shared secret, and then derives two keys as follows. Here, KDF(ikm, salt, info, L) and H(.) indicate the key-derivation function (KDF) and the hash function, respectively, which are negotiated in the PAKE algorithm suite; the PAKE shared secrets for different PAKEs are defined as follows:

• For SPAKE2, this secret indicates the concatenated value Ke || Ka in .
• For SPAKE2+, this secret indicates the value K_main in .

Then, the server computes its "Finished" value as follows, where the Handshake Context, Finished MAC Key, Hash are defined in and HMAC is defined in . Finally, the server sends the CertificateRequest and server Finished messages to the client. (3) After receiving the CertificateRequest and server Finished messages, the client first parses the former to obtain the "certificate_request_context" and "server_share" fields. Based on the received server's share and its own secret, the client derives a PAKE shared secret, and then derives two keys using the same way as the server side. The client then authenticates the server by verifying the server "Finished" value. If this verification succeeds, the client computes its "Finished" value as follows, and sends the client Finished message to the server. Otherwise, the client MAY terminate the (D)TLS connection. (4) After receiving the client Finished message, the server authenticates the client by verifying the client "Finished" value. If this verification succeeds, the server accepts the client's request at the application layer, otherwise rejects.

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

Value	Extension Name	TLS 1.3	Reference
TBD1	pake_algorithm	CH, EE	RFC XXXX
TBD2	pake_share	CR	RFC XXXX

References Normative References This document describes the OPAQUE protocol, an Augmented (or Asymmetric) Password-Authenticated Key Exchange (aPAKE) protocol 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. This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] 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 document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. 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 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. 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 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.

Contributors Hui Ye
Huawei Technologies
yehui.ustc@huawei.com Feng Geng
Huawei Technologies
gengfeng@huawei.com