Algorand Foundation

hugokraw@gmail.com

Novi Research

lewi.kevin.k@gmail.com

Cloudflare

caw@heapingbits.net

Internet-Draft This document describes the OPAQUE protocol, a secure 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, along with several instantiations in different authenticated key exchange protocols. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction Password authentication is the prevalent form of authentication on the web and in many other applications. In the most common implementation, a client authenticates to a server by sending its client ID and password to the server over a TLS connection. This makes the password vulnerable to server mishandling, including accidentally logging the password or storing it in cleartext in a database. Server compromise resulting in access to these plaintext passwords is not an uncommon security incident, even among security-conscious companies. Moreover, plaintext password authentication over TLS is also vulnerable to TLS failures, including many forms of PKI attacks, certificate mishandling, termination outside the security perimeter, visibility to middleboxes, and more. Asymmetric (or Augmented) Password Authenticated Key Exchange (aPAKE) protocols are designed to provide password authentication and mutually authenticated key exchange in a client-server setting without relying on PKI (except during client/password registration) and without disclosing passwords to servers or other entities other than the client machine. A secure aPAKE should provide the best possible security for a password protocol. Namely, it should only be open to inevitable attacks, such as online impersonation attempts with guessed client passwords and offline dictionary attacks upon the compromise of a server and leakage of its password file. In the latter case, the attacker learns a mapping of a client's password under a one-way function and uses such a mapping to validate potential guesses for the password. Crucially important is for the password protocol to use an unpredictable one-way mapping. Otherwise, the attacker can pre-compute a deterministic list of mapped passwords leading to almost instantaneous leakage of passwords upon server compromise. Despite the existence of multiple designs for (PKI-free) aPAKE protocols, none of these protocols are secure against pre-computation attacks. In particular, none of these protocols can use the standard technique against pre-computation that combines secret random values ("salt") into the one-way password mappings. Either these protocols do not use a salt at all or, if they do, they transmit the salt from server to client in the clear, hence losing the secrecy of the salt and its defense against pre-computation. Furthermore, transmitting the salt may require additional protocol messages. This document describes OPAQUE, a PKI-free secure aPAKE that is secure against pre-computation attacks and capable of using a secret salt. OPAQUE provides forward secrecy (essential for protecting past communications in case of password leakage) and the ability to hide the password from the server - even during password registration. Furthermore, OPAQUE enjoys good performance and an array of additional features including the ability to increase the difficulty of offline dictionary attacks via iterated hashing or other hardening schemes, and offloading these operations to the client (that also helps against online guessing attacks); extensibility of the protocol to support storage and retrieval of client's secrets solely based on a password; being amenable to a multi-server distributed implementation where offline dictionary attacks are not possible without breaking into a threshold of servers (such a distributed solution requires no change or awareness on the client side relative to a single-server implementation). OPAQUE is defined and proven as the composition of two functionalities: an oblivious pseudorandom function (OPRF) and an authenticated key exchange (AKE) protocol. It can be seen as a "compiler" for transforming any suitable AKE protocol into a secure aPAKE protocol. (See for requirements of the OPRF and AKE protocols.) This document specifies one OPAQUE instantiation based on 3DH . Other instantiations are possible, as discussed in , but their details are out of scope for this document. In general, the modularity of OPAQUE's design makes it easy to integrate with additional AKE protocols, e.g., IKEv2, and with future ones such as those based on post-quantum techniques. OPAQUE consists of two stages: registration and authenticated key exchange. In the first stage, a client registers its password with the server and stores its encrypted credentials on the server. In the second stage, a client obtains those credentials, recovers them using the client's password, and subsequently uses them as input to an AKE protocol. Currently, the most widely deployed PKI-free aPAKE is SRP , which is vulnerable to pre-computation attacks, lacks proof of security and is less efficient relative to OPAQUE. Moreover, SRP requires a ring as it mixes addition and multiplication operations, and thus does not work over plain elliptic curves. OPAQUE is therefore a suitable replacement for applications that use SRP. This draft complies with the requirements for PAKE protocols set forth in .

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

