idnits 2.17.1 draft-krawczyk-cfrg-opaque-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 28, 2018) is 1939 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-07 == Outdated reference: A later version (-04) exists of draft-barnes-tls-pake-02 == Outdated reference: A later version (-13) exists of draft-irtf-cfrg-argon2-03 == Outdated reference: A later version (-26) exists of draft-irtf-cfrg-spake2-05 == Outdated reference: A later version (-16) exists of draft-irtf-cfrg-hash-to-curve-01 == Outdated reference: A later version (-03) exists of draft-sullivan-cfrg-voprf-02 -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Crypto Forum Research Group H. Krawczyk 3 Internet-Draft IBM Research 4 Intended status: Informational December 28, 2018 5 Expires: July 1, 2019 7 The OPAQUE Asymmetric PAKE Protocol 8 draft-krawczyk-cfrg-opaque-01 10 Abstract 12 This draft describes the OPAQUE protocol, a secure asymmetric 13 password authenticated key exchange (aPAKE) that supports mutual 14 authentication in a client-server setting without any reliance on 15 PKI. OPAQUE is the first PKI-free aPAKE to accommodate secret salt 16 and therefore it is the first to be secure against pre-computation 17 attacks upon server compromise. In contrast, prior aPAKE protocols 18 did not use salt and if they did, the salt was transmitted in the 19 clear from server to user allowing for the building of targeted 20 pre-computed dictionaries. OPAQUE security has been proven by 21 Jarecki et al. (Eurocrypt 2018) in a strong and universally 22 composable formal model of aPAKE security. In addition, the protocol 23 provides forward secrecy and the ability to hide the password from 24 the server even during password registration. 26 Strong security, good performance and an array of additional features 27 make OPAQUE a natural candidate for practical use and for adoption as 28 a standard. To this end, this draft presents several optimized 29 instantiations of OPAQUE and ways of integrating OPAQUE with TLS. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 4, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 1. Introduction 65 Password authentication is the prevalent form of authentication in 66 the web and in most other applications. In the most common 67 implementation, a user authenticates to a server by entering its user 68 id and password where both values are transmitted to the server under 69 the protection of TLS. This makes the password vulnerable to TLS 70 failures, including many forms of PKI attacks, certificate 71 mishandling, termination outside the security perimeter, visibility 72 to middle boxes, and more. Moreover, even under normal operation, 73 passwords are always visible in plaintext form at the server upon TLS 74 decryption. 76 Asymmetric (or augmented) Password Authenticated Key Exchange (aPAKE) 77 protocols are designed to provide password authentication and 78 mutually authenticated key exchange without relying on PKI (except 79 during user/password registration) and without disclosing passwords 80 to servers or other entities other than the client machine. A secure 81 aPAKE should provide the best possible security for a password 82 protocol, namely, it should only be open to inevitable attacks: 83 online impersonation attempts with guessed user passwords and offline 84 dictionary attacks upon the compromise of a server and leakage of its 85 password file. In the latter case, the attacker learns a mapping of 86 a user's password under a one-way function and uses such a mapping to 87 validate potential guesses for the password. Crucially important is 88 for the password protocol to use an unpredictable one-way mapping or 89 otherwise the attacker can pre-compute a deterministic list of mapped 90 passwords leading to almost instantaneous leakage of passwords upon 91 server compromise. 93 Quite surprisingly, in spite of the existence of multiple designs for 94 (PKI-free) aPAKE protocols, none of these protocols is secure against 95 pre-computation attacks. In particular, none of these protocols can 96 use the standard technique against pre-computation that combines 97 _secret_ random values ("salt") into the one-way password mappings. 98 Either these protocols do not use salt at all or, if they do, they 99 transmit the salt from server to user in the clear, hence losing the 100 secrecy of the salt and its defense against pre-computation. 101 Furthermore, the transmission of salt often incurs additional 102 protocol messages. 104 This draft describes OPAQUE, the first PKI-free secure aPAKE that is 105 secure against pre-computation attacks and capable of using secret 106 salt. OPAQUE has been recently defined and studied by Jarecki et al. 107 [OPAQUE] who prove the security of the protocol in a strong aPAKE 108 model that ensures security against pre-computation attacks and is 109 formulated in the Universal Composability framework [Canetti01] under 110 the random oracle model. In contrast, very few aPAKE protocols have 111 been proven formally and those proven were analyzed in a weak 112 security model that allows for pre-computation attacks (e.g., 113 [GMR06]). This is not just a formal issue: these protocols are 114 actually vulnerable to such attacks! Furthermore, as far as we know, 115 protocols discussed recently as candidates for standardization (e.g., 116 SPAKE2+ [I-D.irtf-cfrg-spake2] and AugPAKE [RFC6628]) do not enjoy a 117 proof of security, not even in a weak model. The same holds for the 118 SRP protocol [RFC2945]. VTBPEKE is analyzed in [VTBPEKE] in a weak 119 model that allows for pre-computation attacks and, as in all the 120 above cases (except OPAQUE), does not accommodate secret salt. 122 OPAQUE's design is based on the seminal work of Ford and Kaliski 123 [FK00] with variants studied by Boyen [Boyen09] and Jarecki et al. 124 [JKKX16], although none of these papers presented a proof of aPAKE 125 security (not even in a weak model). 127 In addition to its proven resistance to pre-computation attacks, 128 OPAQUE's security features include forward secrecy (essential for 129 protecting past communications in case of password leakage) and the 130 ability to hide the password from the server - even during password 131 registration. Moreover, good performance and an array of additional 132 features make OPAQUE a natural candidate for practical use and for 133 adoption as a standard. Such features include the ability to 134 increase the difficulty of offline dictionary attacks via iterated 135 hashing (or other hardening schemes) and offloading these operations 136 to the client; extensibility of the protocol to support storage and 137 retrieval of user's secrets solely based on a password; and being 138 amenable to a multi-server distributed implementation where offline 139 dictionary attacks are not possible without breaking into a threshold 140 of servers (such distributed solution requires no change or awareness 141 on the client side relative to a single-server implementation). 143 OPAQUE is defined and proven as the composition of two 144 functionalities: An Oblivious PRF (OPRF) and a key-exchange protocol. 145 It can be seen as a "compiler" for transforming any key-exchange 146 protocol (with KCI security - see below) into a secure aPAKE 147 protocol. In OPAQUE, the user stores a secret private key at the 148 server during password registration and retrieves this key each time 149 it needs to authenticate to the server. The OPRF security properties 150 ensure that only the correct password can unlock the private key 151 while at the same time avoiding potential offline guessing attacks. 152 This general composability property provides great flexibility and 153 enables a variety of OPAQUE instantiations, from optimized 154 performance to integration with TLS. The latter aspect is of prime 155 importance as the use of OPAQUE with TLS constitutes a major security 156 improvement relative to the standard password-over-TLS practice. 157 At the same time, the combination with TLS builds OPAQUE as a fully 158 functional secure communications protocol and can help provide 159 privacy to account information sent by the user to the server prior 160 to authentication. 162 The KCI property required from KE protocols for use with OPAQUE 163 states that knowledge of a party's private key does not allow an 164 attacker to impersonate others to that party. This is an important 165 security property achieved by most public-key based KE protocols, 166 including protocols that use signatures or public key encryption for 167 authentication. It is also a property of many implicitly 168 authenticated protocols (e.g., HMQV) but not all of them. We also 169 note that key exchange protocols based on shared keys do not satisfy 170 the KCI requirement, hence they are not considered in the OPAQUE 171 setting. We note that KCI is needed to ensure a crucial property of 172 OPAQUE: even upon compromise of the server, the attacker cannot 173 impersonate the user to the server without first running an 174 exhaustive dictionary attack. 176 This draft defines OPAQUE with a specific, efficient instantiation 177 over elliptic curves of the OPRF component and with a few KE schemes, 178 including the HMQV [HMQV] and SIGMA [SIGMA] protocols, as well as 179 several suggestions for integrating OPAQUE with TLS 1.3 [RFC8446] 180 offering different tradeoffs between simplicity, performance and user 181 privacy. 183 The computational cost of OPAQUE is determined by the cost of the 184 OPRF, the cost of a regular Diffie-Hellman exchange, and the cost of 185 authenticating such exchange. In our elliptic-curve implementation 186 of the OPRF, the cost for the client is two exponentiations (one or 187 two of which can be fixed base) and one hashing-into-curve operation 188 [I-D.irtf-cfrg-hash-to-curve]; for the server, it is just one 189 exponentiation. The cost of a Diffie-Hellman exchange is as usual 190 two exponentiations per party (one of which is fixed-base). Finally, 191 the cost of authentication per party depends on the specific KE 192 protocol: it is just 1/6 of an exponentiation with HMQV and it is one 193 signature in the case of SIGMA and TLS 1.3. These instantiations 194 preserve the number of messages (two or three) in the underlying KE 195 protocol except in one of the TLS instantiations where user privacy 196 requires an additional round trip. 198 1.1. Terminology 200 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 201 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 202 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 203 [RFC2119] 205 1.2. Notation 207 Throughout this document the first argument to a keyed function 208 represents the key; separated by a semicolon are the function inputs 209 typically implemented as an unambiguous concatenation of strings 210 (details of encodings are left for a future, more detailed 211 specification). 213 Except if said otherwise, random choices in this specification refer 214 to drawing with uniform distribution from a given set (i.e., "random" 215 is short for "uniformly random"). 217 The name OPAQUE: A homonym of O-PAKE where O is for Oblivious (the 218 name OPAKE was taken). 220 2. DH-OPRF 222 A fundamental piece in the definition of OPAQUE is an Oblivious 223 Pseudo Random Function (OPRF). 225 An Oblivious PRF (OPRF) is an interactive protocol between a server S 226 and a user U defined by a special pseudorandom function (PRF), 227 denoted F. The server's input to the protocol is a key k for PRF F 228 and the user's input is a value x in the domain of F. At the end of 229 the protocol, U learns F(k;x) and nothing else while S learns nothing 230 from the protocol execution (in particular nothing about x or the 231 value F(k;x)). 233 OPAQUE uses a specific OPRF instantiation, called DH-OPRF, where the 234 PRF, denoted F, is defined as follows. 236 [Author note: It would be good to align this OPRF specification with 237 [I-D.sullivan-cfrg-voprf] and its defined instantiation suites, but 238 it will require extending that specification to accommodate non- 239 verifiable OPRFs.] 241 Parameters: Hash function H (e.g., a SHA2 or SHA3 function), a cyclic 242 group G of prime order q, a generator g of G, and hash function H' 243 mapping arbitrary strings into G (where H' is modeled as a random 244 oracle). 246 o DH-OPRF domain: Any string 248 o DH-OPRF range: The range of the hash function H 250 o DH-OPRF key: A random element k in [0..q-1]; denote v=g^k 252 o DH-OPRF Operation: F(k; x) = H(x, v, H'(x)^k) 254 Protocol for computing DH-OPRF, U with input x and S with input k: 256 o U: choose random r in [0..q-1], send alpha=H'(x)*g^r to S 258 o S: upon receiving a value alpha, respond with v=g^k and 259 beta=alpha^k 261 o U: upon receiving values beta and v, set the PRF output to 262 H(x, v, beta*v^{-r}) 264 All received values (alpha, beta, v) are checked to be elements in G 265 other than the identity. A party aborts if the check fails. In the 266 case of Elliptic Curves this test is typically inexpensive - see 267 [I-D.irtf-cfrg-spake2] for ways to deal with this check (including 268 co-factor exponentiation) that apply to DH-OPRF as well. 270 Note (exponential blinding): An alternative way of computing DH-OPRF 271 is for U to send alpha=(H'(x))^r in the first message and set the 272 function output to H(x,v,beta^{1/r}) upon receiving S's response. 273 However, note that the multiplicative blinding above allows for a 274 more efficient implementation as the g^r exponentiation uses a fixed 275 base. Moreover, in cases where the user caches v (e.g., for sites it 276 visits often) then one can also use a fixed-base optimized 277 computation of the exponentiation v^{-r}. In any case, it is up to 278 the user to decide on what form of blinding it uses; the server's 279 response is the same in both cases. 281 Note: For elliptic curve implementations of DH-OPRF, the hashing into 282 the curve operation has been studied extensively with known efficient 283 implementations, see [I-D.irtf-cfrg-hash-to-curve] and references 284 therein. 286 2.1. Hardening OPRF via user iterations 288 Protocol OPAQUE can be further strengthened against offline 289 dictionary attacks by applying to the output of DH-OPRF an iterated 290 hash for some number n of iterations. This increases the cost of an 291 offline attack upon the compromise of the server as the attacker will 292 need to perform n iterations for each guess of PwdU it tries to 293 validate. For this purpose we would re-define DH-OPRF as 294 F(k;x) = I^n( H(x, v, H'(x)^k) ) where I is an appropriately chosen 295 function and the symbol I^n denotes n iterations of function I. More 296 generally, any form of hardened password-based key derivation can be 297 used, e.g., PBKDF2 [RFC2898], Argon 2 [I-D.irtf-cfrg-argon2], scrypt 298 [RFC7914]. As we will see, in OPAQUE it is the user who runs this 299 key derivation. The iteration value n or any other parameter 300 required by these functions can be set as public constants or can be 301 set at time of password registration and later communicated by the 302 server as part of its OPAQUE message. (Note; these hardened KDFs 303 often require a salt value as input; for OPAQUE this value can be be 304 set to a constant, e.g., all zeros.) 306 3. OPAQUE Specification 308 OPAQUE consists of the concurrent run of an OPRF protocol and a key- 309 exchange protocol KE (one that provides mutual authentication based 310 on public keys and satisfies the KCI requirement). We first define 311 OPAQUE in a generic way based on any OPRF and any PK-based KE, and 312 later show specific instantiation using DH-OPRF (defined in 313 Section 2) and several KE protocols. The user takes the role of 314 initiator in these protocols and the server the responder's. The 315 private-public keys for the user are denoted PrivU and PubU, and for 316 the server PrivS and PubS. In Section 3.4 we augment the protocol 317 with user-side hardening to increase resistance to offline attacks in 318 case of server compromise. 320 3.1. Password registration 322 Password registration is run between a user U and a server S. It is 323 assumed that the user can authenticate the server during this 324 registration phase (this is the only part in OPAQUE that requires 325 some form of authenticated channel, either physical, out-of-band, 326 PKI-based, etc.) 328 o U chooses password PwdU and a pair of private-public keys PrivU 329 and PubU for the given protocol KE. 331 o S chooses OPRF key kU (random and independent for each user U) and 332 sets vU = g^kU; it also chooses its own pair of private-public 333 keys PrivS and PubS for use with protocol KE (the server can use 334 the same pair of keys with multiple users), and sends PubS to U. 336 o U and S run OPRF(kU;PwdU) as defined in Section 2 with only U 337 learning the result, denoted RwdU (mnemonics for "Randomized 338 PwdU"). 340 o U generates an "envelope" EnvU defined as 342 EnvU = AuthEnc(RwdU; PrivU, PubU, PubS) 344 where AuthEnc is an authenticated encryption function with the 345 "key committing" property and is specified in Section 3.1.1 below. 346 In EnvU, all values require authentication and PrivU also requires 347 encryption. PubU can be omitted from EnvU if it can be 348 reconstructed from PrivU but while it will save bits on the wire 349 it will come at some computational cost during client 350 authentication. 352 o U sends EnvU and PubU to S and erases PwdU, RwdU and all keys. 353 S stores (EnvU, PubS, PrivS, PubU, kU, vU) in a user-specific 354 record. If PrivS and PubS are used for multiple users, S can 355 store these values separately and omit them from the user's 356 record. 358 Note (salt). We note that in OPAQUE the OPRF key acts as the secret 359 salt value that ensures the infeasibility of pre-computation attacks. 360 No extra salt value is needed. 362 Note (password rules). The above procedure has the significant 363 advantage that the user's password is not disclosed to the server 364 even during registration. Some sites require learning the user's 365 password for enforcing password rules. Doing so voids this important 366 security property of OPAQUE and is not recommended. Moving the 367 password check procedure to the client side is a more secure 368 alternative. 370 3.1.1. Implementing the EnvU envelop 372 The function AuthEnc used to compute EnvU needs to satisfy a property 373 called "key committing". That is, given a pair of random AuthEnc 374 keys, it should be infeasible to create an authenticated ciphertext 375 that successfully decrypts under the two keys. This restricts 376 significantly the AuthEnc methods for use, particularly disallowing 377 GCM. We thus specify the AuthEnc function to be implemented via 378 "encrypt-then-hmac" which provably meets this requirement. That is, 379 EnvU will consist of an encryption of the values PrivU, PubU, PubS 380 (concatenated using an unambiguous encoding), with HMAC computed on 381 the resultant ciphertext. Any secure encryption can be used but the 382 MAC needs to be collision resistant which HMAC satisfies (with a tag 383 size of at least 256 bits). Note that this requires two separate 384 keys for the encryption and MAC parts which can be derived from a 385 single key using, for example, the HKDF-Expand function from 386 [RFC5869]. We note that while encryption of PubU and PubS is not 387 strictly required, only authentication, we have included these values 388 under the encryption for the sake of simplicity. Furthermore, 389 encrypting PubU and PubS helps defending against "user enumeration" 390 as discussed in Section 5. 392 [Author note: Is there a standardized definition of Encrypt-then-HMAC 393 that one can refer? Here is a description from signal [SIGNAL].] 395 3.2. Online OPAQUE protocol 397 After registration, the user and server can run the OPAQUE protocol 398 as a password-authenticated key exchange. The protocol proceeds as 399 follows: 401 o User transmits user/account information to the server so that the 402 server can retrieve the user's record. 404 o Server sends EnvU and vU to user. 406 o Server and User execute the OPRF protocol as defined in Section 2; 407 User sets RwdU to the result of this computation. 409 o User decrypts EnvU using RwdU to obtain PrivU, PubU, PubS. 411 o User and server run the specified KE protocol using their 412 respective public and private keys. 414 Note that the steps preceding the run of KE can be arranged in just 415 two messages (one from the user and a response from the server). 416 Furthermore, OPAQUE is optimized by running the OPRF and KE 417 concurrently with interleaved and combined messages (while preserving 418 the internal ordering of messages in each protocol). In all cases, 419 the user needs to obtain EnvU, vU and RwdU (i.e., complete the OPRF 420 protocol) before it can use its own private key PrivU and the 421 server's public key PubS in the run of KE. 423 3.3. OPAQUE Instantiations 425 We present several instantiations of OPAQUE using DH-OPRF as the OPRF 426 and different KE protocols. For the sake of concreteness and 427 performance we focus on KE protocols consisting of two or three 428 messages, denoted K1, K2, K3 (in 2-message protocols K3 is omitted) 429 and such that K1 and K2 include DH values sent by user and server, 430 respectively. These DH values will ensure forward secrecy. 432 Generic OPAQUE with 3-message KE: 434 o C to S: Uid, alpha=H'(PwdU)*g^r, KE1 436 o S to C: beta=alpha^kU, vU, EnvU, KE2 438 o C to S: KE3 440 Key derivation and other details of the protocol are fully specified 441 by the KE scheme. 443 We provide two instantiations of OPAQUE (with HMQV and SIGMA-I) next 444 and discuss integration with TLS in [RFC8446]. 446 3.3.1. Instantiation with HMQV 448 The integration of OPAQUE with HMQV [HMQV] leads to the most 449 efficient instantiation of OPAQUE. It results in a full aAPKE 450 protocol with implicit authentication in just two messages (this 451 includes the DH-OPRF messages) and with explicit mutual 452 authentication in three. Performance is close to optimal due to the 453 negligible cost of authentication in HMQV: Just 1/6 of an 454 exponentiation for each party over the cost of a regular DH exchange. 455 The private and public keys of the parties are Diffie-Hellman keys, 456 namely, PubU=g^PrivU and PubS=g^PrivS. The HMQV exchange can be 457 represented schematically as follows: 459 o KE1 = g^x 461 o KE2 = g^y, Mac(Km1; g^x, g^y) 463 o KE3 = Mac(Km2; g^y, g^x) 465 The third message can be removed (as well as the server's Mac) if one 466 is to provide implicit authentication only (e.g., if explicit 467 authentication is achieved by the subsequent protocol or 468 application). 470 Keys in HMQV, namely, MAC keys Km1, Km2 and session/traffic keys are 471 derived from a common key K computed as follows: 473 C computes K = H((g^y * PubS^e)^{x + d*PrivU)) 475 S computes K = H((g^x * PubU^d)^{y + e*PrivS)) 476 where d = H(g^x, IdS) and e = H(g^y, IdU), and IdU, IdS represent the 477 identities of user and server (typically, a user id and domain name, 478 respectively, and can include the party's public key value). The 479 function H can be the same as used for the DH-OPRF computation. 480 Using multi-exponentiation optimization, the computation of K 481 involves a single multi-exponentiation whose cost is only 17% more 482 than a regular exponentiation. 484 This is a minimal skeleton. A fully-specified protocol will include 485 additional details and a careful key derivation scheme. In 486 particular, the Mac computation will cover the whole preceding 487 transcript. In addition, the parties will check group membership for 488 g^x, g^y or use co-factor computation, e.g., as in 489 [I-D.irtf-cfrg-spake2]; in any case the value is rejected if it 490 equals the identity. The check for PubU and PubS can be done only 491 once at user registration. 493 Note (HMQV patent): IBM has a patent that covers HMQV. While the 494 author does not speak in the name of IBM or with any legal authority, 495 he has reason to believe that if there will be a serious interest in 496 standardizing OPAQUE with HMQV, the patent may not be an impediment. 498 3.3.2. Instantiation with SIGMA-I 500 We show how OPAQUE can be built around the 3-message SIGMA-I protocol 501 [SIGMA]. This example is significant as it shows integration with a 502 signature-based KE protocol and because TLS 1.3 follows the design of 503 SIGMA-I hence the example helps understanding the proposed 504 integration of OPAQUE with TLS in [RFC8446]. 506 SIGMA-I can be represented schematically as follows: 508 o KE1 = g^x 510 o KE2 = g^y, Sig(PrivS; g^x, g^y), Mac(Km1; IdS) 512 o KE3 = Sig(PrivU; g^y, g^x), Mac(Km2; IdU) 514 In this case, the private keys of both users and servers are 515 signature keys. Key derivation is based on the DH value g^xy. 516 K3 cannot be omitted. 518 As before, this is only a skeleton to illustrate the protocol. 519 Full details need to be filled in for a self-contained specification. 521 3.4. Hardening OPAQUE via hardened key derivation 523 As noted in Section 2.1 one can increase the resistance of OPAQUE to 524 offline attacks in case of server compromise by applying a password- 525 hardening key derivation function (KDF) on top of the regular DH-OPRF 526 when computing RwdU. Specifically, the user computes the OPRF in 527 interaction with the server and inputs its result into the KDF in 528 lieu of the password on which this function acts. The output of this 529 computation is set as the value RwdU. Parameters to the KDF function 530 can be set to public values or set at the time of password 531 registration and stored at the server. In this case, the server 532 communicates these parameters to the user during OPAQUE executions 533 together with the second OPRF message. We note that the salt value 534 typically input into the KDF can be set to a constant, e.g., all 535 zeros. 537 4. Integrating OPAQUE with TLS 1.3 539 Note: This section is intended as a basis for discussion on ways to 540 integrate OPAQUE with TLS (particularly TLS 1.3). Precise protocol 541 details are left for a future specification. 543 As stated in the introduction, the standard password-over-TLS 544 mechanism for password authentication suffers from significant 545 weaknesses due to the essential reliance of the protocol on PKI and 546 the exposure of passwords to the server (and other observers) upon 547 TLS decryption. Here we propose integrating OPAQUE with TLS in order 548 to remove these vulnerabilities while at the same time armoring TLS 549 itself against PKI failures. Such integration also benefits OPAQUE 550 by leveraging the standardized negotiation and record-layer security 551 of TLS. Furthermore, TLS can offer an initial PKI-authenticated 552 channel to protect the privacy of account information such as user 553 name transmitted between client and server. 555 If one is willing to forgo protection of user account information 556 transmitted between user and server, integrating OPAQUE with TLS 1.3 557 is relatively straightforward and follows essentially the same 558 approach as with SIGMA-I in Section 3.3.2. Specifically, one reuses 559 the Diffie-Hellman exchange from TLS and uses the user's private key 560 PrivU retrieved from the server as a signature key for TLS client 561 authentication. The integrated protocol will have as its first 562 message the TLS's Client Hello augmented with user account 563 information and with the DH-OPRF first message (the value alpha). 564 The server's response includes the regular TLS 1.3 second flight 565 augmented with the second OPRF message which includes the values 566 beta, vU and EnvU. For its TLS signature, the server uses the 567 private key PrivS whose corresponding public key PubS is 568 authenticated as part of the user envelope EnvU (there is no need to 569 send a regular TLS certificate in this case). Finally, the third 570 flight consists of the standard client Finish message with client 571 authentication where the client's signature is produced with the 572 user's private key PrivU retrieved from EnvU and verified by the 573 server using public key PubU. 575 The above scheme is depicted in Figure 1 where the sign + indicates 576 fields added by OPAQUE, and DH-OPRF1, DH-OPRF2 denote the two DH-OPRF 577 messages. Other messages in the figure are the same as in TLS 1.3. 578 Notation {...} indicates encryption under handshake keys. Note that 579 ServerSignature and ClientSignature are performed with the private 580 keys defined by OPAQUE and they replace signatures by traditional TLS 581 certificates. 583 Client Server 585 ClientHello 586 key_share 587 + userid + DH-OPRF1 --------> 588 ServerHello 589 key_share 590 {+ DH-OPRF2 + vU + EnvU} 591 {+ ServerSignature} 592 <-------- {ServerFinished} 594 {+ ClientSignature} 595 {ClientFinished} --------> 597 Figure 1: Integration of OPAQUE in TLS 1.3 (no userid 598 confidentiality) 600 Note that in order to send DH-OPRF1 in the first message, the client 601 needs to know the DH group the server uses for OPRF, or it needs to 602 "guess" it. This issue already appears in TLS 1.3 where the client 603 needs to guess the key_share group and it should be handled similarly 604 in OPAQUE (e.g., the client may try one or more groups in its first 605 message). 607 Protection of user's account information can be added through TLS 1.3 608 pre-shared/resumption mechanisms where the account information 609 appended to the ClientHello message would be encrypted under the pre- 610 shared key. 612 When a resumable session or pre-shared key between the client and the 613 server do not exist, user account protection requires a server 614 certificate. In this case, the TLS 1.3 handshake is augmented with 615 the two OPAQUE messages interleaved between the second and third 616 flight of the regular TLS handshake. That is, the protocol consists 617 of five flights as follows: (i) A regular 2-flight 1-RTT handshake to 618 produce handshake traffic keys authenticated by the server's TLS 619 certificate; (ii) two messages that include user identification 620 information, the DH-OPRF messages exchanged between client and 621 server, and the retrieved vU and EnvU, all encrypted under the 622 handshake traffic keys (thus providing privacy to user account 623 information); (iii) the TLS 1.3 client authentication flight where 624 client authentication uses the user's private signature key PrivU 625 retrieved from the server in step (ii). 627 Note that server authentication in (i) uses TLS certificates hence 628 user account privacy (but not user authentication) is dependent on 629 PKI. In cases where PKI authentication for the server is deemed 630 acceptable then there is no need for further server authentication. 631 However, if one wants to enforce server authentication without 632 reliance on PKI, then the server needs to authenticate using the 633 private key PrivS whose corresponding public key PubS is sent to the 634 user as part of EnvU. There are two options: If PubS is the same as 635 the public key the server used in the 1-RTT authentication (step (i)) 636 then there is no need for further authentication. In this case, U 637 gets assurance from the authenticated EnvU, not (only) from the PKI 638 certificates. Otherwise, the server needs to send a signature under 639 PrivS that is piggybacked to the second OPAQUE message in (ii). In 640 this case the signature would cover the running transcript hash as is 641 standard in TLS 1.3. The client signature in the last message also 642 covers the transcript hash including the regular handshake and OPAQUE 643 messages. 645 The above scheme is depicted in Figure 2. Please refer to the text 646 before Figure 1 describing notation. Note the asterisk in the 647 ServerSignature message. This indicates that this message is 648 optional as it is used only if the server's key PubS in OPAQUE is 649 different than the one in the server's certificate (transmitted in 650 the second protocol flight). 652 Client Server 654 ClientHello 655 key_share --------> 656 ServerHello 657 key_share 658 {Certificate} 659 {CertificateVerify} 660 <-------- {ServerFinished} 662 {+ userid + DH-OPRF1} --------> 664 {+ DH-OPRF2 + EnvU} 665 {+ DH-OPRF2 + vU + EnvU} 666 <-------- {+ ServerSignature*} 668 {ClientSignature} 669 {ClientFinished} --------> 671 Figure 2: Integration of OPAQUE in TLS 1.3 (with userid 672 confidentiality) 674 We note that the above approaches for integration of OPAQUE with TLS 675 may benefit from the post-handshake client authentication mechanism 676 of TLS 1.3 and the exported authenticators from 677 [I-D.ietf-tls-exported-authenticator]. Also, formatting of messages 678 and negotiation information suggested in [I-D.barnes-tls-pake] can be 679 used in the OPAQUE setting. 681 5. User enumeration 683 User enumeration refers to attacks where the attacker tries to learn 684 whether a given user identity is registered with a server. 685 Preventing such attack requires the server to act with unknown user 686 identities in a way that is indistinguishable from its behavior with 687 existing users. Here we suggest a way to implement such defense, 688 namely, a way for simulating the values beta, vU and EnvU for non- 689 existing users. Note that if the same pair of user identity UId and 690 value alpha is received twice by the server, the response needs to be 691 the same in both cases (since this would be the case for real users). 692 For this, the server S will have two keys MK, MK' for a PRF f (this 693 refers to a regular PRF such as HMAC or CMAC). Upon receiving a pair 694 of user identity UId and value alpha for a non-existing user UId, S 695 computes kU=f(MK; UId) and kU'=f(MK'; UId) and responds with three 696 values beta=alpha^kU, vU=g^kU and EnvU where the latter is computed 697 as the AuthEnc function with key kU' applied to the all-zero string 698 (of the length of a regular EnvU plaintext). Care needs to be taken 699 to avoid side channel leakage (e.g., timing) from helping 700 differentiate these operations from a regular server response. The 701 above requires changes to the server-side implementation but not to 702 the protocol itself or the client side. 704 There is one form of leakage that the above allows and whose 705 prevention would require a change in OPAQUE. Note that an attacker 706 that tests a UId (and same alpha) twice and receives different 707 responses can conclude that either the user registered with the 708 service between these two activations or that the user was registered 709 before but changed its password in between the activations (assuming 710 the server changes kU at the time of a password change). In any 711 case, this indicates that UId is a registered user at the time of the 712 second activation. To conceal this information, S can implement the 713 derivation of kU as kU=f(MK; UId) also for registered users. Hiding 714 changes in EnvU, however, requires a change in the protocol. Instead 715 of sending EnvU as is, we specify that S sends an encryption of EnvU 716 under a key that the user derives from the OPRF result (similarly to 717 RwdU) and that S stores during password registration. During login, 718 the user will derive this key from the OPRF result, use it to decrypt 719 EnvU, and continue with the regular protocol. If S uses a randomized 720 encryption, the encrypted EnvU will look each time as a fresh random 721 string, hence S can simulate the encrypted EnvU also for non-existing 722 users. 724 [Author note: How significant is the user enumeration issue? The 725 first case above does not change the protocol so its implementation 726 is a server's decision. The second case, however, requires a change 727 in OPAQUE so it would be important to have feedback on whether this 728 second order attack justifies such change.] 730 6. Security considerations 732 This is an early draft presenting the OPAQUE concept and its 733 potential instantiations. More precise details and security 734 considerations will be provided in future drafts. We note that the 735 security of OPAQUE is formally proved in [OPAQUE] under a strong 736 model of aPAKE security assuming the security of the OPRF function 737 and of the underlying key-exchange protocol. In turn, the security 738 of DH-OPRF is proven in the random oracle model under the One-More 739 Diffie-Hellman assumption [JKKX16]. 741 While one can expect the practical security of the OPRF function 742 (namely, the hardness of computing the function without knowing the 743 key) to be in the order of computing discrete logarithms or solving 744 Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an 745 attack that slightly improves on generic attacks. For the case that 746 q-1 or q+1, where q is the order of the group G, has a t-bit divisor, 747 they show an attack that calls the OPRF on 2^t chosen inputs and 748 reduces security by t/2 bits, i.e., it can find the OPRF key in time 749 2^{q/2-t/2} and 2^{q/2-t/2} memory. For typical curves, the attack 750 requires an infeasible number of calls and/or results in 751 insignificant security loss [*]. Moreover, in the OPAQUE 752 application, these attacks are completely impractical as the number 753 of calls to the function translates to an equal number of failed 754 authentication attempts by a _single_ user. For example, one would 755 need a billion impersonation attempts to reduce security by 15 bits 756 and a trillion to reduce it by 20 bits - and most curves will not 757 even allow for such attacks in the first place (note that this 758 theoretical loss of security is with respect to computing discrete 759 logarithms, not in reducing the password strength). 761 [*] Some examples (courtesy of Dan Brown): For P-384, 2^90 calls 762 reduce security from 192 to 147 bits; for NIST P-256 the options are 763 6-bit reduction with 2153 OPRF calls, about 14 bit reduction with 187 764 million calls and 20 bits with a trillion calls. For Curve25519, 765 attacks are completely infeasible (require over 2^100 calls) but its 766 twist form allows an attack with 25759 calls that reduces security by 767 7 bits and one with 117223 calls that reduces security by 8.4 bits. 769 Note on user authentication vs. authenticated key exchange. OPAQUE 770 provides PAKE (password-based authenticated key exchange) 771 functionality in the client-server setting. While in the case of 772 user identification, focus is often on the authentication part, we 773 stress that the key exchange element is not less crucial. Indeed, in 774 most cases user authentication is performed to enforce some policy, 775 and the key exchange part is essential for binding this enforcement 776 to the authentication step. Skipping the key exchange part is 777 analogous to carefully checking visitor credentials at the door but 778 then leaving the door open after a first visitor is allowed to enter. 780 7. Acknowledgments 782 The OPAQUE protocol is the product of joint work of the author with 783 Stas Jarecki and Jiayu Xu, and builds on a line of work initiated in 784 the seminal paper by Ford and Kaliski [FK00]. This draft has 785 benefited from comments by multiple people. Special thanks to Dan 786 Brown, Eric Crockett, Fredrik Kuivinen, Jason Resch, Nick Sullivan. 788 8. References 790 8.1. Normative References 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, March 1997. 795 8.2. Informative References 797 [Boyen09] Boyen, X., "HPAKE: Password authentication secure against 798 cross-site user impersonation", Cryptology and Network 799 Security (CANS) , 2009. 801 [BG04] Brown, D. and R. Galant, "The static Diffie-Hellman 802 problem", http://eprint.iacr.org/2004/306 , 2004. 804 [Canetti01] 805 Canetti, R., "Universally composable security: A new 806 paradigm for cryptographic protocols", IEEE Symposium on 807 Foundations of Computer Science (FOCS) , 2001. 809 [Cheon06] Cheon, J., "Security analysis of the strong Diffie-Hellman 810 problem", Euroctypt 2006 , 2006. 812 [FK00] Ford, W. and B. Kaliski, Jr, "Server-assisted generation 813 of a strong secret from a password", WETICE , 2000. 815 [GMR06] Gentry, C., MacKenzie, P., and . Z, Ramzan, "A method for 816 making password-based key exchange resilient to server 817 compromise", CRYPTO , 2006. 819 [I-D.ietf-tls-exported-authenticator] 820 Sullivan, N., "Exported Authenticators in TLS", draft- 821 ietf-tls-exported-authenticator-07 (work in progress), 822 June 2018. 824 [I-D.barnes-tls-pake] 825 Barnes, R. and O. Friel, "Usage of SPAKE with TLS 1.3", 826 draft-barnes-tls-pake-02 (work in progress), June 2018. 828 [I-D.irtf-cfrg-argon2] 829 Biryukov, A., Dinu, D., Khovratovich, D., and S. 830 Josefsson, "The memory-hard Argon2 password hash and 831 proof-of-work function", draft-irtf-cfrg-argon2-03 (work 832 in progress), August 2017. 834 [I-D.irtf-cfrg-spake2] 835 Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", draft-irtf-cfrg- 836 spake2-05 (work in progress), February 2018. 838 [I-D.irtf-cfrg-hash-to-curve] 839 Scott, S., Sullivan, N., and C. Wood, "Hashing to Elliptic 840 Curves", draft-irtf-cfrg-hash-to-curve-01 (work in 841 progress), July 2018. 843 [I-D.sullivan-cfrg-voprf] 844 Davidson, A., Sullivan, N., and C. Wood, "Verifiable 845 Oblivious Pseudorandom Functions (VOPRFs) in Prime-Order 846 Groups", draft-sullivan-cfrg-voprf-02 (work in progress), 847 October 2018. 849 [OPAQUE] Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An 850 Asymmetric PAKE Protocol Secure Against Pre-Computation 851 Attacks", Eurocrypt , 2018. 853 [JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu, 854 "Highly-efficient and composable password-protected secret 855 sharing (or: how to protect your bitcoin wallet online)", 856 IEEE European Symposium on Security and Privacy , 2016. 858 [SIGMA] Krawczyk, H., "SIGMA: The SIGn-and-MAc approach to 859 authenticated Diffie-Hellman and its use in the IKE 860 protocols", CRYPTO , 2003. 862 [HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie- 863 Hellman protocol", CRYPTO , 2005. 865 [VTBPEKE] Pointcheval, D. and G. Wang, "Verifier-based Two-Basis 866 Password Exponential Key Exchange", AsiaCCS , 2017. 868 [SIGNAL] "Signal recommended cryptographic algorithms", 869 https://signal.org/docs/specifications/ 870 doubleratchet/#recommended-cryptographic-algorithms , 871 2016. 873 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 874 Specification Version 2.0", RFC 2898, DOI 10.17487/ 875 RFC2898, September 2000, . 878 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 879 RFC 2945, DOI 10.17487/RFC2945, September 2000, 880 . 882 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 883 Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ 884 RFC5869, May 2010, . 887 [RFC6628] Shin, S. and K. Kobara, "Efficient Augmented Password-Only 888 Authentication and Key Exchange for IKEv2", RFC 6628, DOI 889 10.17487/RFC6628, June 2012, . 892 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 893 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 894 August 2016, . 896 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 897 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 898 . 900 Author's Address 902 Hugo Krawczyk 903 IBM Research 905 Email: hugo@ee.technion.ac.il