PAKE Usage in TLS 1.3

3.1.1. 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:¶

　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 some PAKE algorithm. For example, the first bytes "0x00" and "0x01" represent CPace [I-D.draft-irtf-cfrg-cpace-13] and SPAKE2 [RFC9382], respectively; and the first bytes "0x40" and "0x41" represent OPAQUE [I-D.draft-irtf-cfrg-opaque-18] 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.¶

3.1.2. PAKE Share

The "pake_share" extension contains the endpoint’s PAKE parameters. The "PAKEShareEntry" value is defined as follows:¶

  struct {
      PAKEAlgorithm pake_algorithm;
      opaque pake_message<1..2^16-1>;
  } 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.¶

  struct {
      select (pake_algorithm) {
      case CPace:
          opaque dh_share;
          opaque associated_data;
      case SPAKE2:
          opaque dh_share;
      case OPAQUE:
          opaque credential_message;
          opaque nonce;
          opaque dh_share;
      case SPAKE2+:
          opaque dh_share;
      };
  } PAKEMessage;

• The "dh_share" field indicates a (EC)DH public element that is determined by the specified PAKE algorithm and the underlying group. 1) For CPace, the "dh_share" field indicates the value Ya or Yb in Section 6.2 of [I-D.draft-irtf-cfrg-cpace-13]; 2) for SPAKE2, this field indicates the value pA or pB in Section 3.3 of [RFC9382]; 3) for OPAQUE, this field indicates the value client_public_keyshare or server_public_keyshare in Section 6.1 of [I-D.draft-irtf-cfrg-opaque-18]; 4) for SPAKE2+, this field indicates the value shareP or shareV in Section 3.3 of [RFC9383].¶

• The "associated_data" field for CPace indicates the value ADa or ADb in Section 3.1 of [I-D.draft-irtf-cfrg-cpace-13].¶

• The "credential_message" field for OPAQUE indicates the value CredentialRequest or CredentialResponse in Section 6.3.1 of [I-D.draft-irtf-cfrg-opaque-18].¶

• The "nonce" field for OPAQUE indicates the value client_nonce or server_nonce in Section 6.1 of [I-D.draft-irtf-cfrg-opaque-18].¶

Note that the "random" value of the ClientHello message (see Section 4.1.2 of [RFC8446]) can be used as a unique session identifier sid of the CPace algorithm (see Section 3.1 of [I-D.draft-irtf-cfrg-cpace-13]).¶

(1) In the ClientHello message, the "extension_data" field of this extension contains a "PAKEShareClientHello" value:¶

  struct {
      opaque client_identity<0..2^16-1>;
      PAKEShareEntry client_shares<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 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:¶

  struct {
      PAKEAlgorithm selected_pake_algorithm;
  } PAKEShareHelloRetryRequest;

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:¶

  struct {
      opaque server_identity<0..2^16-1>;
      PAKEShareEntry server_share;
  } 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.¶

Upon receipt of the ClientHello message, servers use the "client_identity" value to determine if there is a PAKE registration record in their database, if not, servers MAY reply with a fake PAKE response to prevent active client enumeration attacks (see Section 3.1.4); if so, servers reply with a normal PAKE response containing a "pake_share" extension in the ServerHello message as described below.¶

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

3.1.3. 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:¶

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

3.1.4. Enumeration Prevention

If there is not a PAKE registration record on the server and the server directly aborts the handshake with an "illegal_parameter" alert, then this will provide an attacker with an oracle for client identities, that allows the attacker to learn whether there exists a PAKE registration record for the given "client_identity" value. To prevent this active client enumeration attack, the server can generate a fake PAKE response as follows.¶

• Select the first pake_algorithm that is supported by both the client and the server.¶

• Offer a "pake_share" extension in the ServerHello message, which includes the "server_identity", the selected "pake_algorithm" and the associated "pake_message" values. Here, the "dh_share" field of the "pake_message" can be generated by picking a value at random from the set of all valid DH shares of the selected pake_algorithm; for OPAQUE, the "credential_message" field of the "pake_message" can be generated according to Section 6.3.2.2 of [I-D.draft-irtf-cfrg-opaque-18] to contain a fake CredentialResponse.¶

• Complete the remainder of the protocol as usual.¶

As a result, the normal and fake PAKE responses are indistinguishable from one another, and the client cannot figure out whether the given "client_identity" value has a PAKE registration record on the server upon receiving the ServerHello and server's Finished messages. The verification of the server's Finished message will fail with overwhelming probability, since the server's DH share is a randomly picked value. However, the unsuccessful verification make the attacker only know whether a given (client_identity, password) pair is correct, and it cannot be used by the attacker to learn whether the client_identity is an unregistered client identity.¶