A Password Authenticated Key Exchange Extension for TLS 1.3

5.1. Client Behavior

To offer support for a PAKE protocol, the client sends a pake extension in the ClientHello carrying a PAKEClientHello value:¶

enum {
    pake(0xTODO), (65535)
} ExtensionType;

The payload of the client extension has the following PAKEClientHello structure:¶

enum {
    SPAKE2PLUS_V1 (0xXXXX),
    CPACE_X25519_SHA512 (0xXXXX),
    OQUAKE_V1 (0xXXXX),
    OQUAKE_PLUS_V1 (0xXXXX),
} PAKEScheme;

struct {
    PAKEScheme   pake_scheme;
    opaque      pake_message<1..2^16-1>;
} PAKEShare;

struct {
    opaque    client_identity<0..2^16-1>;
    opaque    server_identity<0..2^16-1>;
    PAKEShare client_shares<0..2^16-1>;
} PAKEClientHello;

The PAKEClientHello structure consists of an identity pair under which the client can authenticate alongside a list of PAKE algorithms and the client's first message for each underlying PAKE protocol. Concretely, these structure fields are defined as follows:¶

client_shares

A list of PAKEShare values, each one with a distinct PAKEScheme algorithm.¶

client_identity

The client identity used for the PAKE. It may be empty.¶

server_identity

The server identity used for the PAKE. It may be empty.¶

pake_scheme

The 2-byte identifier of the PAKE algorithm.¶

pake_message

The client PAKE message used to initialize the protocol.¶

The client and server identity fields are common to all PAKEShares to prevent client enumeration attacks; see Section 9.¶

The PAKEScheme field in the PAKEShare allows implementations to support multiple PAKEs and negotiate which to use in the context of the handshake. For instance, if a client knows a password but not which PAKE the server supports it could send corresponding PAKEShares for each PAKE. If the client sends multiple PAKEShare values, then they MUST be sorted in monotonically increasing order by the NamedPAKE value. Moreover, the client MUST NOT send more than one PAKEShare with the same NamedPAKE value.¶

Section 9.2 of [TLS13] specifies that a valid ClientHello must include either a pre_shared_key extension or both a signature_algorithms and supported_groups extension. With the addition of the pake extension specified here, the new requirement is that a valid ClientHello must satisfy at least one of the following options:¶

• includes a pre_shared_key extension¶

• includes signature_algorithms, supported_groups, and key_share extensions¶

• includes pake, supported_groups, and key_share extensions¶

If a client sends the pake extension, then it MUST also send a supported_groups and key_share extension. Like PSK-based authentication in psk_dhe_ke mode as defined in Section 4.2.0 of [TLS13], authentication with the pake extension is always combined with the normal TLS key exchange mechanism. See Section 5.3 for details.¶

Combining the pake extension with the normal TLS key exchange mechanism using a hybrid or PQ key agreement protects against Harvest Now Decrypt Later Attacks where traffic recorded today may be decrypted by a Cryptographically Relevant Quantum Computer (CRQC) in the future. This protection covers the resulting application traffic regardless of which PAKEScheme is negotiated. It does not, by itself, protect the password: if the negotiated PAKEScheme is purely classical (e.g., SPAKE2+ or CPace), a future CRQC that breaks the scheme's underlying classical assumption can still retroactively recover the password from the harvested pake extension messages, independent of whether the surrounding TLS key exchange was hybrid or PQ. Deployments concerned with retroactive password recovery, as opposed to only traffic confidentiality, should select a post-quantum PAKEScheme, such as OQUAKE, OQUAKE+, or CPaceOQUAKE+; see the Security Considerations of [PQPAKE] for a detailed treatment of this distinction.¶

A client which sends both a pake and signature_algorithms extension indicates the client requires both PAKE authentication and standard server certificate authentication.¶

The client MAY also send a pre_shared_key extension along with the pake extension, to allow the server to choose an authentication mode.¶

The server identity value provided in the PAKEClientHello structure are disjoint from that which the client may provide in the ServerNameIndication (SNI) field.¶

5.2. Server Behavior

If a server receives a ClientHello with a pake extension, but without both asupported_group and key_share extension it MUST abort the connection with a "missing_extension" alert.¶

