Internet DRAFT - draft-krawczyk-cfrg-opaque
draft-krawczyk-cfrg-opaque
Crypto Forum Research Group H. Krawczyk
Internet-Draft Algorand Foundation
Intended status: Informational June 19, 2020
Expires: December 21, 2020
The OPAQUE Asymmetric PAKE Protocol
draft-krawczyk-cfrg-opaque-06
Abstract
This draft 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.
Prior aPAKE protocols did not use salt and if they did, the salt was
transmitted in the clear from server to user allowing for the
building of targeted pre-computed dictionaries. OPAQUE security has
been proven by Jarecki et al. (Eurocrypt 2018) in a strong and
universally composable formal model of aPAKE security. In addition,
the protocol provides forward secrecy and the ability to hide the
password from the server even during password registration.
Strong security, versatility through modularity, good performance,
and an array of additional features make OPAQUE a natural candidate
for practical use and for adoption as a standard. To this end, this
draft presents several instantiations of OPAQUE and ways of
integrating OPAQUE with TLS.
This draft presents a high-level description of OPAQUE, highlighting
its components and modular design. It also provides the basis for a
specification for standardization but a detailed specification ready
for implementation is beyond the scope of this document.
Implementers of OPAQUE should ONLY follow the precise specification
in the upcoming draft-irtf-cfrg-opaque.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Krawczyk Expires December 21, 2020 [Page 1]
Internet-Draft OPAQUE June 2020
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 21, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6
2. DH-OPRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. DH-OPRF instantiation and detailed specification . . . . 8
2.2. Hardening OPRF via user iterations . . . . . . . . . . . 8
3. OPAQUE Specification . . . . . . . . . . . . . . . . . . . . 8
3.1. Password registration . . . . . . . . . . . . . . . . . . 9
3.2. Online OPAQUE protocol (Login and key exchange) . . . . . 10
3.3. Parties' identities . . . . . . . . . . . . . . . . . . . 10
4. Specification of the EnvU envelope . . . . . . . . . . . . . 11
5. OPAQUE Instantiations . . . . . . . . . . . . . . . . . . . . 13
5.1. Instantiation of OPAQUE with HMQV and 3DH . . . . . . . . 13
5.2. Instantiation of OPAQUE with SIGMA-I . . . . . . . . . . 16
6. Integrating OPAQUE with TLS 1.3 . . . . . . . . . . . . . . . 17
7. User enumeration . . . . . . . . . . . . . . . . . . . . . . 20
8. Security considerations . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
Krawczyk Expires December 21, 2020 [Page 2]
Internet-Draft OPAQUE June 2020
1. Introduction
Password authentication is the prevalent form of authentication in
the web and in most other applications. In the most common
implementation, a user authenticates to a server by entering its user
id and password where both values are transmitted to the server under
the protection of TLS. This makes the password vulnerable to TLS
failures, including many forms of PKI attacks, certificate
mishandling, termination outside the security perimeter, visibility
to middle boxes, and more. Moreover, even under normal operation,
passwords are always visible in plaintext form at the server upon TLS
decryption (in particular, storage of plaintext passwords is not an
uncommon security incident, even among security-conscious companies).
Asymmetric (or augmented) Password Authenticated Key Exchange (aPAKE)
protocols are designed to provide password authentication and
mutually authenticated key exchange without relying on PKI (except
during user/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:
online impersonation attempts with guessed user 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 user'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 or
otherwise the attacker can pre-compute a deterministic list of mapped
passwords leading to almost instantaneous leakage of passwords upon
server compromise.
Quite surprisingly, in spite of the existence of multiple designs for
(PKI-free) aPAKE protocols, none of these protocols is 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 salt at all or, if they do, they
transmit the salt from server to user in the clear, hence losing the
secrecy of the salt and its defense against pre-computation.
Furthermore, the transmission of salt may incur additional protocol
messages.
This draft describes OPAQUE, a PKI-free secure aPAKE that is secure
against pre-computation attacks and capable of using secret salt.
OPAQUE has been recently defined and studied by Jarecki et al.
[OPAQUE] who prove the security of the protocol in a strong aPAKE
model that ensures security against pre-computation attacks and is
formulated in the Universal Composability (UC) framework [Canetti01]
Krawczyk Expires December 21, 2020 [Page 3]
Internet-Draft OPAQUE June 2020
under the random oracle model. In contrast, 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.,
[GMR06]). 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 [AuCPace] and
SPAKE2+ [SPAKE2plus]. We note that as shown in [OPAQUE], these
protocols, and any aPAKE in the model from [GMR06], can be converted
into an aPAKE secure against pre-computation attacks at the expense
of an additional OPRF execution.
It is worth noting that the currently most deployed (PKI-free) aPAKE
is SRP [RFC2945], which is open to pre-computation attacks, is
inefficient 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.
OPAQUE's design builds on a line of work initiated in the seminal
paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol
of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et
al. [JKKX16]. None of these papers considered security against pre-
computation attacks or presented a proof of aPAKE security (not even
in a weak model).
In addition to its proven resistance to pre-computation attacks,
OPAQUE's security features include 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. Moreover, good performance and an array of additional
features make OPAQUE a natural candidate for practical use and for
adoption as a standard. Such features include 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
user's secrets solely based on a password; and being amenable to a
multi-server distributed implementation where offline dictionary
attacks are not possible without breaking into a threshold of servers
(such 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 PRF (OPRF) and a key-exchange protocol.
It can be seen as a "compiler" for transforming any key-exchange
protocol (with KCI security and forward secrecy - see below) into a
secure aPAKE protocol. In OPAQUE, the user stores a secret private
key at the server during password registration and retrieves this key
Krawczyk Expires December 21, 2020 [Page 4]
Internet-Draft OPAQUE June 2020
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 user to the server
prior to authentication.
The KCI property required from KE 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 KE 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 user to the server without first running an
exhaustive dictionary attack. Another essential requirement from KE
protocols for use in OPAQUE is to provide forward secrecy (against
active attackers).
This draft presents a high-level description of OPAQUE highlighting
its components and modular design. It also provides the basis for a
specification for standardization but a detailed specification ready
for implementation is beyond the current scope of this document
(which may be expanded in future revisions or done separately).
We describe OPAQUE with a specific instantiation of the OPRF
component over elliptic curves and with a few KE schemes, including
the HMQV [HMQV], 3DH [SIGNAL] and SIGMA [SIGMA] protocols. We also
present several strategies for integrating OPAQUE with TLS 1.3
[RFC8446] offering different tradeoffs between simplicity,
performance and user privacy. In general, the modularity of OPAQUE's
design makes it easy to integrate with additional key-exchange
protocols, e.g., IKEv2.
The computational cost of OPAQUE is determined by the cost of the
OPRF, the cost of a regular Diffie-Hellman exchange, and the cost of
authenticating such exchange. In our elliptic-curve implementation
of the OPRF, the cost for the client is two exponentiations (one or
Krawczyk Expires December 21, 2020 [Page 5]
Internet-Draft OPAQUE June 2020
two of which can be fixed base) and one hashing-into-curve operation
[I-D.irtf-cfrg-hash-to-curve]; for the server, it is just one
exponentiation. The cost of a Diffie-Hellman exchange is as usual
two exponentiations per party (one of which is fixed-base). Finally,
the cost of authentication per party depends on the specific KE
protocol: it is just 1/6 of an exponentiation with HMQV, two
exponentiations for 3DH, and it is one signature generation and
verification in the case of SIGMA and TLS 1.3. These instantiations
preserve the number of messages in the underlying KE protocol except
in one of the TLS instantiations where user privacy may require an
additional round trip.
1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]
1.2. Notation
Throughout this document the first argument to a keyed function
represents the key; separated by a semicolon are the function inputs
typically implemented as an unambiguous concatenation of strings
(details of encodings are left for a future, more detailed
specification).
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 or pseudorandom function.
The name OPAQUE: A homonym of O-PAKE where O is for Oblivious (the
name OPAKE was taken).
2. DH-OPRF
OPAQUE uses in a fundamental way an Oblivious Pseudo Random Function
(OPRF).
An Oblivious PRF (OPRF) is an interactive protocol between a server S
and a user U defined by a special pseudorandom function (PRF),
denoted F. The server's input to the protocol is a key k for PRF F
and the user's input is a value x in the domain of F. At the end of
the protocol, U learns F(k; x) and nothing else while S learns
nothing from the protocol execution (in particular nothing about x or
the value F(k; x)).
Krawczyk Expires December 21, 2020 [Page 6]
Internet-Draft OPAQUE June 2020
OPAQUE uses a specific OPRF instantiation, called DH-OPRF, where the
PRF, denoted F, is defined next, generically.
Parameters: Hash function H (e.g., SHA2 or SHA3 function) with
256-bit output at least, a cyclic group G of prime order q, a
generator g of G, and hash function H' mapping arbitrary strings into
G (where H' is modeled as a random oracle).
o DH-OPRF domain: Any string
o DH-OPRF range: The range of the hash function H
o DH-OPRF key: A random element k in [0..q-1]
o DH-OPRF Operation: F(k; x) = H(x, H'(x)^k)
Protocol for computing DH-OPRF, U with input x and S with input k:
o U: choose random r in [0..q-1], send alpha=H'(x)^r to S
o S: upon receiving a value alpha, respond with beta=alpha^k
o U: upon receiving beta set the PRF output to H(x, beta^{1/r})
Received values alpha, beta are checked to be elements in G other
than the identity and the receiving party aborts if the check fails
(alternatively, co-factor exponentiation can be applied to the
received values).
Note (fixed-base blinding): An alternative way of computing DH-OPRF
is for U to choose random r in [0..q-1] and send alpha=H'(x)*g^r to
S, who responds with beta=alpha^k as well as with the value v=g^k
(that S may store together with k). U then sets the OPRF output F(k;
x) to H(x, beta*v^{-r}). This reduces the computation at U from two
variable-base exponentiations in the above protocol to one fixed-base
and one variable-base exponentiation. Moreover, if U stores g^k
(e.g., for servers to which it logins frequently), then the
computation takes two fixed-base exponentiations (with bases g and
g^k). The downside of fixed-base blinding is the need for the server
to store g^k and to sent it to the client, which is otherwise not
necessary. Applications can choose any of the blinding options as
both compute the same function.
We note that prior versions of this document defined the OPRF to
include g^k under the hash function H in order to provide security
for fixed-base blinding. However, [Blinding] proved recently that
fixed-base blinding is secure also without hashing g^k.
Krawczyk Expires December 21, 2020 [Page 7]
Internet-Draft OPAQUE June 2020
2.1. DH-OPRF instantiation and detailed specification
The above description of DH-OPRF is generic and applicable to any
cyclic group. Detailed specification for concrete implementations of
DH-OPRF can be found in [I-D.irtf-cfrg-voprf] which defines several
instantiation suites for DH-OPRF, including the choice of hash-to-
curve functions (denoted H' above) as detailed in
[I-D.irtf-cfrg-hash-to-curve]. OPAQUE will adopt some of these
instantiation suites and their underlying elliptic curves. The
latter will determine implementation details for such curves
including ways to check curve membership, the suitability of co-
factor mechanisms, etc.
2.2. Hardening OPRF via user iterations
Protocol OPAQUE is strengthened against offline dictionary attacks by
applying to the output of DH-OPRF a hardening procedure such as via
repeated iterations, memory hard operations, etc. This greatly
increases the cost of an offline attack upon the compromise of the
password file at the server. For this purpose, we define the
extended DH-OPRF F* as
F*(k; x) = I^n( H(x, H'(x)^k) ) where I is a hardening function and n
is a measure of hardness. For example, I can represent the iterative
function of PBKDF2 [RFC8018] and n the number of iterations; in the
case of memory-hard functions such as Argon2 [I-D.irtf-cfrg-argon2]
and scrypt [RFC7914], I is a more involved memory-hard function and n
measures cost factors and other parameters.
Parameters to the hardening function can be set to public values or
set at the time of password registration and stored at the server.
In this case, the server communicates these parameters to the user
during OPAQUE executions together with the second OPRF message. We
note that the salt value typically input into the KDF can be set to a
constant, e.g., all zeros.
3. OPAQUE Specification
OPAQUE consists of the concurrent run of an OPRF protocol and a key-
exchange protocol KE (one that provides mutual authentication based
on public keys and satisfies the KCI requirement discussed in the
introduction). We first define OPAQUE in a generic way based on any
OPRF and any PK-based KE, and later show specific instantiation using
DH-OPRF (defined in Section 2) and several KE protocols. The user,
running on a client machine, takes the role of initiator in these
protocols and the server the responder's. The private-public keys
for the user are denoted PrivU and PubU, and for the server PrivS and
PubS.
Krawczyk Expires December 21, 2020 [Page 8]
Internet-Draft OPAQUE June 2020
3.1. Password registration
Password registration is executed between a user U (running on a
client machine) and a server S. It is assumed the server can
identify the user and the client can authenticate the server during
this registration phase. This is the only part in OPAQUE that
requires an authenticated channel, either physical, out-of-band, PKI-
based, etc.
o U chooses password PwdU and a pair of private-public keys PrivU
and PubU for the given protocol KE.
o S chooses OPRF key kU (random and independent for each user),
chooses its own pair of private-public keys PrivS and PubS for use
with protocol KE (S can use the same pair of keys with multiple
users), and sends PubS to the client.
o Client and S run the OPRF F(kU; PwdU) as defined in Section 2 with
only the client learning the result. The client then applies a
hardening function, as described in Section 2.2, to this result
obtaining a value denoted RwdU (for "Randomized PwdU"). The
parameters of the hardening function can be public and known to
client machines or they can be stored by S and communicated to the
client during registration and login sessions.
o Client generates an "envelope" EnvU that contains PrivU and PubS,
and optionally also PubU and the parties' identities (see
Section 3.3), all protected under RwdU. PrivU needs secrecy and
authentication protection, while the other values require
authentication and optionally secrecy. We provide a precise
specification of the enveloping function in Section 4.
Implementations of OPAQUE MUST NOT use any enveloping scheme other
than as specified in that section.
o The client sends EnvU and PubU to S and erases PwdU, RwdU and all
keys. S stores (EnvU, PubS, PrivS, PubU, kU) in a user-specific
record. If PrivS and PubS are used for multiple users, S can
store these values separately and omit them from the user's
record.
Note (salt). We note that in OPAQUE the OPRF key acts as the secret
salt value that ensures the infeasibility of pre-computation attacks.
No other salt value is needed.
Note (password rules). The above procedure has the significant
advantage that the user's password is never disclosed to the server
even during registration. Some sites require learning the user's
password for enforcing password rules. Doing so voids this important
Krawczyk Expires December 21, 2020 [Page 9]
Internet-Draft OPAQUE June 2020
security property of OPAQUE and is not recommended. Moving the
password check procedure to the client side is a more secure
alternative (limited checks at the server are possible to implement,
e.g., detecting repeated passwords).
3.2. Online OPAQUE protocol (Login and key exchange)
After registration, the user (through a client machine) and server
can run the OPAQUE protocol as a password-authenticated key exchange.
The protocol proceeds as follows:
o Client transmits user/account information to the server so that
the server can retrieve the user's record.
o Server and client execute the OPRF protocol as defined in
Section 2; client sets RwdU to the result of this computation (if
this computation includes a hardening function as in Section 2.2,
the parameters of this function are either known to the client or
communicated by the server).
o Server sends EnvU to client.
o Client authenticates/decrypts EnvU using RwdU to obtain PrivU,
PubS, and any of the optional values (PubU and parties'
identities) if included under EnvU. If authentication fails,
client aborts.
o Client and server run the specified KE protocol using their
respective public and private keys.
Note that the steps preceding the run of KE can be arranged in just
two messages (one from the client and a response from the server).
Furthermore, OPAQUE is optimized by running the OPRF and KE
concurrently with interleaved and combined messages (while preserving
the internal ordering of messages in each protocol). In all cases,
the client needs to obtain EnvU and RwdU (i.e., complete the OPRF
protocol) before it can use its own private key PrivU and the
server's public key PubS in the run of KE.
3.3. Parties' identities
Authenticated key-exchange protocols generate keys that need to be
uniquely and verifiably bound to a pair of identities, in the case of
OPAQUE a user and a server. Thus, it is essential for the parties to
agree on such identities, including an agreed bit representation of
these identities as needed, for example, when inputting identities to
a key derivation function. When referring to identities IdU and IdS
in this document, we refer to such agreed identities. Applications
Krawczyk Expires December 21, 2020 [Page 10]
Internet-Draft OPAQUE June 2020
may have different policies about how and when identities are
determined. A natural approach is to tie IdU to the identity the
server uses to fetch EnvU (hence determined during password
registration) and to tie IdS to the server identity used by the
client to initiate a password registration or login sessions. IdS
and IdU can also be part of EnvU or be tied to the parties' public
keys. In principle, it is possible that identities 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 user must always be those
defined at time of password registration.
4. Specification of the EnvU envelope
In Section 3.1, EnvU was defined as an envelope containing the user's
private key PrivU and server's public key PubS protected under RwdU.
Optionally, EnvU may also contain PubU and identities IdS, IdU. The
private key PrivU requires secrecy and authentication while the other
values need authentication but not necessarily secrecy. Here we
specify how such protection is implemented in OPAQUE. This is the
only mechanism specified for generating EnvU, it MUST NOT be modified
or replaced with other schemes (see the Security Considerations
section).
We define EnvU on the basis of two fields, SecEnv and ClrEnv. The
former contains information to be concealed by the envelope while
ClrEnv contains information included in cleartext form in EnvU.
PrivU is always included in SecEnv while PubS can be part of SecEnv
or ClrEnv as decided by the application. The latter also holds for
the optional values PubU, IdU, IdS.
Inputs to the enveloping function are SecEnv, ClrEnv (which may be
empty), and a fresh random nonce Nonce of length LH, where LH is the
output length in bytes of the hash function underlying HKDF.
Let LS be the length in bytes of SecEnv. Define:
KEYS = HKDF-Expand(key=RwdU, info=(nonce | "EnvU"), Length=LS+LH+LH)
Let PAD denote the LS left-most bytes of KEYS, HmacKey the next LH
bytes, and ExportKey the last LH bytes.
EnvU is generated during the Password Registration phase as follows:
(1) Set C = SecEnv XOR PAD
(2) Set E = Nonce | C | ClrEnv
(3) Set T = HMAC(HmacKey; E)
Krawczyk Expires December 21, 2020 [Page 11]
Internet-Draft OPAQUE June 2020
(4) Set EnvU to the pair (E,T)
When the client receives EnvU = (E,T) during the online OPAQUE phase,
it derives the stream KEYS using RwdU and Nonce as specified above,
it uses HmacKey to validate the received value T, and aborts if
verification fails. Otherwise, it uses PAD to recover SecEnv, and it
proceeds to run the KE part of OPAQUE using the information in SecEnv
and ClrEnv.
Note (Exporter key). The key ExportKey, part of the KEYS stream, is
not used by OPAQUE. Rather, it is exported to the calling
application for any purpose for which the application may require a
key. A typical example would be for the user to store additional
credentials or secret information (a private key, a cryptocurrency
wallet, a confidential file, etc.) encrypted under ExportKey at the
server. There is no restriction for the type of encryption scheme
used in this case. However, ExportKey MUST NOT be used in any way
before the HMAC value in EnvU is validated.
[[TODO: More precise specification needed here, such as default order
of elements in EnvU, their encodings, etc.]]
Note (storage/communication efficient EnvU): It is possible to
shorten EnvU by including PubS in ClrEnv and omitting SecEnv and any
other value from EnvU. In this case, the user's key PrivU is derived
from RwdU; e.g., the value PAD in KEYS is used as a seed for a key
generation procedure that outputs PrivU (the length of PAD will
depend on the specific key generation procedure). Such EnvU consists
of Nonce, PubS and the HMAC value, resulting in less storage at the
server and less communication from server to client. The server can
further minimize storage space by deriving per-user OPRF keys kU from
a single global secret key using a PRF, and it can use the same pair
(PrivS,PubS) for all its users. In this case, the per-user OPAQUE
storage consists of Nonce, PubU and HMAC(Khmac; PubS). While it may
be "tempting" to omit Nonce for space savings, this can lead to
vulnerabilities (see below).
[[TODO: Do we want to document the above option? Note that it
contradicts the earlier specification that mandates including PrivU
under SecEnv. This is to be decided according to whether people
think that the savings of PrivU in server's storage and communication
warrants this option.]]
Note (Necessity of Nonce): The random value Nonce used in the
derivation of PAD must not be omitted. Doing so leads to the
repeated use of the same PAD value in case that a user registers
twice the same password and the server reuses the same kU. This
results in the use of the same PAD for XORing two different values of
Krawczyk Expires December 21, 2020 [Page 12]
Internet-Draft OPAQUE June 2020
PrivU. Moreover, an adversarial server that intentionally reuses the
same kU with different users, will cause users with the same PwdU to
generate the same PAD, from which the server can learn information
about their respective PrivU values. This attack is particularly
damaging if PAD is used as a seed to derive PrivU.
[[Consider moving last paragraph to Security Considerations.]]
5. OPAQUE Instantiations
We present several instantiations of OPAQUE using DH-OPRF and
different KE protocols. For the sake of concreteness we focus on KE
protocols consisting of three messages, denoted KE1, KE2, KE3, and
such that KE1 and KE2 include DH values sent by user and server,
respectively, and KE3 provides explicit user authentication. As
shown in [OPAQUE], 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 of
using OPAQUE with protocols with more than 3 messages as in the case
of IKEv2 (or its underlying SIGMA-R protocol [SIGMA]).
OPAQUE generic outline with 3-message KE:
o C to S: IdU, alpha=H'(PwdU)^r, KE1
o S to C: beta=alpha^kU, EnvU, KE2
o C to S: KE3
Key derivation and other details of the protocol are specified by the
KE scheme. We do note that by the results in [OPAQUE], KE2 and KE3
should include authentication of the OPRF messages (or at least of
the value alpha) for binding between the OPRF run and the KE session.
Next, we present three instantiations of OPAQUE - with HMQV, 3DH and
SIGMA-I. In Section 6 we discuss integration with TLS 1.3 [RFC8446].
5.1. Instantiation of OPAQUE with HMQV and 3DH
The integration of OPAQUE with HMQV [HMQV] leads to the most
efficient instantiation of OPAQUE in terms of exponentiations count.
Performance is close to optimal due to the low cost of authentication
in HMQV: Just 1/6 of an exponentiation for each party over the cost
of a regular DH exchange. However, HMQV is encumbered by an IBM
patent, hence we also present OPAQUE with 3DH which only differs in
the key derivation function at the cost of an extra exponentiation
(and less resilience to the compromise of ephemeral exponents). We
Krawczyk Expires December 21, 2020 [Page 13]
Internet-Draft OPAQUE June 2020
note that 3DH serves as a basis for the key-exchange protocol of
[SIGNAL].
Importantly, many other protocols follow a similar format with
differences mainly in the key derivation function. This includes the
Noise family of protocols. Extension may also apply to KEM-based KE
protocols as in many post-quantum candidates.
The private and public keys of the parties in these examples are
Diffie-Hellman keys, namely, PubU=g^PrivU and PubS=g^PrivS.
Specification/implementation details that are specific to the choice
of group G will be adapted from the corresponding standards for
different elliptic curves.
PROTOCOL MESSAGES. OPAQUE with HMQV and OPAQUE with 3DH comprises:
o KE1 = OPRF1, nonceU, info1*, IdU*, ePubU
o KE2 = OPRF2, EnvU, nonceS, info2*, ePubS, Einfo2*, Mac(Km3;
xcript2),
o KE3 = info3*, Einfo3*, Mac(Km3; xcript3)}
where:
o * denotes optional elements;
o OPRF1, OPRF2 denote the DH-OPRF values alpha, beta sent by user
and server, respectively, as defined in Section 2;
o EnvU is the OPAQUE's envelope stored by the server containing
keying information for the client to run the AKE with the server;
o nonceU, nonceS are fresh random nonces chosen by client and
server, respectively;
o info1, info2, info3 denote optional application-specific
information sent in the clear (e.g., they can include parameter
negotiation, parameters for a hardening function, etc.);
o Einfo2, Einfo3 denotes optional application-specific information
sent encrypted under keys Ke2, Ke3 defined below;
o IdU is the user's identity used by the server to fetch the
corresponding user record, including EnvU, OPRF key, etc. (it can
be omitted from message KE1 if the information is available to the
server in some other way);
Krawczyk Expires December 21, 2020 [Page 14]
Internet-Draft OPAQUE June 2020
o IdS, the server's identity, is not shown explicitly, it can be
part of an info field (encrypted or not), part of EnvU, or can be
known from other context (see Section 3.3); it is used crucially
for key derivation (see below);
o ePubU, ePubS are Diffie-Hellman ephemeral public keys chosen by
user and server, respectively;
o xcript2 includes the concatenation of the values OPRF1, nonceU,
info1*, IdU*, ePubU, OPRF2, EnvU, nonceS, info2*, ePubS, Einfo2*;
o xcript3 includes the concatenation of all elements in xcript2
followed by info3*, Einfo3*;
Notes:
o The explicit concatenation of elements under xcript2 and xcript3
can be replaced with hashed values of these elements, or their
combinations, using a collision-resistant hash (e.g., as in the
transcript-hash of TLS 1.3).
o The inclusion of the values OPRF1 and OPRF2 under xcript2 is
needed for binding the OPRF execution to that of the KE session.
On the other hand, including EnvU in xcript2 is not mandatory.
o The ephemeral keys ePubU, ePubS, can be exchanged prior to the
above 3 messages, e.g., when running these protocols under TLS
1.3.
[[TODO: Specify that in the login phase, ephemeral DH values need to
be verified to belong to the correct group (via membership tests or
cofactor exponentiation). Same hold for public keys during the
registration phase. Details of verification depend on the particular
group/curve.]]
KEY DERIVATION. The above protocol requires MAC keys Km2, Km3, and
optional encryption keys Ke2, Ke3, as well as generating a session
key SK which is the AKE output for protecting subsequent traffic (or
for generating further key material). Key derivation uses HKDF
[RFC5869] with a combination of the parties static and ephemeral
private-public key pairs and the parties' identities IdU, IdS. See
Section 3.3.
SK, Km2, Km3, Ke2, Ke3 = HKDF(salt=0, IKM, info, L)
where L is the sum of lengths of SK, Km2, Km3, Ke2, Ke3, and SK gets
the most significant bytes of the HKDF output, Km2 the next bytes,
etc.
Krawczyk Expires December 21, 2020 [Page 15]
Internet-Draft OPAQUE June 2020
Values IKM and info are defined for each protocol:
For HMQV:
o info = "HMQV keys" | nonceU | nonceS | IdU | IdS
o IKM = Khmqv
where Khmqv is computed:
* by the client: Khmqv = (ePubS * PubS^s)^{ePrivU + u*PrivU}
* by the server: Khmqv = (ePubU * PubU^u)^{ePrivS + s*PrivS}
and u = H(ePubU | "user" | info); s = H(ePubS | "srvr" | info).
FOR 3DH:
o info = "3DH keys" | nonceU | nonceS | IdU | IdS
o IKM = K3dh
where K3dh is the concatenation of three DH values computed:
* by the client: K3dh = ePubS^ePrivU | PubS^ePrivU | ePubS^PrivU
* by the server: K3dh = ePubU^ePrivS | ePubU^PrivS | PubU^ePrivS
5.2. Instantiation of OPAQUE with SIGMA-I
We show how OPAQUE is built around the 3-message SIGMA-I protocol
[SIGMA]. This is an example of a signature-based protocol and also
serves as a basis for integration of OPAQUE with TLS 1.3, as the
latter follows the design of SIGMA-I (see Section 6. This
specification can be extended to the 4-message SIGMA-R protocol as
used in IKEv2.
PROTOCOL MESSAGES. OPAQUE with SIGMA-I comprises:
o KE1 = OPRF1, nonceU, info1*, IdU*, ePubU
o KE2 = OPRF2, EnvU, nonceS, info2*, ePubS, Einfo2*, Sign(PrivS;
xcript2-), Mac(Km2; IdS),
o KE3 = info3*, Einfo3*, Sign(PrivU; xcript3-), Mac(Km3; IdU)}
See explanation of fields above. In addition, for the signed
material, xcript2- is defined similarly to xcript2, however if
Krawczyk Expires December 21, 2020 [Page 16]
Internet-Draft OPAQUE June 2020
xcript2 includes information that identifies the user, such
information can be eliminated in xcript2- (this is advised if signing
user's identification information by the server is deemed to have
adverse privacy consequences). Similarly, xcript3- is defined as
xcript3 with server identification information removed if so desired.
KEY DERIVATION. Key in SIGMA-I are derived as
SK, Km2, Km3, Ke2, Ke3 = HKDF(salt=0, IKM, info, L)
where
o L is the sum of lengths of SK, Km2, Km3, Ke2, Ke3, and SK gets the
most significant bytes of the HKDF output, Km2 the next bytes,
etc.,
o info = "SIGMA-I keys" | nonceU | nonceS | IdU | IdS
o IKM = Ksigma
and Ksigma is computed:
* by the client: Ksigma = ePubS^ePrivU
* by the server: Ksigma = ePubU^ePrivS
6. Integrating OPAQUE with TLS 1.3
This section is intended as a discussion of ways to integrate OPAQUE
with TLS 1.3. Precise protocol details are left for a future
separate specification. A very preliminary draft is
[I-D.sullivan-tls-opaque].
As stated in the introduction, the security of the standard password-
over-TLS mechanism for password authentication suffers from its
essential reliance on PKI and the exposure of passwords to the server
(and possibly others) upon TLS decryption. Integrating OPAQUE with
TLS removes these vulnerabilities while at the same time it armors
TLS itself against PKI failures. Such integration also benefits
OPAQUE by leveraging the standardized negotiation and record-layer
security of TLS. Furthermore, TLS offers an initial PKI-
authenticated channel to protect the privacy of account information
such as user name transmitted between client and server.
If one is willing to forgo protection of user account information
transmitted between user and server, integrating OPAQUE with TLS 1.3
is relatively straightforward and follows essentially the same
approach as with SIGMA-I in Section 5.2. Specifically, one reuses
Krawczyk Expires December 21, 2020 [Page 17]
Internet-Draft OPAQUE June 2020
the Diffie-Hellman exchange from TLS and uses the user's private key
PrivU retrieved from the server as a signature key for TLS client
authentication. The integrated protocol will have as its first
message the TLS's Client Hello augmented with user account
information and with the DH-OPRF first message (the value alpha).
The server's response includes the regular TLS 1.3 second flight
augmented with the second OPRF message which includes the values beta
and EnvU. For its TLS signature, the server uses the private key
PrivS whose corresponding public key PubS is authenticated as part of
the user envelope EnvU (there is no need to send a regular TLS
certificate in this case). Finally, the third flight consists of the
standard client Finish message with client authentication where the
client's signature is produced with the user's private key PrivU
retrieved from EnvU and verified by the server using public key PubU.
The above scheme is depicted in Figure 1 where the sign + indicates
fields added by OPAQUE, and OPRF1, OPRF2 denote the two DH-OPRF
messages. Other messages in the figure are the same as in TLS 1.3.
Notation {...} indicates encryption under handshake keys. Note that
ServerSignature and ClientSignature are performed with the private
keys defined by OPAQUE and they replace signatures by traditional TLS
certificates.
Client Server
ClientHello
key_share
+ userid + OPRF1 -------->
ServerHello
key_share
{+ OPRF2 + EnvU}
{ServerSignature}
<-------- {ServerFinished}
{ClientSignature}
{ClientFinished} -------->
Figure 1: Integration of OPAQUE in TLS 1.3 (no userid
confidentiality)
Note that in order to send OPRF1 in the first message, the client
needs to know the DH group the server uses for OPRF, or it needs to
"guess" it. This issue already appears in TLS 1.3 where the client
needs to guess the key_share group and it should be handled similarly
in OPAQUE (e.g., the client may try one or more groups in its first
message).
Krawczyk Expires December 21, 2020 [Page 18]
Internet-Draft OPAQUE June 2020
Protection of user's account information can be added through TLS 1.3
pre-shared/resumption mechanisms where the account information
appended to the ClientHello message would be encrypted under the pre-
shared key.
When a resumable session or pre-shared key between the client and the
server do not exist, user account protection requires a server
certificate. One option that does not add round trips is to use a
mechanism similar to the proposed ESNI extension [I-D.ietf-tls-esni]
or a semi-static TLS exchange as in [I-D.ietf-tls-semistatic-dh].
Without such extensions, one would run a TLS 1.3 handshake augmented
with the two first OPAQUE messages interleaved between the second and
third flight of the regular TLS handshake. That is, the protocol
consists of five flights as follows: (i) A regular 2-flight 1-RTT
handshake to produce handshake traffic keys authenticated by the
server's TLS certificate; (ii) two OPAQUE messages that include user
identification information, the DH-OPRF messages exchanged between
client and server, and the retrieved EnvU, all encrypted under the
handshake traffic keys (thus providing privacy to user account
information); (iii) the TLS 1.3 client authentication flight where
client authentication uses the user's private signature key PrivU
retrieved from the server in step (ii).
Note that server authentication in step (i) uses TLS certificates
hence PKI is used for user account privacy but not for user
authentication or other purposes. (In some applications, PKI may be
trusted also for server authentication in which case server
authentication through OPAQUE may be forgone). In OPAQUE the server
authenticates using the private key PrivS whose corresponding public
key PubS is sent to the user as part of EnvU. There are two options:
If PubS is the same as the public key the server used in the 1-RTT
authentication (step (i)) then there is no need for further
authentication. Otherwise, the server needs to send a signature
under PrivS that is piggybacked to the second OPAQUE message in (ii).
In this case, the signature would cover the running transcript hash
as is standard in TLS 1.3. The client signature in the last message
also covers the transcript hash including the regular handshake and
OPAQUE messages.
The described scheme is depicted in Figure 2. Please refer to the
text before Figure 1 describing notation. Note the asterisk in the
ServerSignature message. This indicates that this message is
optional as it is used only if the server's key PubS in OPAQUE is
different than the one in the server's certificate (transmitted in
the second protocol flight).
Krawczyk Expires December 21, 2020 [Page 19]
Internet-Draft OPAQUE June 2020
Client Server
ClientHello
key_share -------->
ServerHello
key_share
{Certificate}
{CertificateVerify}
<-------- {ServerFinished}
{+ userid + OPRF1} -------->
{+ OPRF2 + EnvU}
<-------- {+ ServerSignature*}
{ClientSignature}
{ClientFinished} -------->
Figure 2: Integration of OPAQUE in TLS 1.3 (with userid
confidentiality)
We note that the above approaches for integration of OPAQUE with TLS
may benefit from the post-handshake client authentication mechanism
of TLS 1.3 and the exported authenticators from
[I-D.ietf-tls-exported-authenticator]. Also, formatting of messages
and negotiation information suggested in [I-D.barnes-tls-pake] can be
used in the OPAQUE setting.
7. User enumeration
User enumeration refers to attacks where the attacker tries to learn
whether a given user identity is registered with a server.
Preventing such attack requires the server to act with unknown user
identities in a way that is indistinguishable from its behavior with
existing users. Here we suggest a way to implement such defense,
namely, a way for simulating the values beta and EnvU for non-
existing users. Note that if the same pair of user identity IdU and
value alpha is received twice by the server, the response needs to be
the same in both cases (since this would be the case for real users).
For protection against this attack, one would apply the encryption
function in the construction of EnvU (Section 4) to all the key
material in EnvU, namely, AOenv will be empty. The server S will
have two keys MK, MK' for a PRF f (this refers to a regular PRF such
as HMAC or CMAC). Upon receiving a pair of user identity IdU and
value alpha for a non-existing user IdU, S computes kU=f(MK; IdU) and
kU'=f(MK'; IdU) and responds with values beta=alpha^kU and EnvU,
where the latter is computed as follows. RwdU is set to kU' and
AEenv is set to the all-zero string (of the length of a regular EnvU
Krawczyk Expires December 21, 2020 [Page 20]
Internet-Draft OPAQUE June 2020
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. Note that an attacker
that tests a IdU (and same alpha) twice and receives different
responses can conclude that either the user registered with the
service between these two activations or that the user was registered
before but changed its password in between the activations (assuming
the server changes kU at the time of a password change). In any
case, this indicates that IdU is a registered user at the time of the
second activation. To conceal this information, S can implement the
derivation of kU as kU=f(MK; IdU) also for registered users. Hiding
changes in EnvU, however, requires a change in the protocol. Instead
of sending EnvU as is, S would send an encryption of EnvU under a key
that the user derives from the OPRF result (similarly to RwdU) and
that S stores during password registration. During login, the user
will derive this key from the OPRF result, will use it to decrypt
EnvU, and continue with the regular protocol. If S uses a randomized
encryption, the encrypted EnvU will look each time as a fresh random
string, hence S can simulate the encrypted EnvU also for non-existing
users.
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.
[[TODO: Should this variant be documented/standardized?]]
8. Security considerations
This is a high-level draft presenting the OPAQUE concept and its
potential instantiations. Precise details and complete security
considerations will be provided in the upcoming draft-irtf-cfrg-
opaque. Implementations should be built on the basis of that
document and not the present one.
The security of OPAQUE is formally proved in [OPAQUE] under a strong
model of aPAKE security assuming the security of the OPRF function
and of the underlying key-exchange protocol. In turn, the security
of DH-OPRF is proven in the random oracle model under the One-More
Diffie-Hellman assumption [JKKX16].
Krawczyk Expires December 21, 2020 [Page 21]
Internet-Draft OPAQUE June 2020
Additionally, the above analysis sets requirements on the way
elements in the envelope EnvU are protected. Specifically, while one
can model such protection as an authenticated encryption scheme,
AuthEnc, with optional authenticated-only data, not all authenticated
encryption mechanisms are secure for creating EnvU. To be secure,
such a scheme needs to have the property of "random-key robustness"
(RKR). That is, given a pair of random AuthEnc keys, it should be
infeasible to create an authenticated ciphertext that successfully
decrypts (i.e., passes authentication) under the two keys. Some
natural AuthEnc schemes, including GCM and ChaCha20-Poly1305, do not
satisfy this property and MUST NOT be used for building EnvU (this is
not just a theoretical concern but one that may open OPAQUE to real
attacks).
To avoid wrong implementation choices, we have specified a simple and
efficient mechanism for generating and protecting EnvU (Section 4)
that ensures the required security properties and MUST NOT be
modified or replaced with other schemes. In particular, HMAC should
not be replaced with arbitrary MAC functions. A suitable MAC needs
to satisfy the above RKR property and many practical MAC functions,
particularly Carter-Wegman constructions such as GHASH and Poly1305,
are not RKR-secure. In contrast, HMAC enjoys a stronger form of
robustness: It is infeasible to find keys k1, k2 and messages M1, M2
so that HMAC(k1;M1) = HMAC(k2;M2) (it follows from collision
resistance of the underlying hash function). Yet, another element
necessary for the security of the enveloping scheme is the use of a
fresh random nonce for each EnvU.
Contents of EnvU should be restricted to OPAQUE-specific values
required for setting the keys used in the KE phase. Any functional
application-specific extensions should use the ExportKey (e.g., to
pass application-specific parameters, retrieve additional user
information stored at the server, etc.). ExportKey can be used with
any secure key derivation function or authenticated encryption.
However, it MUST NOT be used (by the client during the login phase)
before the HMAC value in EnvU has been verified.
Best practices regarding implementation of cryptographic schemes
apply to OPAQUE. Particular care needs to be given to the
implementation of the OPRF regarding testing group membership and
avoiding timing and other side channel leakage in the hash-to-curve
mapping. Drafts [I-D.irtf-cfrg-hash-to-curve] and
[I-D.irtf-cfrg-voprf] have detailed instantiation and implementation
guidance that will be integral part of the specification of OPAQUE.
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
Krawczyk Expires December 21, 2020 [Page 22]
Internet-Draft OPAQUE June 2020
Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an
attack that slightly improves on generic attacks. For the case that
q-1 or q+1, where q is the order of the group G, has a t-bit divisor,
they show an attack that calls the OPRF on 2^t chosen inputs and
reduces security by t/2 bits, i.e., it can find the OPRF key in time
2^{q/2-t/2} and 2^{q/2-t/2} memory. For typical curves, the attack
requires an infeasible number of calls and/or results in
insignificant security loss (*). Moreover, in the OPAQUE
application, these attacks are completely impractical as the number
of calls to the function translates to an equal number of failed
authentication attempts by a _single_ user. For example, one would
need a billion impersonation attempts to reduce security by 15 bits
and a trillion to reduce it by 20 bits - and most curves will not
even allow for such attacks in the first place (note that this
theoretical loss of security is with respect to computing discrete
logarithms, not in reducing the password strength).
(*) Some examples (courtesy of Dan Brown): For P-384, 2^90 calls
reduce security from 192 to 147 bits; for NIST P-256 the options are
6-bit reduction with 2153 OPRF calls, about 14 bit reduction with 187
million calls and 20 bits with a trillion calls. For Curve25519,
attacks are completely infeasible (require over 2^100 calls) but its
twist form allows an attack with 25759 calls that reduces security by
7 bits and one with 117223 calls that reduces security by 8.4 bits.
Note on user authentication vs. authenticated key exchange. OPAQUE
provides PAKE (password-based authenticated key exchange)
functionality in the client-server setting. While in the case of
user identification, focus is often on the authentication part, we
stress that the key exchange element is not less crucial. Indeed, in
most cases user authentication is performed to enforce some policy,
and the key exchange part is essential for binding this enforcement
to the authentication step. Skipping the key exchange part is
analogous to carefully checking a visitor's credential at the door
and then leaving the door open for others to enter freely.
This draft complies with the requirements for PAKE protocols set
forth in [RFC8125].
9. 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, Kevin Lewi, Payman Mohassel, Jason
Resch, Nick Sullivan and Chris Wood.
Krawczyk Expires December 21, 2020 [Page 23]
Internet-Draft OPAQUE June 2020
10. References
10.1. Normative References
[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/info/rfc2119>.
10.2. Informative References
[AuCPace] Haase, B. and B. Labrique, "AuCPace: Efficient verifier-
based PAKE protocol tailored for the IIoT",
http://eprint.iacr.org/2018/286 , 2018.
[BG04] Brown, D. and R. Galant, "The static Diffie-Hellman
problem", http://eprint.iacr.org/2004/306 , 2004.
[Blinding]
Jarecki, S., Krawczyk, H., and J. Xu, "Multiplicative DH-
OPRF and Its Applications to Password Protocols",
Manuscript , 2020.
[Boyen09] Boyen, X., "HPAKE: Password authentication secure against
cross-site user impersonation", Cryptology and Network
Security (CANS) , 2009.
[Canetti01]
Canetti, R., "Universally composable security: A new
paradigm for cryptographic protocols", IEEE Symposium on
Foundations of Computer Science (FOCS) , 2001.
[Cheon06] Cheon, J., "Security analysis of the strong Diffie-Hellman
problem", Euroctypt 2006 , 2006.
[FK00] Ford, W. and B. Kaliski, Jr, "Server-assisted generation
of a strong secret from a password", WETICE , 2000.
[GMR06] Gentry, C., MacKenzie, P., and . Z, Ramzan, "A method for
making password-based key exchange resilient to server
compromise", CRYPTO , 2006.
[HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie-
Hellman protocol", CRYPTO , 2005.
[I-D.barnes-tls-pake]
Barnes, R. and O. Friel, "Usage of PAKE with TLS 1.3",
draft-barnes-tls-pake-04 (work in progress), July 2018.
Krawczyk Expires December 21, 2020 [Page 24]
Internet-Draft OPAQUE June 2020
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
Encrypted Client Hello", draft-ietf-tls-esni-07 (work in
progress), June 2020.
[I-D.ietf-tls-exported-authenticator]
Sullivan, N., "Exported Authenticators in TLS", draft-
ietf-tls-exported-authenticator-12 (work in progress), May
2020.
[I-D.ietf-tls-semistatic-dh]
Rescorla, E., Sullivan, N., and C. Wood, "Semi-Static
Diffie-Hellman Key Establishment for TLS 1.3", draft-ietf-
tls-semistatic-dh-01 (work in progress), March 2020.
[I-D.irtf-cfrg-argon2]
Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "The memory-hard Argon2 password hash and
proof-of-work function", draft-irtf-cfrg-argon2-10 (work
in progress), March 2020.
[I-D.irtf-cfrg-hash-to-curve]
Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and
C. Wood, "Hashing to Elliptic Curves", draft-irtf-cfrg-
hash-to-curve-08 (work in progress), June 2020.
[I-D.irtf-cfrg-voprf]
Davidson, A., Sullivan, N., and C. Wood, "Oblivious
Pseudorandom Functions (OPRFs) using Prime-Order Groups",
draft-irtf-cfrg-voprf-03 (work in progress), March 2020.
[I-D.sullivan-tls-opaque]
Sullivan, N., Krawczyk, H., Friel, O., and R. Barnes,
"Usage of OPAQUE with TLS 1.3", draft-sullivan-tls-
opaque-00 (work in progress), March 2019.
[JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu,
"Highly-efficient and composable password-protected secret
sharing (or: how to protect your bitcoin wallet online)",
IEEE European Symposium on Security and Privacy , 2016.
[OPAQUE] Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An
Asymmetric PAKE Protocol Secure Against Pre-Computation
Attacks", Eurocrypt , 2018.
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",
RFC 2945, DOI 10.17487/RFC2945, September 2000,
<https://www.rfc-editor.org/info/rfc2945>.
Krawczyk Expires December 21, 2020 [Page 25]
Internet-Draft OPAQUE June 2020
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
August 2016, <https://www.rfc-editor.org/info/rfc7914>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
Password-Based Cryptography Specification Version 2.1",
RFC 8018, DOI 10.17487/RFC8018, January 2017,
<https://www.rfc-editor.org/info/rfc8018>.
[RFC8125] Schmidt, J., "Requirements for Password-Authenticated Key
Agreement (PAKE) Schemes", RFC 8125, DOI 10.17487/RFC8125,
April 2017, <https://www.rfc-editor.org/info/rfc8125>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[SIGMA] Krawczyk, H., "SIGMA: The SIGn-and-MAc approach to
authenticated Diffie-Hellman and its use in the IKE
protocols", CRYPTO , 2003.
[SIGNAL] "Signal recommended cryptographic algorithms",
https://signal.org/docs/specifications/
doubleratchet/#recommended-cryptographic-algorithms ,
2016.
[SPAKE2plus]
Shoup, V., "Security Analysis of SPAKE2+",
http://eprint.iacr.org/2020/313 , 2020.
Author's Address
Hugo Krawczyk
Algorand Foundation
Email: hugokraw@gmail.com
Krawczyk Expires December 21, 2020 [Page 26]