Notation The following terms are used throughout this document to describe the operations, roles, and behaviors of OPAQUE:

• Client (C): Entity that has knowledge of a password and wishes to authenticate.
• Server (S): Entity that authenticates clients using passwords.
• password: An opaque byte string containing the client's password.
• I2OSP and OS2IP: Convert a byte string to and from a non-negative integer as described in Section 4 of . Note that these functions operate on byte strings in big-endian byte order.
• concat(x0, ..., xN): Concatenate byte strings. For example, concat(0x01, 0x0203, 0x040506) = 0x010203040506.
• random(n): Generate a cryptographically secure pseudorandom byte string of length n bytes.
• xor(a,b): Apply XOR to byte strings. For example, xor(0xF0F0, 0x1234) = 0xE2C4. It is an error to call this function with two arguments of unequal length.
• ct_equal(a, b): Return true if a is equal to b, and false otherwise. This function is constant-time in the length of a and b, which are assumed to be of equal length, irrespective of the values a or b.

Except if said otherwise, random choices in this specification refer to drawing with uniform distribution from a given set (i.e., "random" is short for "uniformly random"). Random choices can be replaced with fresh outputs from a cryptographically strong pseudorandom generator, according to the requirements in , or pseudorandom function. The name OPAQUE is a homonym of O-PAKE where O is for Oblivious. The name OPAKE was taken.

Cryptographic Protocol and Algorithm Dependencies OPAQUE relies on the following protocols and primitives:

• Oblivious Pseudorandom Function (OPRF, , version -06):
  • Blind(x): Convert input x into an element of the OPRF group, randomize it by some scalar r, producing M, and output (r, M).
  • GenerateKeyPair(): Generate an OPRF private and public key. OPAQUE only requires an OPRF private key. We write (oprf_key, _) = GenerateKeyPair() to denote use of this function for generating secret key oprf_key (and discarding the corresponding public key).
  • Evaluate(k, M): Evaluate input element M using private key k, yielding output element Z.
  • Finalize(x, r, Z): Finalize the OPRF evaluation using input x, random scalar r, and evaluation output Z, yielding output y.
  • SerializeScalar(s): Map a scalar s to a unique byte array buf of fixed length.
  • DeserializeScalar(buf): Map a byte array buf to a scalar s, or fail if the input is not a valid byte representation of a scalar.
  • SerializedElement: A serialized OPRF group element, a byte array of fixed length.
  • SerializedScalar: A serialized OPRF scalar, a byte array of fixed length.

Note that we only need the base mode variant (as opposed to the verifiable mode variant) of the OPRF described in .

• Cryptographic hash function:
  • Hash(m): Compute the cryptographic hash of input message m. The type of the hash is determined by the chosen OPRF group.
  • Nh: The output size of the Hash function.
• Authenticated Key Exchange (AKE, ):
  • Npk: The size of the public keys used for the key exchange protocol.
  • Nsk: The size of the private keys used for the key exchange protocol.
• Memory Hard Function (MHF):
  • Harden(msg, params): Repeatedly apply a memory-hard function with parameters params to strengthen the input msg against offline dictionary attacks. This function also needs to satisfy collision resistance.

Offline Registration Registration is executed between a client C and a server S. It is assumed S can identify C and the client can authenticate S during this registration phase. This is the only part in OPAQUE that requires an authenticated channel, either physical, out-of-band, PKI-based, etc. This section describes the registration flow, message encoding, and helper functions. Moreover, C has a key pair (client_private_key, client_public_key) for an AKE protocol which is suitable for use with OPAQUE; See . The private-public keys (client_private_key, client_public_key) may be randomly generated (using a cryptographically secure pseudorandom number generator) for the account or provided by the calling client. Clients MUST NOT use the same key pair (client_private_key, client_public_key) for two different accounts. To begin, C chooses its password, and S chooses its own pair of private-public AKE keys (server_private_key, server_public_key) for use with the AKE. S can use the same pair of keys with multiple clients. These steps can happen offline, i.e., before the registration phase. Once complete, the registration process proceeds as follows: (response, oprf_key) = CreateRegistrationResponse(request, server_public_key) response <------------------------- (record, export_key) = FinalizeRequest(password, creds, blind, response) record -------------------------> ]]> describes details of the functions referenced above. Both client and server MUST validate the other party's public key before use. See for more details. Upon completion, S stores C's credentials for later use. See for a recommended storage format.