If a server receives a ClientHello with a pake extension and pre_shared_key extension then it must choose an authentication mechanism. In cases where client enumeration is a risk, servers SHOULD NOT inspect the offered client_identity fields in the pake extension when deciding between PAKE or PSK authentication since this could be used as an client enumeration tool.¶

A server that receives a pake extension examines its contents to determine if it is well-formed. In particular, if the list of PAKEShare values is not sorted in monotonically increasing order by PAKEScheme values, or if there are duplicate PAKEScheme entries in this list, the server aborts the handshake with an "illegal_parameter" alert.¶

If the list of PAKEShare values is well-formed, the server then scans the list of PAKEShare values to determine if there is one corresponding to a server supported PAKEScheme. If the server does not support any of the offered PAKESchemes in the client PAKEShares then the server MUST abort the protocol with an "illegal_parameter" alert.¶

If the server has a PAKEScheme in common with the client then the server uses the client_identity and server_identity alongside its local database of PAKE registration information to determine if the request corresponds to a legitimate client registration record. If one does not exist, the server MAY simulate a PAKE response as described in Section 5.4. Simulating a response prevents client enumeration attacks on the server's PAKE database; see Section 9.¶

If there exists a valid PAKE registration, the server indicates its selection by including a pake extension in its ServerHello. The content of this extension is a PAKEServerHello value, specifying the PAKE the server has selected, and the server's first message in the PAKE protocol. The format of this structure is as follows:¶

struct {
    PAKEShare server_share;
} PAKEServerHello;

The server_share value of this structure is a PAKEShare, which echoes back the PAKE algorithm chosen and the server's PAKE message generated in response to the client's PAKE message.¶

If a server uses PAKE authentication, then it MUST NOT send an extension of type pre_shared_key, or early_data.¶

Use of PAKE authentication MAY be used with certificate-based authentication of both clients and servers. If use of a PAKE is negotiated and the client included the signature_algorithms extension, then servers MUST include Certificate and CertificateVerify messages in the handshake. The server MAY send a CertificateRequest for client certificate authentication. See Section 9 for a discussion on different security considerations depending on if certificates are used or not.¶

5.3. Key Schedule Modifications

When the client and server agree on a PAKE to use, a shared secret derived from the PAKE protocol is concatenated with the regular ECDH(E) input and used as part of the ECDH(E) input to the TLS 1.3 key schedule. Details for the shared secret computation are left to the specific PAKE algorithm. See Section 6.2 and Section 6.3 for information about how the SPAKE2+ and CPace variants operate, respectively.¶

As with client authentication via certificates, the server has not authenticated the client until after it has received the client's Finished message. When a server negotiates the use of this mechanism for authentication, it SHOULD NOT send application data before it has received the client's Finished message, as it would otherwise be sending data to an unauthenticated client.¶

5.4. Server Simulation

To simulate a fake PAKE response, the server does the following:¶

• Select a PAKEScheme supported by the client and server, as normal.¶

• Include the pake extension in its ServerHello, containing a PAKEShare value with the selected PAKEScheme and corresponding pake_message. To generate the pake_message for this PAKEShare value, the server selects a value uniformly at random from the set of possible values of the PAKE algorithm shares.¶

• Perform the rest of the protocol as normal.¶

Because the server's share was selected uniformly at random, the server will reject the client's Finished message with overwhelming probability.¶

A server that performs the simulation of the protocol acts only as an all-or-nothing oracle for whether a given (identity, password) pair is correct. If an attacker does not supply a correct pair, they do not learn anything beyond this fact.¶

6.1. Requirements for Internal PAKEs

In order to be usable as Internal PAKEs with the pake extension, a PAKE protocol must specify some syntax for its messages, and the PAKE protocol MUST produce a shared secret in exactly two messages carried in the ClientHello and ServerHello. Internal PAKEs complete their authentication exchange within the TLS handshake and cannot require additional message rounds.¶

In addition, to be compatible with the security requirements of TLS 1.3, Internal PAKE protocols defined for use with TLS 1.3 MUST provide forward secrecy and MUST be able to achieve key confirmation via TLS 1.3 Finished messages.¶

