< draft-krawczyk-cfrg-opaque-01.txt   draft-krawczyk-cfrg-opaque-02.txt >
Crypto Forum Research Group H. Krawczyk Crypto Forum Research Group H. Krawczyk
Internet-Draft IBM Research Internet-Draft Algorand Foundation
Intended status: Informational December 28, 2018 Intended status: Informational July 07, 2019
Expires: July 1, 2019 Expires: January 8, 2020
The OPAQUE Asymmetric PAKE Protocol The OPAQUE Asymmetric PAKE Protocol
draft-krawczyk-cfrg-opaque-01 draft-krawczyk-cfrg-opaque-02
Abstract Abstract
This draft describes the OPAQUE protocol, a secure asymmetric This draft describes the OPAQUE protocol, a secure asymmetric
password authenticated key exchange (aPAKE) that supports mutual password authenticated key exchange (aPAKE) that supports mutual
authentication in a client-server setting without any reliance on authentication in a client-server setting without reliance on PKI and
PKI. OPAQUE is the first PKI-free aPAKE to accommodate secret salt with security against pre-computation attacks upon server compromise.
and therefore it is the first to be secure against pre-computation Prior aPAKE protocols did not use salt and if they did, the salt was
attacks upon server compromise. In contrast, prior aPAKE protocols transmitted in the clear from server to user allowing for the
did not use salt and if they did, the salt was transmitted in the building of targeted pre-computed dictionaries. OPAQUE security has
clear from server to user allowing for the building of targeted been proven by Jarecki et al. (Eurocrypt 2018) in a strong and
pre-computed dictionaries. OPAQUE security has been proven by universally composable formal model of aPAKE security. In addition,
Jarecki et al. (Eurocrypt 2018) in a strong and universally the protocol provides forward secrecy and the ability to hide the
composable formal model of aPAKE security. In addition, the protocol password from the server even during password registration.
provides forward secrecy and the ability to hide the password from
the server even during password registration.
Strong security, good performance and an array of additional features Strong security, versatility through modularity, good performance,
make OPAQUE a natural candidate for practical use and for adoption as and an array of additional features make OPAQUE a natural candidate
a standard. To this end, this draft presents several optimized for practical use and for adoption as a standard. To this end, this
instantiations of OPAQUE and ways of integrating OPAQUE with TLS. draft presents several optimized instantiations of OPAQUE and ways of
integrating OPAQUE with TLS.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 4, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
1. Introduction 1. Introduction
Password authentication is the prevalent form of authentication in Password authentication is the prevalent form of authentication in
skipping to change at page 3, line 9 skipping to change at page 3, line 9
server compromise. server compromise.
Quite surprisingly, in spite of the existence of multiple designs for Quite surprisingly, in spite of the existence of multiple designs for
(PKI-free) aPAKE protocols, none of these protocols is secure against (PKI-free) aPAKE protocols, none of these protocols is secure against
pre-computation attacks. In particular, none of these protocols can pre-computation attacks. In particular, none of these protocols can
use the standard technique against pre-computation that combines use the standard technique against pre-computation that combines
_secret_ random values ("salt") into the one-way password mappings. _secret_ random values ("salt") into the one-way password mappings.
Either these protocols do not use salt at all or, if they do, they 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 transmit the salt from server to user in the clear, hence losing the
secrecy of the salt and its defense against pre-computation. secrecy of the salt and its defense against pre-computation.
Furthermore, the transmission of salt often incurs additional Furthermore, the transmission of salt may incur additional protocol
protocol messages. messages.
This draft describes OPAQUE, the first PKI-free secure aPAKE that is This draft describes OPAQUE, a PKI-free secure aPAKE that is secure
secure against pre-computation attacks and capable of using secret against pre-computation attacks and capable of using secret salt.
salt. OPAQUE has been recently defined and studied by Jarecki et al. OPAQUE has been recently defined and studied by Jarecki et al.
[OPAQUE] who prove the security of the protocol in a strong aPAKE [OPAQUE] who prove the security of the protocol in a strong aPAKE
model that ensures security against pre-computation attacks and is model that ensures security against pre-computation attacks and is
formulated in the Universal Composability framework [Canetti01] under formulated in the Universal Composability framework [Canetti01] under
the random oracle model. In contrast, very few aPAKE protocols have the random oracle model. In contrast, very few aPAKE protocols have
been proven formally and those proven were analyzed in a weak been proven formally and those proven were analyzed in a weak
security model that allows for pre-computation attacks (e.g., security model that allows for pre-computation attacks (e.g.,
[GMR06]). This is not just a formal issue: these protocols are [GMR06]). This is not just a formal issue: these protocols are
actually vulnerable to such attacks! Furthermore, as far as we know, actually vulnerable to such attacks! Furthermore, as far as we know,
protocols discussed recently as candidates for standardization (e.g., protocols discussed recently as candidates for standardization (e.g.,
SPAKE2+ [I-D.irtf-cfrg-spake2] and AugPAKE [RFC6628]) do not enjoy a SPAKE2+ [I-D.irtf-cfrg-spake2] and AugPAKE [RFC6628]) do not enjoy a
proof of security, not even in a weak model. The same holds for the proof of security, not even in a weak model. The same holds for the
SRP protocol [RFC2945]. VTBPEKE is analyzed in [VTBPEKE] in a weak SRP protocol [RFC2945]. VTBPEKE is analyzed in [VTBPEKE] in a weak
model that allows for pre-computation attacks and, as in all the model that allows for pre-computation attacks and, as in all the
above cases (except OPAQUE), does not accommodate secret salt. above cases (except OPAQUE), does not accommodate secret salt.
OPAQUE's design is based on the seminal work of Ford and Kaliski OPAQUE's design builds on a line of work initiated in the seminal
[FK00] with variants studied by Boyen [Boyen09] and Jarecki et al. paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol
[JKKX16], although none of these papers presented a proof of aPAKE of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et
security (not even in a weak model). 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, In addition to its proven resistance to pre-computation attacks,
OPAQUE's security features include forward secrecy (essential for OPAQUE's security features include forward secrecy (essential for
protecting past communications in case of password leakage) and the protecting past communications in case of password leakage) and the
ability to hide the password from the server - even during password ability to hide the password from the server - even during password
registration. Moreover, good performance and an array of additional registration. Moreover, good performance and an array of additional
features make OPAQUE a natural candidate for practical use and for features make OPAQUE a natural candidate for practical use and for
adoption as a standard. Such features include the ability to adoption as a standard. Such features include the ability to
increase the difficulty of offline dictionary attacks via iterated increase the difficulty of offline dictionary attacks via iterated
hashing (or other hardening schemes) and offloading these operations hashing (or other hardening schemes) and offloading these operations
skipping to change at page 4, line 18 skipping to change at page 4, line 18
protocol (with KCI security - see below) into a secure aPAKE protocol (with KCI security - see below) into a secure aPAKE
protocol. In OPAQUE, the user stores a secret private key at the protocol. In OPAQUE, the user stores a secret private key at the
server during password registration and retrieves this key each time server during password registration and retrieves this key each time
it needs to authenticate to the server. The OPRF security properties it needs to authenticate to the server. The OPRF security properties
ensure that only the correct password can unlock the private key ensure that only the correct password can unlock the private key
while at the same time avoiding potential offline guessing attacks. while at the same time avoiding potential offline guessing attacks.
This general composability property provides great flexibility and This general composability property provides great flexibility and
enables a variety of OPAQUE instantiations, from optimized enables a variety of OPAQUE instantiations, from optimized
performance to integration with TLS. The latter aspect is of prime performance to integration with TLS. The latter aspect is of prime
importance as the use of OPAQUE with TLS constitutes a major security importance as the use of OPAQUE with TLS constitutes a major security
improvement relative to the standard password-over-TLS practice. improvement relative to the standard password-over-TLS practice. At
At the same time, the combination with TLS builds OPAQUE as a fully the same time, the combination with TLS builds OPAQUE as a fully
functional secure communications protocol and can help provide functional secure communications protocol and can help provide
privacy to account information sent by the user to the server prior privacy to account information sent by the user to the server prior
to authentication. to authentication.
The KCI property required from KE protocols for use with OPAQUE The KCI property required from KE protocols for use with OPAQUE
states that knowledge of a party's private key does not allow an states that knowledge of a party's private key does not allow an
attacker to impersonate others to that party. This is an important attacker to impersonate others to that party. This is an important
security property achieved by most public-key based KE protocols, security property achieved by most public-key based KE protocols,
including protocols that use signatures or public key encryption for including protocols that use signatures or public key encryption for
authentication. It is also a property of many implicitly authentication. It is also a property of many implicitly
skipping to change at page 4, line 43 skipping to change at page 4, line 43
setting. We note that KCI is needed to ensure a crucial property of setting. We note that KCI is needed to ensure a crucial property of
OPAQUE: even upon compromise of the server, the attacker cannot OPAQUE: even upon compromise of the server, the attacker cannot
impersonate the user to the server without first running an impersonate the user to the server without first running an
exhaustive dictionary attack. exhaustive dictionary attack.
This draft defines OPAQUE with a specific, efficient instantiation This draft defines OPAQUE with a specific, efficient instantiation
over elliptic curves of the OPRF component and with a few KE schemes, over elliptic curves of the OPRF component and with a few KE schemes,
including the HMQV [HMQV] and SIGMA [SIGMA] protocols, as well as including the HMQV [HMQV] and SIGMA [SIGMA] protocols, as well as
several suggestions for integrating OPAQUE with TLS 1.3 [RFC8446] several suggestions for integrating OPAQUE with TLS 1.3 [RFC8446]
offering different tradeoffs between simplicity, performance and user offering different tradeoffs between simplicity, performance and user
privacy. privacy. See also the companion draft [I-D.sullivan-tls-opaque]. In
general, the modularity of OPAQUE's design makes it easy to integrate
with additional key-exchange protocols, e.g., IKE.
The computational cost of OPAQUE is determined by the cost of the 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 OPRF, the cost of a regular Diffie-Hellman exchange, and the cost of
authenticating such exchange. In our elliptic-curve implementation authenticating such exchange. In our elliptic-curve implementation
of the OPRF, the cost for the client is two exponentiations (one or of the OPRF, the cost for the client is two exponentiations (one or
two of which can be fixed base) and one hashing-into-curve operation 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 [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 exponentiation. The cost of a Diffie-Hellman exchange is as usual
two exponentiations per party (one of which is fixed-base). Finally, two exponentiations per party (one of which is fixed-base). Finally,
the cost of authentication per party depends on the specific KE the cost of authentication per party depends on the specific KE
protocol: it is just 1/6 of an exponentiation with HMQV and it is one protocol: it is just 1/6 of an exponentiation with HMQV and it is one
signature in the case of SIGMA and TLS 1.3. These instantiations signature in the case of SIGMA and TLS 1.3. These instantiations
preserve the number of messages (two or three) in the underlying KE preserve the number of messages (two or three) in the underlying KE
protocol except in one of the TLS instantiations where user privacy protocol except in one of the TLS instantiations where user privacy
requires an additional round trip. requires an additional round trip (this can be saved if using a
mechanism similar to the proposed ESNI extension
[I-D.ietf-tls-esni]).
1.1. Terminology 1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] [RFC2119]
1.2. Notation 1.2. Notation
skipping to change at page 5, line 49 skipping to change at page 6, line 5
and a user U defined by a special pseudorandom function (PRF), 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 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 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 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 from the protocol execution (in particular nothing about x or the
value F(k;x)). value F(k;x)).
OPAQUE uses a specific OPRF instantiation, called DH-OPRF, where the OPAQUE uses a specific OPRF instantiation, called DH-OPRF, where the
PRF, denoted F, is defined as follows. PRF, denoted F, is defined as follows.
[Author note: It would be good to align this OPRF specification with [To do: Align this OPRF specification with [I-D.sullivan-cfrg-voprf]
[I-D.sullivan-cfrg-voprf] and its defined instantiation suites, but and its defined instantiation suites.]
it will require extending that specification to accommodate non-
verifiable OPRFs.]
Parameters: Hash function H (e.g., a SHA2 or SHA3 function), a cyclic Parameters: Hash function H (e.g., a SHA2 or SHA3 function), a cyclic
group G of prime order q, a generator g of G, and hash function H' 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 mapping arbitrary strings into G (where H' is modeled as a random
oracle). oracle).
o DH-OPRF domain: Any string o DH-OPRF domain: Any string
o DH-OPRF range: The range of the hash function H o DH-OPRF range: The range of the hash function H
skipping to change at page 7, line 16 skipping to change at page 7, line 16
Protocol OPAQUE can be further strengthened against offline Protocol OPAQUE can be further strengthened against offline
dictionary attacks by applying to the output of DH-OPRF an iterated dictionary attacks by applying to the output of DH-OPRF an iterated
hash for some number n of iterations. This increases the cost of an hash for some number n of iterations. This increases the cost of an
offline attack upon the compromise of the server as the attacker will offline attack upon the compromise of the server as the attacker will
need to perform n iterations for each guess of PwdU it tries to need to perform n iterations for each guess of PwdU it tries to
validate. For this purpose we would re-define DH-OPRF as validate. For this purpose we would re-define DH-OPRF as
F(k;x) = I^n( H(x, v, H'(x)^k) ) where I is an appropriately chosen F(k;x) = I^n( H(x, v, H'(x)^k) ) where I is an appropriately chosen
function and the symbol I^n denotes n iterations of function I. More function and the symbol I^n denotes n iterations of function I. More
generally, any form of hardened password-based key derivation can be generally, any form of hardened password-based key derivation can be
used, e.g., PBKDF2 [RFC2898], Argon 2 [I-D.irtf-cfrg-argon2], scrypt used, e.g., PBKDF2 [RFC8018], Argon 2 [I-D.irtf-cfrg-argon2], scrypt
[RFC7914]. As we will see, in OPAQUE it is the user who runs this [RFC7914]. As we will see, in OPAQUE it is the user who runs this
key derivation. The iteration value n or any other parameter key derivation. The iteration value n or any other parameter
required by these functions can be set as public constants or can be required by these functions can be set as public constants or can be
set at time of password registration and later communicated by the set at time of password registration and later communicated by the
server as part of its OPAQUE message. (Note; these hardened KDFs server as part of its OPAQUE message. (Note; these hardened KDFs
often require a salt value as input; for OPAQUE this value can be be often require a salt value as input; for OPAQUE this value can be be
set to a constant, e.g., all zeros.) set to a constant, e.g., all zeros.)
3. OPAQUE Specification 3. OPAQUE Specification
skipping to change at page 8, line 18 skipping to change at page 8, line 18
learning the result, denoted RwdU (mnemonics for "Randomized learning the result, denoted RwdU (mnemonics for "Randomized
PwdU"). PwdU").
o U generates an "envelope" EnvU defined as o U generates an "envelope" EnvU defined as
EnvU = AuthEnc(RwdU; PrivU, PubU, PubS) EnvU = AuthEnc(RwdU; PrivU, PubU, PubS)
where AuthEnc is an authenticated encryption function with the where AuthEnc is an authenticated encryption function with the
"key committing" property and is specified in Section 3.1.1 below. "key committing" property and is specified in Section 3.1.1 below.
In EnvU, all values require authentication and PrivU also requires In EnvU, all values require authentication and PrivU also requires
encryption. PubU can be omitted from EnvU if it can be encryption. However, for simplicity and to hide the EnvU
reconstructed from PrivU but while it will save bits on the wire contents, we specify that all values are encrypted (not just
it will come at some computational cost during client authenticated). PubU can be omitted from EnvU if it is not needed
authentication. for running the key-exchange protocol by the client or if it can
be reconstructed from PrivU.
o U sends EnvU and PubU to S and erases PwdU, RwdU and all keys. o U sends EnvU and PubU to S and erases PwdU, RwdU and all keys.
S stores (EnvU, PubS, PrivS, PubU, kU, vU) in a user-specific S stores (EnvU, PubS, PrivS, PubU, kU, vU) in a user-specific
record. If PrivS and PubS are used for multiple users, S can record. If PrivS and PubS are used for multiple users, S can
store these values separately and omit them from the user's store these values separately and omit them from the user's
record. record.
Note (salt). We note that in OPAQUE the OPRF key acts as the secret Note (salt). We note that in OPAQUE the OPRF key acts as the secret
salt value that ensures the infeasibility of pre-computation attacks. salt value that ensures the infeasibility of pre-computation attacks.
No extra salt value is needed. No extra salt value is needed.
skipping to change at page 8, line 44 skipping to change at page 8, line 45
advantage that the user's password is not disclosed to the server advantage that the user's password is not disclosed to the server
even during registration. Some sites require learning the user's even during registration. Some sites require learning the user's
password for enforcing password rules. Doing so voids this important password for enforcing password rules. Doing so voids this important
security property of OPAQUE and is not recommended. Moving the security property of OPAQUE and is not recommended. Moving the
password check procedure to the client side is a more secure password check procedure to the client side is a more secure
alternative. alternative.
3.1.1. Implementing the EnvU envelop 3.1.1. Implementing the EnvU envelop
The function AuthEnc used to compute EnvU needs to satisfy a property The function AuthEnc used to compute EnvU needs to satisfy a property
called "key committing". That is, given a pair of random AuthEnc called "key committing" (a.k.a. robust encryption). That is, given a
keys, it should be infeasible to create an authenticated ciphertext pair of random AuthEnc keys, it should be infeasible to create an
that successfully decrypts under the two keys. This restricts authenticated ciphertext that successfully decrypts under the two
significantly the AuthEnc methods for use, particularly disallowing keys. Not all AuthEnc schemes enjoy this property, and this includes
GCM. We thus specify the AuthEnc function to be implemented via the standard GCM mode. To address this issue we slightly modify GCM
"encrypt-then-hmac" which provably meets this requirement. That is, to achieve robustness.
EnvU will consist of an encryption of the values PrivU, PubU, PubS
(concatenated using an unambiguous encoding), with HMAC computed on To the plaintext specified by the definition of EnvU, concatenate a
the resultant ciphertext. Any secure encryption can be used but the string of all zeros so that the last full block of the resultant
MAC needs to be collision resistant which HMAC satisfies (with a tag plaintext is an all-zero block (of the length of the underlying block
size of at least 256 bits). Note that this requires two separate cipher, i.e., 128 for AES). Use regular GCM on this augmented
keys for the encryption and MAC parts which can be derived from a plaintext with a nonce value of zero.
single key using, for example, the HKDF-Expand function from
[RFC5869]. We note that while encryption of PubU and PubS is not [Author note: A random nonce can be used if one assumes that the
strictly required, only authentication, we have included these values following problem is infeasible: Given two random keys for the block
under the encryption for the sake of simplicity. Furthermore, cipher, find an input of a block length that encrypts to the same
encrypting PubU and PubS helps defending against "user enumeration" ciphertext under both keys. Is AES secure in this sense?]
as discussed in Section 5.
Following are two alternative methods to achieve encryption
robustness (presented here for completeness in case any of these are
preferred to the above method):
(1) Encrypt-then-HMAC: Implement the AuthEnc scheme using any
encryption function in encrypt-then-MAC mode where the MAC is
implemented with HMAC with a tag size of at least 256 bits (HMAC
ensures a collision-resistant property needed to ensure robustness).
This requires two separate keys, one for encryption and one for HMAC,
which can be derived from RwdU using, for example, the HKDF-Expand
function from [RFC5869].
[Author note: Is there a standardized definition of Encrypt-then-HMAC [Author note: Is there a standardized definition of Encrypt-then-HMAC
that one can refer? Here is a description from signal [SIGNAL].] that one can refer? Here is a description from signal [SIGNAL].]
(2) Fixed-string MAC: Any AuthEnc method is key committing if one
concatenates to the AuthEnc output a MAC computed on a fixed string.
Specifically, one derives two keys from RwdU: one is a key to the
AuthEnc function and the other is a key to a MAC (any secure MAC
function works). EnvU is then defined as before except that to the
output of AuthEnc one concatenates the output of the MAC function
computed with the second derived key on a fixed string (e.g., all
zeros).
3.2. Online OPAQUE protocol 3.2. Online OPAQUE protocol
After registration, the user and server can run the OPAQUE protocol After registration, the user and server can run the OPAQUE protocol
as a password-authenticated key exchange. The protocol proceeds as as a password-authenticated key exchange. The protocol proceeds as
follows: follows:
o User transmits user/account information to the server so that the o User transmits user/account information to the server so that the
server can retrieve the user's record. server can retrieve the user's record.
o Server sends EnvU and vU to user. o Server sends EnvU and vU to user.
skipping to change at page 11, line 21 skipping to change at page 11, line 42
This is a minimal skeleton. A fully-specified protocol will include This is a minimal skeleton. A fully-specified protocol will include
additional details and a careful key derivation scheme. In additional details and a careful key derivation scheme. In
particular, the Mac computation will cover the whole preceding particular, the Mac computation will cover the whole preceding
transcript. In addition, the parties will check group membership for transcript. In addition, the parties will check group membership for
g^x, g^y or use co-factor computation, e.g., as in g^x, g^y or use co-factor computation, e.g., as in
[I-D.irtf-cfrg-spake2]; in any case the value is rejected if it [I-D.irtf-cfrg-spake2]; in any case the value is rejected if it
equals the identity. The check for PubU and PubS can be done only equals the identity. The check for PubU and PubS can be done only
once at user registration. once at user registration.
Note (HMQV patent): IBM has a patent that covers HMQV. While the Note (IP disclosure): IBM has a patent that covers HMQV. If there is
author does not speak in the name of IBM or with any legal authority, interest in standardizing this mode one can check if a free license
he has reason to believe that if there will be a serious interest in of the HMQV patent could be provided for such use.
standardizing OPAQUE with HMQV, the patent may not be an impediment.
3.3.2. Instantiation with SIGMA-I 3.3.2. Instantiation with SIGMA-I
We show how OPAQUE can be built around the 3-message SIGMA-I protocol We show how OPAQUE can be built around the 3-message SIGMA-I protocol
[SIGMA]. This example is significant as it shows integration with a [SIGMA]. This example is significant as it shows integration with a
signature-based KE protocol and because TLS 1.3 follows the design of signature-based KE protocol and because TLS 1.3 follows the design of
SIGMA-I hence the example helps understanding the proposed SIGMA-I hence the example helps understanding the proposed
integration of OPAQUE with TLS in [RFC8446]. integration of OPAQUE with TLS in [RFC8446].
SIGMA-I can be represented schematically as follows: SIGMA-I can be represented schematically as follows:
skipping to change at page 12, line 25 skipping to change at page 12, line 42
registration and stored at the server. In this case, the server registration and stored at the server. In this case, the server
communicates these parameters to the user during OPAQUE executions communicates these parameters to the user during OPAQUE executions
together with the second OPRF message. We note that the salt value 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 typically input into the KDF can be set to a constant, e.g., all
zeros. zeros.
4. Integrating OPAQUE with TLS 1.3 4. Integrating OPAQUE with TLS 1.3
Note: This section is intended as a basis for discussion on ways to Note: This section is intended as a basis for discussion on ways to
integrate OPAQUE with TLS (particularly TLS 1.3). Precise protocol integrate OPAQUE with TLS (particularly TLS 1.3). Precise protocol
details are left for a future specification. details are left for a future specification. A preliminary draft is
[I-D.sullivan-tls-opaque].
As stated in the introduction, the standard password-over-TLS As stated in the introduction, the standard password-over-TLS
mechanism for password authentication suffers from significant mechanism for password authentication suffers from significant
weaknesses due to the essential reliance of the protocol on PKI and weaknesses due to the essential reliance of the protocol on PKI and
the exposure of passwords to the server (and other observers) upon the exposure of passwords to the server (and other observers) upon
TLS decryption. Here we propose integrating OPAQUE with TLS in order TLS decryption. Here we propose integrating OPAQUE with TLS in order
to remove these vulnerabilities while at the same time armoring TLS to remove these vulnerabilities while at the same time armoring TLS
itself against PKI failures. Such integration also benefits OPAQUE itself against PKI failures. Such integration also benefits OPAQUE
by leveraging the standardized negotiation and record-layer security by leveraging the standardized negotiation and record-layer security
of TLS. Furthermore, TLS can offer an initial PKI-authenticated of TLS. Furthermore, TLS can offer an initial PKI-authenticated
skipping to change at page 13, line 49 skipping to change at page 14, line 36
in OPAQUE (e.g., the client may try one or more groups in its first in OPAQUE (e.g., the client may try one or more groups in its first
message). message).
Protection of user's account information can be added through TLS 1.3 Protection of user's account information can be added through TLS 1.3
pre-shared/resumption mechanisms where the account information pre-shared/resumption mechanisms where the account information
appended to the ClientHello message would be encrypted under the pre- appended to the ClientHello message would be encrypted under the pre-
shared key. shared key.
When a resumable session or pre-shared key between the client and the When a resumable session or pre-shared key between the client and the
server do not exist, user account protection requires a server server do not exist, user account protection requires a server
certificate. In this case, the TLS 1.3 handshake is augmented with certificate. One option that does not add round trips is to use a
the two OPAQUE messages interleaved between the second and third mechanism similar to the proposed ESNI extension [I-D.ietf-tls-esni].
Without such extension, one would run a TLS 1.3 handshake augmented
with the two OPAQUE messages interleaved between the second and third
flight of the regular TLS handshake. That is, the protocol consists 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 of five flights as follows: (i) A regular 2-flight 1-RTT handshake to
produce handshake traffic keys authenticated by the server's TLS produce handshake traffic keys authenticated by the server's TLS
certificate; (ii) two messages that include user identification certificate; (ii) two messages that include user identification
information, the DH-OPRF messages exchanged between client and information, the DH-OPRF messages exchanged between client and
server, and the retrieved vU and EnvU, all encrypted under the server, and the retrieved vU and EnvU, all encrypted under the
handshake traffic keys (thus providing privacy to user account handshake traffic keys (thus providing privacy to user account
information); (iii) the TLS 1.3 client authentication flight where information); (iii) the TLS 1.3 client authentication flight where
client authentication uses the user's private signature key PrivU client authentication uses the user's private signature key PrivU
retrieved from the server in step (ii). retrieved from the server in step (ii).
skipping to change at page 16, line 19 skipping to change at page 16, line 43
prevention would require a change in OPAQUE. Note that an attacker prevention would require a change in OPAQUE. Note that an attacker
that tests a UId (and same alpha) twice and receives different that tests a UId (and same alpha) twice and receives different
responses can conclude that either the user registered with the responses can conclude that either the user registered with the
service between these two activations or that the user was registered service between these two activations or that the user was registered
before but changed its password in between the activations (assuming before but changed its password in between the activations (assuming
the server changes kU at the time of a password change). In any the server changes kU at the time of a password change). In any
case, this indicates that UId is a registered user at the time of the case, this indicates that UId is a registered user at the time of the
second activation. To conceal this information, S can implement the second activation. To conceal this information, S can implement the
derivation of kU as kU=f(MK; UId) also for registered users. Hiding derivation of kU as kU=f(MK; UId) also for registered users. Hiding
changes in EnvU, however, requires a change in the protocol. Instead changes in EnvU, however, requires a change in the protocol. Instead
of sending EnvU as is, we specify that S sends an encryption of EnvU of sending EnvU as is, S would send an encryption of EnvU under a key
under a key that the user derives from the OPRF result (similarly to that the user derives from the OPRF result (similarly to RwdU) and
RwdU) and that S stores during password registration. During login, that S stores during password registration. During login, the user
the user will derive this key from the OPRF result, use it to decrypt will derive this key from the OPRF result, use it to decrypt EnvU,
EnvU, and continue with the regular protocol. If S uses a randomized and continue with the regular protocol. If S uses a randomized
encryption, the encrypted EnvU will look each time as a fresh random encryption, the encrypted EnvU will look each time as a fresh random
string, hence S can simulate the encrypted EnvU also for non-existing string, hence S can simulate the encrypted EnvU also for non-existing
users. users.
[Author note: How significant is the user enumeration issue? The [Author note: How significant is the user enumeration issue? The
first case above does not change the protocol so its implementation first case above does not change the protocol so its implementation
is a server's decision. The second case, however, requires a change is a server's decision. The second case, however, requires a change
in OPAQUE so it would be important to have feedback on whether this in OPAQUE so it would be important to have feedback on whether this
second order attack justifies such change.] second order attack justifies such change.]
skipping to change at page 16, line 45 skipping to change at page 17, line 22
This is an early draft presenting the OPAQUE concept and its This is an early draft presenting the OPAQUE concept and its
potential instantiations. More precise details and security potential instantiations. More precise details and security
considerations will be provided in future drafts. We note that the considerations will be provided in future drafts. We note that the
security of OPAQUE is formally proved in [OPAQUE] under a strong security of OPAQUE is formally proved in [OPAQUE] under a strong
model of aPAKE security assuming the security of the OPRF function model of aPAKE security assuming the security of the OPRF function
and of the underlying key-exchange protocol. In turn, the security 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 of DH-OPRF is proven in the random oracle model under the One-More
Diffie-Hellman assumption [JKKX16]. Diffie-Hellman assumption [JKKX16].
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.sullivan-cfrg-voprf] have detailed instantiation and
implementation guidance.
While one can expect the practical security of the OPRF function While one can expect the practical security of the OPRF function
(namely, the hardness of computing the function without knowing the (namely, the hardness of computing the function without knowing the
key) to be in the order of computing discrete logarithms or solving key) to be in the order of computing discrete logarithms or solving
Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an
attack that slightly improves on generic attacks. For the case that 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, 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 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 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 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 requires an infeasible number of calls and/or results in
skipping to change at page 17, line 33 skipping to change at page 18, line 17
7 bits and one with 117223 calls that reduces security by 8.4 bits. 7 bits and one with 117223 calls that reduces security by 8.4 bits.
Note on user authentication vs. authenticated key exchange. OPAQUE Note on user authentication vs. authenticated key exchange. OPAQUE
provides PAKE (password-based authenticated key exchange) provides PAKE (password-based authenticated key exchange)
functionality in the client-server setting. While in the case of functionality in the client-server setting. While in the case of
user identification, focus is often on the authentication part, we user identification, focus is often on the authentication part, we
stress that the key exchange element is not less crucial. Indeed, in stress that the key exchange element is not less crucial. Indeed, in
most cases user authentication is performed to enforce some policy, most cases user authentication is performed to enforce some policy,
and the key exchange part is essential for binding this enforcement and the key exchange part is essential for binding this enforcement
to the authentication step. Skipping the key exchange part is to the authentication step. Skipping the key exchange part is
analogous to carefully checking visitor credentials at the door but analogous to carefully checking visitor credentials at the door and
then leaving the door open after a first visitor is allowed to enter. then leaving the door open after a first visitor is allowed to enter.
This draft complies with the requirements for PAKE protocols set
forth in [RFC8125].
7. Acknowledgments 7. Acknowledgments
The OPAQUE protocol is the product of joint work of the author with The OPAQUE protocol and its analysis is joint work of the author with
Stas Jarecki and Jiayu Xu, and builds on a line of work initiated in Stas Jarecki and Jiayu Xu. This draft has benefited from comments by
the seminal paper by Ford and Kaliski [FK00]. This draft has multiple people. Special thanks to Dan Brown, Eric Crockett, Fredrik
benefited from comments by multiple people. Special thanks to Dan Kuivinen, Jason Resch, Nick Sullivan.
Brown, Eric Crockett, Fredrik Kuivinen, Jason Resch, Nick Sullivan.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 8.2. Informative References
[BG04] Brown, D. and R. Galant, "The static Diffie-Hellman
problem", http://eprint.iacr.org/2004/306 , 2004.
[Boyen09] Boyen, X., "HPAKE: Password authentication secure against [Boyen09] Boyen, X., "HPAKE: Password authentication secure against
cross-site user impersonation", Cryptology and Network cross-site user impersonation", Cryptology and Network
Security (CANS) , 2009. Security (CANS) , 2009.
[BG04] Brown, D. and R. Galant, "The static Diffie-Hellman
problem", http://eprint.iacr.org/2004/306 , 2004.
[Canetti01] [Canetti01]
Canetti, R., "Universally composable security: A new Canetti, R., "Universally composable security: A new
paradigm for cryptographic protocols", IEEE Symposium on paradigm for cryptographic protocols", IEEE Symposium on
Foundations of Computer Science (FOCS) , 2001. Foundations of Computer Science (FOCS) , 2001.
[Cheon06] Cheon, J., "Security analysis of the strong Diffie-Hellman [Cheon06] Cheon, J., "Security analysis of the strong Diffie-Hellman
problem", Euroctypt 2006 , 2006. problem", Euroctypt 2006 , 2006.
[FK00] Ford, W. and B. Kaliski, Jr, "Server-assisted generation [FK00] Ford, W. and B. Kaliski, Jr, "Server-assisted generation
of a strong secret from a password", WETICE , 2000. of a strong secret from a password", WETICE , 2000.
[GMR06] Gentry, C., MacKenzie, P., and . Z, Ramzan, "A method for [GMR06] Gentry, C., MacKenzie, P., and . Z, Ramzan, "A method for
making password-based key exchange resilient to server making password-based key exchange resilient to server
compromise", CRYPTO , 2006. compromise", CRYPTO , 2006.
[I-D.ietf-tls-exported-authenticator] [HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie-
Sullivan, N., "Exported Authenticators in TLS", draft- Hellman protocol", CRYPTO , 2005.
ietf-tls-exported-authenticator-07 (work in progress),
June 2018.
[I-D.barnes-tls-pake] [I-D.barnes-tls-pake]
Barnes, R. and O. Friel, "Usage of SPAKE with TLS 1.3", Barnes, R. and O. Friel, "Usage of PAKE with TLS 1.3",
draft-barnes-tls-pake-02 (work in progress), June 2018. draft-barnes-tls-pake-04 (work in progress), July 2018.
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
"Encrypted Server Name Indication for TLS 1.3", draft-
ietf-tls-esni-03 (work in progress), March 2019.
[I-D.ietf-tls-exported-authenticator]
Sullivan, N., "Exported Authenticators in TLS", draft-
ietf-tls-exported-authenticator-09 (work in progress), May
2019.
[I-D.irtf-cfrg-argon2] [I-D.irtf-cfrg-argon2]
Biryukov, A., Dinu, D., Khovratovich, D., and S. Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "The memory-hard Argon2 password hash and Josefsson, "The memory-hard Argon2 password hash and
proof-of-work function", draft-irtf-cfrg-argon2-03 (work proof-of-work function", draft-irtf-cfrg-argon2-06 (work
in progress), August 2017. in progress), June 2019.
[I-D.irtf-cfrg-spake2]
Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", draft-irtf-cfrg-
spake2-05 (work in progress), February 2018.
[I-D.irtf-cfrg-hash-to-curve] [I-D.irtf-cfrg-hash-to-curve]
Scott, S., Sullivan, N., and C. Wood, "Hashing to Elliptic Scott, S., Sullivan, N., and C. Wood, "Hashing to Elliptic
Curves", draft-irtf-cfrg-hash-to-curve-01 (work in Curves", draft-irtf-cfrg-hash-to-curve-03 (work in
progress), July 2018. progress), March 2019.
[I-D.irtf-cfrg-spake2]
Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", draft-irtf-cfrg-
spake2-08 (work in progress), March 2019.
[I-D.sullivan-cfrg-voprf] [I-D.sullivan-cfrg-voprf]
Davidson, A., Sullivan, N., and C. Wood, "Verifiable Davidson, A., Sullivan, N., and C. Wood, "Oblivious
Oblivious Pseudorandom Functions (VOPRFs) in Prime-Order Pseudorandom Functions (OPRFs) using Prime-Order Groups",
Groups", draft-sullivan-cfrg-voprf-02 (work in progress), draft-sullivan-cfrg-voprf-03 (work in progress), March
October 2018. 2019.
[OPAQUE] Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An [I-D.sullivan-tls-opaque]
Asymmetric PAKE Protocol Secure Against Pre-Computation Sullivan, N., Krawczyk, H., Friel, O., and R. Barnes,
Attacks", Eurocrypt , 2018. "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, [JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu,
"Highly-efficient and composable password-protected secret "Highly-efficient and composable password-protected secret
sharing (or: how to protect your bitcoin wallet online)", sharing (or: how to protect your bitcoin wallet online)",
IEEE European Symposium on Security and Privacy , 2016. IEEE European Symposium on Security and Privacy , 2016.
[SIGMA] Krawczyk, H., "SIGMA: The SIGn-and-MAc approach to [OPAQUE] Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An
authenticated Diffie-Hellman and its use in the IKE Asymmetric PAKE Protocol Secure Against Pre-Computation
protocols", CRYPTO , 2003. Attacks", Eurocrypt , 2018.
[HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie-
Hellman protocol", CRYPTO , 2005.
[VTBPEKE] Pointcheval, D. and G. Wang, "Verifier-based Two-Basis
Password Exponential Key Exchange", AsiaCCS , 2017.
[SIGNAL] "Signal recommended cryptographic algorithms",
https://signal.org/docs/specifications/
doubleratchet/#recommended-cryptographic-algorithms ,
2016.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, DOI 10.17487/
RFC2898, September 2000, <https://www.rfc-editor.org/info/
rfc2898>.
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",
RFC 2945, DOI 10.17487/RFC2945, September 2000, RFC 2945, DOI 10.17487/RFC2945, September 2000,
<https://www.rfc-editor.org/info/rfc2945>. <https://www.rfc-editor.org/info/rfc2945>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ Key Derivation Function (HKDF)", RFC 5869,
RFC5869, May 2010, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC5869, May 2010,
rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC6628] Shin, S. and K. Kobara, "Efficient Augmented Password-Only [RFC6628] Shin, S. and K. Kobara, "Efficient Augmented Password-Only
Authentication and Key Exchange for IKEv2", RFC 6628, DOI Authentication and Key Exchange for IKEv2", RFC 6628,
10.17487/RFC6628, June 2012, <https://www.rfc- DOI 10.17487/RFC6628, June 2012,
editor.org/info/rfc6628>. <https://www.rfc-editor.org/info/rfc6628>.
[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
August 2016, <https://www.rfc-editor.org/info/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 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <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.
[VTBPEKE] Pointcheval, D. and G. Wang, "Verifier-based Two-Basis
Password Exponential Key Exchange", AsiaCCS , 2017.
Author's Address Author's Address
Hugo Krawczyk Hugo Krawczyk
IBM Research Algorand Foundation
Email: hugo@ee.technion.ac.il Email: hugokraw@gmail.com
 End of changes. 43 change blocks. 
132 lines changed or deleted 184 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/