Credential Storage OPAQUE makes use of a structure Envelope to store client credentials. The Envelope structure embeds the following types of credentials:

• client_private_key: The encoded client private key for the AKE protocol.
• server_public_key: The encoded server public key for the AKE protocol.
• client_identity: The client identity. This is an application-specific value, e.g., an e-mail address or normal account name.
• server_identity: The server identity. This is typically a domain name, e.g., example.com. See for information about this identity.

Each public and private key value is an opaque byte string, specific to the AKE protocol in which OPAQUE is instantiated. For example, if used as raw public keys for TLS 1.3 , they may be RSA or ECDSA keys as per . These credentials are incorporated in the SecretCredentials and CleartextCredentials structs, depending on the mode set by the value of EnvelopeMode: The base mode defines SecretCredentials and CleartextCredentials as follows: The custom_identifier mode defines SecretCredentials and CleartextCredentials as follows: ; opaque server_identity<0..2^16-1>; } CleartextCredentials; ]]> These credentials are embedded into the following Envelope structure with encryption and authentication.

mode

The EnvelopeMode value. This MUST be one of base or custom_identifier.

nonce

A unique 32-byte nonce used to protect this Envelope.

encrypted_creds

Encoding of encrypted and authenticated SecretCredentials.

auth_tag

Authentication tag protecting the contents of the envelope, covering InnerEnvelope and CleartextCredentials.

The full procedure for constructing Envelope and InnerEnvelope from SecretCredentials and CleartextCredentials is described in . Note that only SecretCredentials are stored in the Envelope (in encrypted form). The EnvelopeMode value is specified as part of the configuration (see ). Credential information corresponding to the configuration-specific mode, along with the client public key client_public_key and private key client_private_key, are recommended to be stored in a Credentials object with the following named fields:

• client_private_key, the client's private key
• client_public_key, the client's public key corresponding to client_private_key
• client_identity, an optional client identity (present only in the custom_identifier mode)
• server_identity, an optional server identity (present only in the custom_identifier mode)

Registration Messages

data

A serialized OPRF group element.

data

A serialized OPRF group element.

server_public_key

The server's encoded public key that will be used for the online authenticated key exchange stage.

client_public_key

The client's encoded public key, corresponding to the private key client_private_key.

envelope

The client's Envelope structure.

Registration Functions

CreateRegistrationRequest

CreateRegistrationResponse

FinalizeRequest The inputs to HKDF-Extract and HKDF-Expand are as specified in . The underlying hash function is that which is associated with the OPAQUE configuration (see ). See for details about the output export_key usage. Upon completion of this function, the client MUST send record to the server.

Credential File The server then constructs and stores the credential_file object, where envelope and client_public_key are obtained from record, and oprf_key is retained from the output of CreateRegistrationResponse. oprf_key is serialized using SerializeScalar. The below structure represents an example of how these values might be conveniently stored together.

Online Authenticated Key Exchange After registration, the client and server run the authenticated key exchange stage of the OPAQUE protocol. This stage is composed of a concurrent OPRF and key exchange flow. The key exchange protocol is authenticated using the client and server credentials established during registration; see . The type of keys MUST be suitable for the key exchange protocol. For example, if the key exchange protocol is 3DH, as described in , then the private and public keys must be Diffie-Hellman keys. In the end, the client proves its knowledge of the password, and both client and server agree on a mutually authenticated shared secret key. OPAQUE produces two outputs: a session secret and an export key. The export key may be used for additional application-specific purposes, as outlined in . The output export_key MUST NOT be used in any way before the HMAC value in the envelope is validated. See for more details about this requirement.