A specification describing the use of a particular Internal PAKE protocol with TLS must provide the following details:¶

• A PAKEScheme registered value indicating pre-provisioned parameters;¶

• Content of the pake_message field in a ClientHello;¶

• Content of the pake_message field in a ServerHello;¶

• How the PAKE protocol is executed based on those messages; and¶

• How the outputs of the PAKE protocol are used to create the PAKE portion of the(EC)DHE input to the TLS key schedule.¶

Several current PAKE protocols satisfy these requirements for Internal PAKE usage, for example:¶

• CPace [CPACE]¶

• SPAKE2+ (described in Section 6.2) [RFC9383]¶

• OPAQUE [OPAQUE]¶

• OQUAKE (described in Section 6.4) [PQPAKE]¶

• OQUAKE+ (described in Section 6.5) [PQPAKE]¶

6.2. SPAKE2+ Integration

This section describes the SPAKE2+ instantiation of the pake extension for TLS. The SPAKE2+ protocol is described in [SPAKE2PLUS]. Section 6.2.1 describes the setup required before the protocol runs, and Section 6.2.2 describes the protocol execution in TLS.¶

                                    0
                                    |
                                    v
                        0 ->  HKDF-Extract = Early Secret
                                    |
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
                                    |
                                    v
                              Derive-Secret(., "derived", "")
                                    |
                                    v
                K_shared || (EC)DHE -> HKDF-Extract = Handshake Secret
                ^^^^^^^^^^^         |
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
                                    |
                                    v
                              Derive-Secret(., "derived", "")
                                    |
                                    v
                         0 -> HKDF-Extract = Master Secret
                                    |
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)
                                    +-----> Derive-Secret(...)

6.3. CPace Integration

This section describes the CPace instantiation of the pake extension for TLS. The CPace protocol is described in [CPACE]. Section 6.3.1 describes the setup required before the protocol runs, and Section 6.3.2 describes the protocol execution in TLS.¶

6.4. OQUAKE Integration

This section describes the OQUAKE instantiation of the pake extension for TLS. The OQUAKE protocol is a post-quantum symmetric PAKE described in [PQPAKE]. Section 6.4.1 describes the setup required before the protocol runs, and Section 6.4.2 describes the protocol execution in TLS.¶

6.5. OQUAKE+ Integration

This section describes the OQUAKE+ instantiation of the pake extension for TLS. OQUAKE+ is a post-quantum asymmetric PAKE (aPAKE) described in [PQPAKE]. Section 6.5.1 describes the setup required before the protocol runs, and Section 6.5.2 describes the protocol execution in TLS.¶

state, resp_msg = OQUAKE+.Respond(PRS, public_context, secret_context,
                                   init_msg, pk)

client_key, response = OQUAKE+.Finish(state, seed, resp_msg, public_context)

7.1. Overview

External PAKEs provide an alternative approach for applications requiring:¶

• Multi-round PAKE protocols: Protocols requiring more than two messages to complete authentication¶

• Complex hybrid constructions: Sequential combinations of multiple PAKE protocols¶

• Application-controlled channels: Direct control over communication channels and timing¶

• Separation of concerns: Clear boundary between PAKE execution and TLS connection establishment¶

External PAKEs execute their complete protocol exchange outside of TLS, then integrate with TLS through External PSK Import [RFC9258]. This approach enables protocols that cannot be constrained to the two-message limit of Internal PAKEs.¶

7.2. General Framework

External PAKE protocols must satisfy the following requirements:¶

• High-entropy output: Must derive a cryptographically strong shared secret¶

• PSK Import compatibility: Output must be suitable for External PSK Import per [RFC9258]¶

• Secure session binding: Must provide mechanism to correlate out-of-band execution with TLS connection¶

• Forward secrecy: Must provide forward secrecy properties appropriate to the application¶

The integration pattern for External PAKEs follows these phases:¶

1. Out-of-band PAKE execution: Complete PAKE protocol exchange using application-controlled channels¶

2. PSK derivation: Use External PSK Import to derive TLS PSK from PAKE output¶

3. TLS PSK connection: Establish TLS connection using standard PSK mechanisms¶