Credential Retrieval The online AKE stage of the protocol requires clients to obtain and decrypt their credentials from the server-stored envelope. This process is similar to the offline registration stage, as shown below. response = CreateCredentialResponse(request, server_public_key, credential_file) response <------------------------- (client_private_key, server_public_key, export_key) = RecoverCredentials(password, blind, response) ]]> The rest of this section describes these credential retrieval functions in more detail.

Credential Retrieval Messages

data

A serialized OPRF group element.

data

A serialized OPRF group element.

server_public_key

The server's encoded public key that will be used for the online authenticated key exchange stage.

envelope

The client's Envelope structure.

Credential Retrieval Functions

CreateCredentialRequest

CreateCredentialResponse

RecoverCredentials

AKE Instantiations This section describes instantiations of OPAQUE using 3-message AKEs which satisfies the forward secrecy and KCI properties discussed in . As shown in , OPAQUE cannot use less than three messages so the 3-message instantiations presented here are optimal in terms of number of messages. On the other hand, there is no impediment to using OPAQUE with protocols with more than 3 messages as in the case of IKEv2 (or the underlying SIGMA-R protocol ). The generic outline of OPAQUE with a 3-message AKE protocol includes three messages KE1, KE2, and KE3, where KE1 and KE2 include key exchange shares, e.g., DH values, sent by client and server, respectively, and KE3 provides explicit client authentication and full forward security (without it, forward secrecy is only achieved against eavesdroppers which is insufficient for OPAQUE security). The output of the authentication phase is a session secret session_key and export key export_key. Applications can use session_key to derive additional keying material as needed. Key derivation and other details of the protocol are specified by the AKE scheme. We note that by the results in , KE2 and KE3 must authenticate credential_request and credential_response, respectively, for binding between the underlying OPRF protocol messages and the KE session. We use the parameters Npk and Nsk to denote the size of the public and private keys used in the AKE instantiation. Npk and Nsk must adhere to the output size limitations of the HKDF Expand function from , which means that Npk, Nsk <= 255 * Nh. The rest of this section includes key schedule utility functions used by OPAQUE-3DH, and then provides a detailed specification for OPAQUE-3DH, including its wire format messages.

Key Schedule Utility Functions The key derivation procedures for OPAQUE-3DH makes use of the functions below, re-purposed from TLS 1.3 . Where HkdfLabel is specified as: = "OPAQUE " + Label; opaque context<0..255> = Context; } HkdfLabel; Derive-Secret(Secret, Label, Transcript-Hash) = HKDF-Expand-Label(Secret, Label, Transcript-Hash, Nh) ]]> HKDF uses Hash as its underlying hash function, which is the same as that which is indicated by the OPAQUE instantiation. Note that the Label parameter is not a NULL-terminated string.

OPAQUE-3DH Instantiation OPAQUE-3DH is implemented using a suitable prime order group. All operations in the key derivation steps in are performed in this group and represented here using multiplicative notation. The output of OPAQUE-3DH is a session secret session_key and export key export_key. The parameters Npk and Nsk are set to be equal to the size of an element and scalar, respectively, in the associated prime order group.

OPAQUE-3DH Messages The three messages for OPAQUE-3DH are described below. ; uint8 client_keyshare[Npk]; } KE1; ]]>

request

A CredentialRequest generated according to .

client_nonce

A fresh 32-byte randomly generated nonce.

client_info

Optional application-specific information to exchange during the protocol.

client_keyshare

Client ephemeral key share of fixed size Npk, where Npk depends on the corresponding prime order group.

; uint8 mac[Nh]; } KE2; ]]>

response

A CredentialResponse generated according to .

server_nonce

A fresh 32-byte randomly generated nonce.

server_keyshare

Server ephemeral key share of fixed size Npk, where Npk depends on the corresponding prime order group.

enc_server_info

Optional application-specific information to exchange during the protocol encrypted under key Ke2, defined below.

mac

An authentication tag computed over the handshake transcript computed using Km2, defined below.

mac

An authentication tag computed over the handshake transcript computed using Km3, defined below.