4. Session correlation: Verify proper binding between PAKE execution and TLS connection¶

7.3. CPaceOQUAKE+ Integration

This section describes how CPaceOQUAKE+, the hybrid aPAKE from [PQPAKE], can be realized using out-of-band PAKE execution followed by TLS integration via External PSK Import [RFC9258]. CPaceOQUAKE+ provides best-of-both-worlds security: it remains secure if either the classical assumptions underlying CPace or the post-quantum assumptions underlying OQUAKE+ hold.¶

Client                                Server
  |                                    |
  |-- CPace.Init --------------------->|
  |<-- CPace.Respond ------------------|
  | (both derive cpace_isk)            |
  |                                    |
  |-- OQUAKE+.Init ------------------->|
  |<-- OQUAKE+.Respond ----------------|
  | (both derive hybrid_secret)        |
  |                                    |
  | (both: external_psk = Import(hybrid_secret, "TLS 1.3 CPaceOQUAKE+ PSK", context))
  |                                    |
  |-- TLS ClientHello ---------------->|
  |    (with PSK extension)            |
  |<-- TLS ServerHello ----------------|
  |    (PSK selected)                  |
  |-- [TLS handshake completion] ----->|
  |<-- [TLS handshake completion] -----|

- client_cpace_msg = CPace.Init(password, identities)
- server_cpace_msg = CPace.Respond(client_cpace_msg, password, identities)
- cpace_isk = CPace.Finish(server_cpace_msg)  // Both parties derive ISK

- client_oquake_msg = OQUAKE+.Init(verifier, context=cpace_isk, identities)
- server_oquake_msg = OQUAKE+.Respond(client_oquake_msg, verifier, pk, context=cpace_isk)
- hybrid_secret = OQUAKE+.Finish(server_oquake_msg)  // Both parties derive final secret

- external_psk = Import(hybrid_secret, "TLS 1.3 CPaceOQUAKE+ PSK", context) // From RFC9258
- psk_identity = application_defined_identifier
- Standard TLS 1.3 PSK handshake using (external_psk, psk_identity)

9.1. Dictionary attack mitigation

Because PAKE security is based on knowledge of a low-entropy secret, an attacker can perform a "dictionary attack" by repeatedly attempting to guess the low-entropy secret.¶

Clients and servers SHOULD apply mitigations against dictionary attacks. Reasonable mitigations include rate-limiting authentication attempts, imposing a backoff time between attempts, limiting the number of failed attempts, or limiting the total number of attempts.¶

Clients SHOULD treat each time they receive an invalid PAKEServerHello as a failed authentication attempt for the identity in the previously sent PAKEClientHello. Servers SHOULD treat each time they send a PAKEServerHello extension as a failed authentication attempt for the selected identity, until they receive a correct Finished message from the client. Once the server receives a correct Finished message, the authentication attempt MAY be treated as successful.¶

9.2. Protection of client identities

Many of the security properties of this protocol will derive from the PAKE protocol being used. Security considerations for PAKE protocols are noted in Section 6.¶

If a server doesn't recognize the identity supplied by the client in the ClientHello pake extension, the server MAY abort the handshake with an "illegal_parameter" alert. In this case, the server acts as an oracle for identities, in which each handshake allows an attacker to learn whether the server recognizes a given identity.¶

Alternatively, if the server wishes to hide the fact that a client identity is unrecognized, the server MAY simulate the protocol as if an identity was recognized, but the password was incorrect. This is similar to the procedure outlined in [RFC5054]. The simulation mechanism is described in Section 5.4.¶

9.3. Ramifications of low entropy secret compromise

As with PSK based authentication, if only PAKE authentication is in use, then an attacker that learns the low entropy secret could impersonate either the client or the server. In situations where a notion of stable identity is available, then certificate-based authentication MAY be used as well to reduce this risk. For example, requiring the server to authenticate with a certificate in addition to PAKE authentication means an attacker that learns the password could only impersonate a client to a server, but could not impersonate a server to a client. This is an important distinction in situations where the client sends sensitive data to the server.¶

9.4. Internal PAKE Security Considerations

The following security considerations apply to Internal PAKEs that execute within the TLS handshake using the pake extension.¶