OPAQUE-3DH Key Schedule OPAQUE-3DH requires MAC keys server_mac_key and client_mac_key and encryption key handshake_encrypt_key. Additionally, OPAQUE-3DH also outputs session_key. The schedule for computing this key material is below. Derive-Secret(., "handshake secret", Hash(preamble)) = handshake_secret | +-> Derive-Secret(., "session secret", Hash(preamble)) = session_key ]]> From handshake_secret, Km2, Km3, and Ke2 are computed as follows: Nh is the output length of the underlying hash function. The Derive-Secret parameter preamble is computed as: See for more information about identities client_identity and server_identity. Let epkS and eskS be server_keyshare and the corresponding secret key, and epkU and eskU be client_keyshare and the corresponding secret key. The input parameter IKM the concatenation of three DH values computed by the client as follows: Likewise, IKM is computed by the server as follows:

OPAQUE-3DH Encryption and Key Confirmation {#3dh-core} Clients and servers use keys Km2 and Km3 in computing KE2.mac and KE3.mac, respectively. These values are computed as follows:

• KE2.mac = HMAC(Km2, Hash(concat(preamble, KE2.enc_server_info)), where preamble is as defined in .
• KE3.mac = HMAC(Km3, Hash(concat(preamble, KE2.enc_server_info, KE2.mac)), where preamble is as defined in .

The server application info, an opaque byte string server_info, is encrypted using a technique similar to that used for secret credential encryption. Specifically, a one-time-pad is derived from Ke2 and then used as input to XOR with the plaintext. In pseudocode, this is done as follows:

Configurations An OPAQUE configuration is a tuple (OPRF, Hash, MHF, EnvelopeMode, Group). The OPAQUE OPRF protocol is drawn from the "base mode" variant of . The following OPRF ciphersuites are supported:

• OPRF(ristretto255, SHA-512)
• OPRF(decaf448, SHA-512)
• OPRF(P-256, SHA-256)
• OPRF(P-384, SHA-512)
• OPRF(P-521, SHA-512)

Future configurations may specify different OPRF constructions. The OPAQUE hash function is that which is associated with the OPRF ciphersuite. For the ciphersuites specified here, only SHA-512 and SHA-256 are supported. The OPAQUE MHFs include Argon2 , scrypt , and PBKDF2 with fixed parameter choices. The EnvelopeMode value is defined in . It MUST be one of base or custom_identifier. Future specifications may specify alternate EnvelopeMode values and their corresponding Envelope structure. The Group mode identifies the group used in the OPAQUE-3DH AKE. This SHOULD match that of the OPRF.

Security Considerations OPAQUE is defined and proven as the composition of two functionalities: an OPRF and an AKE protocol. It can be seen as a "compiler" for transforming any AKE protocol (with KCI security and forward secrecy - see below) into a secure aPAKE protocol. In OPAQUE, the client stores a secret private key at the server during password registration and retrieves this key each time it needs to authenticate to the server. The OPRF security properties ensure that only the correct password can unlock the private key while at the same time avoiding potential offline guessing attacks. This general composability property provides great flexibility and enables a variety of OPAQUE instantiations, from optimized performance to integration with TLS. The latter aspect is of prime importance as the use of OPAQUE with TLS constitutes a major security improvement relative to the standard password-over-TLS practice. At the same time, the combination with TLS builds OPAQUE as a fully functional secure communications protocol and can help provide privacy to account information sent by the client to the server prior to authentication. The KCI property required from AKE protocols for use with OPAQUE states that knowledge of a party's private key does not allow an attacker to impersonate others to that party. This is an important security property achieved by most public-key based AKE protocols, including protocols that use signatures or public key encryption for authentication. It is also a property of many implicitly authenticated protocols, e.g., HMQV, but not all of them. We also note that key exchange protocols based on shared keys do not satisfy the KCI requirement, hence they are not considered in the OPAQUE setting. We note that KCI is needed to ensure a crucial property of OPAQUE: even upon compromise of the server, the attacker cannot impersonate the client to the server without first running an exhaustive dictionary attack. Another essential requirement from AKE protocols for use in OPAQUE is to provide forward secrecy (against active attackers).

Related Analysis Jarecki et al. proved the security of OPAQUE in a strong aPAKE model that ensures security against pre-computation attacks and is formulated in the Universal Composability (UC) framework under the random oracle model. This assumes security of the OPRF function and of the underlying key exchange protocol. In turn, the security of the OPRF protocol from is proven in the random oracle model under the One-More Diffie-Hellman assumption . Very few aPAKE protocols have been proven formally, and those proven were analyzed in a weak security model that allows for pre-computation attacks (e.g., ). This is not just a formal issue: these protocols are actually vulnerable to such attacks. This includes protocols that have recent analyses in the UC model such as AuCPace and SPAKE2+ . We note that as shown in , these protocols, and any aPAKE in the model from , can be converted into an aPAKE secure against pre-computation attacks at the expense of an additional OPRF execution. OPAQUE's design builds on a line of work initiated in the seminal paper of Ford and Kaliski and is based on the HPAKE protocol of Xavier Boyen and the (1,1)-PPSS protocol from Jarecki et al. . None of these papers considered security against pre-computation attacks or presented a proof of aPAKE security (not even in a weak model).

Identities AKE protocols generate keys that need to be uniquely and verifiably bound to a pair of identities. In the case of OPAQUE, those identities correspond to client_identity and server_identity. Thus, it is essential for the parties to agree on such identities, including an agreed bit representation of these identities as needed. Applications may have different policies about how and when identities are determined. A natural approach is to tie client_identity to the identity the server uses to fetch envelope (hence determined during password registration) and to tie server_identity to the server identity used by the client to initiate an offline password registration or online authenticated key exchange session. server_identity and client_identity can also be part of the envelope or be tied to the parties' public keys. In principle, identities may change across different sessions as long as there is a policy that can establish if the identity is acceptable or not to the peer. However, we note that the public keys of both the server and the client must always be those defined at the time of password registration. The client identity (client_identity) and server identity (server_identity) are optional parameters that are left to the application to designate as monikers for the client and server. If the application layer does not supply values for these parameters, then they will be omitted from the creation of the envelope during the registration stage. Furthermore, they will be substituted with client_identity = client_public_key and server_identity = server_public_key during the authenticated key exchange stage. The advantage to supplying a custom client_identity and server_identity (instead of simply relying on a fallback to client_public_key and server_public_key) is that the client can then ensure that any mappings between client_identity and client_public_key (and server_identity and server_public_key) are protected by the authentication from the envelope. Then, the client can verify that the client_identity and server_identity contained in its envelope matches the client_identity and server_identity supplied by the server. However, if this extra layer of verification is unnecessary for the application, then simply leaving client_identity and server_identity unspecified (and using client_public_key and server_public_key instead) is acceptable.

Envelope Encryption The analysis of OPAQUE from requires the authenticated encryption scheme used to produce envelope to have a special property called random key-robustness (or key-committing). This specification enforces this property by utilizing encrypt-then-HMAC in the construction of the envelope. There is no option to use another authenticated-encryption scheme with this specification. (Deviating from the key-robustness requirement may open the protocol to attacks, e.g., .) We remark that export_key for authentication or encryption requires no special properties from the authentication or encryption schemes as long as export_key is used only after the envelope is validated, i.e., after the HMAC in RecoverCredentials passes verification.

Export Key Usage The export key can be used (separately from the OPAQUE protocol) to provide confidentiality and integrity to other data which only the client should be able to process. For instance, if the server is expected to maintain any client-side secrets which require a password to access, then this export key can be used to encrypt these secrets so that they remain hidden from the server.

Static Diffie-Hellman Oracles While one can expect the practical security of the OPRF function (namely, the hardness of computing the function without knowing the key) to be in the order of computing discrete logarithms or solving Diffie-Hellman, Brown and Gallant and Cheon show an attack that slightly improves on generic attacks. For typical curves, the attack requires an infeasible number of calls to the OPRF or results in insignificant security loss; see for more information. For OPAQUE, these attacks are particularly impractical as they translate into an infeasible number of failed authentication attempts directed at individual users.

Input Validation Both client and server MUST validate the other party's public key(s) used for the execution of OPAQUE. This includes the keys shared during the offline registration phase, as well as any keys shared during the online key agreement phase. The validation procedure varies depending on the type of key. For example, for OPAQUE instantiations using 3DH with P-256, P-384, or P-521 as the underlying group, validation is as specified in Section 5.6.2.3.4 of . This includes checking that the coordinates are in the correct range, that the point is on the curve, and that the point is not the point at infinity. Additionally, validation MUST ensure the Diffie-Hellman shared secret is not the point at infinity.

OPRF Hardening Hardening the output of the OPRF greatly increases the cost of an offline attack upon the compromise of the password file at the server. Applications SHOULD select parameters that balance cost and complexity.

Client Enumeration Client enumeration refers to attacks where the attacker tries to learn whether a given client identity is registered with a server. Preventing such attacks requires the server to act with unknown client identities in a way that is indistinguishable from its behavior with existing clients. Here we suggest a way to implement such defense, namely, a way for simulating a CredentialResponse for non-existing clients. Note that if the same CredentialRequest is received twice by the server, the response needs to be the same in both cases (since this would be the case for real clients). For protection against this attack, one would apply the encryption function in the construction of the envelope to all the key material in it. The server S will have two keys MK, MK' for a pseudorandom function f. f refers to a regular pseudorandom function such as HMAC or CMAC. Upon receiving a CredentialRequest for a non-existing client client_identity, S computes oprf_key=f(MK; client_identity) and oprf_key'=f(MK'; client_identity) and responds with CredentialResponse carrying Z=M^oprf_key and envelope, where the latter is computed as follows. prk is set to oprf_key' and secret_creds is set to the all-zero string (of the length of a regular envelope plaintext). Care needs to be taken to avoid side-channel leakage (e.g., timing) from helping differentiate these operations from a regular server response. The above requires changes to the server-side implementation but not to the protocol itself or the client-side. There is one form of leakage that the above allows and whose prevention would require a change in OPAQUE. An attacker that attempts authentication with the same CredentialRequest twice and receives different responses can conclude that either the client registered with the service between these two activations or that the client was registered before but changed its password in between the activations (assuming the server changes oprf_key at the time of a password change). In any case, this indicates that client_identity is a registered client at the time of the second activation. To conceal this information, S can implement the derivation of oprf_key as oprf_key=f(MK; client_identity) also for registered clients. Hiding changes in the envelope, however, requires a change in the protocol. Instead of sending envelope as is, S would send an encryption of envelope under a key that the client derives from the OPRF result (similarly to prk) and that S stores during password registration. During the authenticated key exchange stage, the client will derive this key from the OPRF result, will use it to decrypt the envelope, and continue with the regular protocol. If S uses a randomized encryption, the encrypted envelope will look each time as a fresh random string, hence S can simulate the encrypted envelope also for non-existing clients. Note that the first case above does not change the protocol so its implementation is a server's decision (the client side is not changed). The second case, requires changes on the client side so it changes OPAQUE itself. [[https://github.com/cfrg/draft-irtf-cfrg-opaque/issues/22: Should this variant be documented/standardized?]]

Password Salt and Storage Implications In OPAQUE, the OPRF key acts as the secret salt value that ensures the infeasibility of pre-computation attacks. No extra salt value is needed. Also, clients never disclose their passwords to the server, even during registration. Note that a corrupted server can run an exhaustive offline dictionary attack to validate guesses for the client's password; this is inevitable in any aPAKE protocol. (OPAQUE enables defense against such offline dictionary attacks by distributing the server so that an offline attack is only possible if all - or a minimal number of - servers are compromised .) Some applications may require learning the client's password for enforcing password rules. Doing so invalidates this important security property of OPAQUE and is NOT RECOMMENDED. Applications should move such checks to the client. Note that limited checks at the server are possible to implement, e.g., detecting repeated passwords.

IANA Considerations This document makes no IANA requests.

References Normative References 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. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Informative References This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. An Oblivious Pseudorandom Function (OPRF) is a two-party protocol for computing the output of a PRF. One party (the server) holds the PRF secret key, and the other (the client) holds the PRF input. The 'obliviousness' property ensures that the server does not learn anything about the client's input during the evaluation. The client should also not learn anything about the server's secret PRF key. Optionally, OPRFs can also satisfy a notion 'verifiability' (VOPRF). In this setting, the client can verify that the server's output is indeed the result of evaluating the underlying PRF with just a public key. This document specifies OPRF and VOPRF constructions instantiated within prime-order groups, including elliptic curves. This document describes two mechanisms for enabling the use of the OPAQUE password-authenticated key exchange in TLS 1.3. n.d. This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG). 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 provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer- oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema. This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community.

Acknowledgments The OPAQUE protocol and its analysis is joint work of the author with Stas Jarecki and Jiayu Xu. We are indebted to the OPAQUE reviewers during CFRG's aPAKE selection process, particularly Julia Hesse and Bjorn Tackmann. This draft has benefited from comments by multiple people. Special thanks to Richard Barnes, Dan Brown, Eric Crockett, Paul Grubbs, Fredrik Kuivinen, Payman Mohassel, Jason Resch, Greg Rubin, and Nick Sullivan.

Alternate AKE Instantiations It is possible to instantiate OPAQUE with other AKEs, such as HMQV and SIGMA-I. HMQV is similar to 3DH but varies in its key schedule. SIGMA-I uses digital signatures rather than static DH keys for authentication. Specification of these instantiations is left to future documents. A sketch of how these instantiations might change is included in the next subsection for posterity. The AKE private key size (Nsk) is limited to the output size of the HKDF Expand function from . Future specifications which have keys exceeding this size should specify a mechanism by which private keys and their corresponding public keys can be deterministically derived from a fixed-length seed. OPAQUE may also be instantiated with any post-quantum (PQ) AKE protocol that has the message flow above and security properties (KCI resistance and forward secrecy) outlined in . Note that such an instantiation is not quantum-safe unless the OPRF is quantum-safe. However, an OPAQUE instantiation where the AKE is quantum-safe, but the OPRF is not, would still ensure the confidentiality of application data encrypted under session_key (or a key derived from it) with a quantum-safe encryption function.

HMQV Instantiation Sketch An HMQV instantiation would work similar to OPAQUE-3DH, differing primarily in the key schedule . First, the key schedule preamble value would use a different constant prefix - "HMQV" instead of "3DH" - as shown below. Second, the IKM derivation would change. Assuming HMQV is instantiated with a cyclic group of prime order p with bit length L, clients would compute IKM as follows: Likewise, servers would compute IKM as follows: In both cases, u would be computed as follows: Likewise, s would be computed as follows: Hash is the same hash function used in the main OPAQUE protocol for key derivation. Its output length (in bits) must be at least L.

SIGMA-I Instantiation Sketch A SIGMA-I instantiation differs more drastically from OPAQUE-3DH, since authentication uses digital signatures in lieu of Diffie Hellman. In particular, both KE2 and KE3 would carry a digital signature, computed using the server and client private keys established during registration, respectively, as well as a MAC, where the MAC is computed as in OPAQUE-3DH. The key schedule would also change. Specifically, the key schedule preamble value would use a different constant prefix - "SIGMA-I" instead of "3DH" - and the IKM computation would use only the ephemeral key shares exchanged between client and server.

Test Vectors This section contains test vectors for the OPAQUE-3DH specification. Each test vector specifies the configuration information, protocol inputs, intermediate values computed during registration and authentication, and protocol outputs. All values are encoded in hexadecimal strings. The configuration information includes the (OPRF, Hash, MHF, EnvelopeMode, Group) tuple, where the Group matches that which is used in the OPRF. These test vectors were generated using draft-06 of .

OPAQUE-3DH Test Vector 1

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Test Vector 2

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Test Vector 3

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Test Vector 4

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Test Vector 5

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Test Vector 6

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Test Vector 7

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Test Vector 8

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Test Vector 9

Configuration

Input Values

Intermediate Values

Output Values

OPAQUE-3DH Test Vector 10

Configuration

Input Values

Intermediate Values

Output Values