9.5. External PAKE Security Considerations

The following security considerations apply to External PAKEs that execute out-of-band prior to TLS connection establishment.¶

10.1. PAKE Scheme registry

This document requests that IANA create a new registry called "PAKE Schemes" for internal PAKEs (those negotiated with the PAKE extension) with the following contents:¶

The SPAKE2PLUS_V1 PAKEScheme variant has the following parameters associated with it:¶

• G: P-256¶

• Hash: SHA256¶

• KDF: HKDF-SHA256¶

• MAC: HMAC-SHA256¶

Additionally, it uses the M and N values from Section 4 of [SPAKE2PLUS], included below, as compressed points on the P-256 curve, for completeness.¶

M =
02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f

N =
03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49

The CPACE_X25519_SHA512 PAKEScheme variant has the parameters for 'CPACE-X25519-SHA512' as specified in Section 4 of [CPACE].¶

The OQUAKE_V1 PAKEScheme variant has the following parameters associated with it:¶

• BUA-sKEM: ML-BUA-sKEM1024¶

• KDF: HKDF-SHA-256¶

• DST: as specified in [PQPAKE]¶

These parameters correspond to the RECOMMENDED configuration in [PQPAKE].¶

The OQUAKE_PLUS_V1 PAKEScheme variant has the following parameters associated with it:¶

• BUA-sKEM: ML-BUA-sKEM1024¶

• KEM: X-Wing [XWING]¶

• KDF: HKDF-SHA-256¶

• KSF: Argon2id [ARGON2] (parameters as specified in [PQPAKE])¶

• DST: as specified in [PQPAKE]¶

These parameters correspond to the RECOMMENDED configuration in [PQPAKE].¶

Normative References

[CPACE]

Abdalla, M., Haase, B., and J. Hesse, "CPace, a balanced composable PAKE", Work in Progress, Internet-Draft, draft-irtf-cfrg-cpace-21, 22 April 2026, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace-21>.

[I-D.ietf-tls-hybrid-design]

Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key exchange in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-16, 7 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-16>.

[PQPAKE]

Vos, J. and C. A. Wood, "Hybrid Post-Quantum Password Authenticated Key Exchange", Work in Progress, Internet-Draft, draft-vos-cfrg-pqpake-latest, 2026, <https://datatracker.ietf.org/doc/draft-vos-cfrg-pqpake/>.

[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/rfc/rfc2119>.

[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/rfc/rfc8174>.

[RFC9147]

Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/rfc/rfc9147>.

[RFC9383]

Taubert, T. and C. A. Wood, "SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol", RFC 9383, DOI 10.17487/RFC9383, September 2023, <https://www.rfc-editor.org/rfc/rfc9383>.

[SPAKE2PLUS]

Taubert, T. and C. A. Wood, "SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol", RFC 9383, DOI 10.17487/RFC9383, September 2023, <https://www.rfc-editor.org/rfc/rfc9383>.

[TLS13]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[XWING]

Connolly, D., Schwabe, P., and B. Westerbaan, "X-Wing: The Hybrid KEM You've Been Looking For", Work in Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem-latest, 2024, <https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/>.

Informative References

[ARGON2]

"Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications", RFC 9106, 2022, <https://www.rfc-editor.org/rfc/rfc9106>.

[ECH]

Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-25, 14 June 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-25>.

[FIRST-DRAFT]

Barnes, R. and O. Friel, "Usage of PAKE with TLS 1.3", Work in Progress, Internet-Draft, draft-barnes-tls-pake-04, 16 July 2018, <https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake-04>.

[OPAQUE]

Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The OPAQUE Augmented PAKE Protocol", Work in Progress, Internet-Draft, draft-irtf-cfrg-opaque-18, 21 November 2024, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque-18>.

[RFC5054]

Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, DOI 10.17487/RFC5054, November 2007, <https://www.rfc-editor.org/rfc/rfc5054>.

[RFC9258]

Benjamin, D. and C. A. Wood, "Importing External Pre-Shared Keys (PSKs) for TLS 1.3", RFC 9258, DOI 10.17487/RFC9258, July 2022, <https://www.rfc-editor.org/rfc/rfc9258>.