idnits 2.17.1 draft-krawczyk-cfrg-opaque-00.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.) ** There are 10 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 01, 2018) is 2005 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 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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 October 01, 2018 5 Expires: April 4, 2019 7 The OPAQUE Asymmetric PAKE Protocol 8 draft-krawczyk-cfrg-opaque-00 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 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 pre- 20 computed dictionaries. OPAQUE security has been proven by Jarecki et 21 al. (Eurocrypt 2018) in a strong and universally composable formal 22 model of aPAKE security. In addition, the protocol provides forward 23 secrecy and the ability to hide the password from the server even 24 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 April 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 86 of a user's password under a one-way function and uses such a mapping 87 to validate potential guesses for the password. Crucially important 88 is for the password protocol to use an unpredictable one-way mapping 89 or otherwise the attacker can pre-compute a deterministic list of 90 mapped passwords leading to almost instantaneous leakage of passwords 91 upon 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 in 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 none of the protocols discussed recently as candidates for 116 standardization (e.g., SPAKE2+ [I-D.irtf-cfrg-spake2] and AugPAKE 117 [RFC6628]) enjoys a proof of security, not even in a weak model. The 118 same holds for the SRP protocol [RFC2945] and none of these protocols 119 accommodates secret salt. 121 OPAQUE's design is based on the seminal work of Ford and Kaliski 122 [FK00] with variants studied by Boyen [Boyen09] and Jarecki et al. 123 [JKKX16], although none of these papers presented a proof of aPAKE 124 security (not even in a weak model). 126 In addition to its proven security against pre-computation attacks, 127 OPAQUE's security features include forward secrecy (essential for 128 protecting past communications in case of password leakage) and the 129 ability to hide the password from the server even during password 130 registration. Moreover, good performance and an array of additional 131 features make OPAQUE a natural candidate for practical use and for 132 adoption as a standard. Such features include the ability to 133 increase the difficulty of offline dictionary attacks via iterated 134 hashing and offloading these iterations to the client, extensibility 135 of the protocol to support storage and retrieval of user's secrets 136 solely based on a password, and being amenable to a multi-server 137 distributed implementation where offline dictionary attacks are not 138 possible without breaking into a threshold of servers (such 139 distributed solution requires no change or awareness on the client 140 side relative to a single-server implementation). 142 OPAQUE is defined and proven as the composition of two 143 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. At 157 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. 173 This draft defines OPAQUE with a specific, efficient instantiation 174 over elliptic curves of the OPRF component and with a few KE schemes, 175 including the HMQV [HMQV] and SIGMA [SIGMA] protocols, as well as 176 several suggestions for integrating OPAQUE with TLS 1.3 177 [I-D.ietf-tls-tls13] offering different tradeoffs between simplicity, 178 performance and user privacy. 180 The computational cost of OPAQUE is determined by the cost of the 181 OPRF, the cost of a regular Diffie-Hellman exchange, and the cost of 182 authenticating such exchange. In our elliptic-curve implementation 183 of the OPRF, the cost for the client is two exponentiations (one or 184 two of which can be fixed base) and one hashing-into-curve operation 185 [I-D.irtf-cfrg-hash-to-curve]; for the server, it is just one 186 exponentiation. The cost of a Diffie-Hellman exchange is as usual 187 two exponentiations per party (one of which is fixed-base). Finally, 188 the cost of authentication per party depends on the specific KE 189 protocol: it is just 1/6 of an exponentiation with HMQV and it is one 190 signature in the case of SIGMA and TLS 1.3. These instantiations 191 preserve the number of messages (two or three) in the underlying KE 192 protocol except in one of the TLS instantiations where user privacy 193 requires an additional round trip. 195 1.1. Terminology 197 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 198 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 199 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 200 [RFC2119] 202 1.2. Notation 204 Throughout this document the first argument to a keyed function 205 represents the key; separated by a semicolon are the function inputs 206 typically implemented as a unambiguous concatenation of strings. 208 Except if said otherwise, random choices in this specification refer 209 to drawing with uniform distribution from a given set (i.e., "random" 210 is short for "uniformly random"). 212 The name OPAQUE: A homonym of O-PAKE where O is for Oblivious (the 213 name OPAKE was taken). 215 2. DH-OPRF 217 A fundamental piece in the definition of OPAQUE is an Oblivious 218 Pseudo Random Function (OPRF). 220 An Oblivious PRF (OPRF) is an interactive protocol between a server S 221 and a user U defined by a special pseudorandom function (PRF), 222 denoted F. The server's input to the protocol is a key k for PRF F 223 and the user's input is a value x in the domain of F. At the end of 224 the protocol, U learns F(k;x) and nothing else while S learns nothing 225 from the protocol execution (in particular nothing about x or the 226 value F(k;x)). 228 OPAQUE uses a specific OPRF instantiation, called DH-OPRF, where the 229 PRF, denoted F, is defined as follows. 231 Parameters: Hash function H (e.g., a SHA2 or SHA3 function), a cyclic 232 group G of prime order q (with a defined unique string representation 233 of its elements), a generator g of G, and hash function H' mapping 234 arbitrary strings into G (where H' is modeled as a random oracle). 236 o DH-OPRF domain: Any string 238 o DH-OPRF range: The range of the hash function H 239 o DH-OPRF key: A random element k in [0..q-1]; denote v=g^k 241 o DH-OPRF Operation: F(k; x) = H(x, v, H'(x)^k) 243 Protocol for computing DH-OPRF, U with input x and S with input k: 245 o U: choose random r in [0..q-1], send a=H'(x)*g^r to S 247 o S: upon receiving a value a, respond with v=g^k and b=a^k 249 o U: upon receiving values b and v, set the PRF output to 250 H(x, v, b*v^{-r}) 252 All received values (a, b, v) are checked to be non-unit elements in 253 G. A party aborts if the check fails. In the case of Elliptic 254 Curves this test is typically inexpensive - see 255 [I-D.irtf-cfrg-spake2] for ways to deal with this check (including 256 co-factor exponentiation) that apply to DH-OPRF as well. 258 Note (exponential blinding): An alternative way of computing DH-OPRF 259 is for U to send a=(H'(x))^r in the first message and set the 260 function output to H(x,v,b^{1/r}) upon receiving S's response. 261 However, note that the multiplicative blinding above is more 262 efficient as the g^r exponentiation uses a fixed base. Moreover, in 263 cases where the user caches v (e.g., for sites it visits often) then 264 one can also optimize the exponentiation v^{-r}. 266 Note: For elliptic curve implementations of DH-OPRF, the hashing into 267 the curve operation has been studied extensively with known efficient 268 implementations, see [I-D.irtf-cfrg-hash-to-curve]. 270 2.1. Hardening OPRF via user iterations 272 Protocol OPAQUE can be further strengthened against offline 273 dictionary attacks by applying to the output of DH-OPRF an iterated 274 hash for some number n of iterations. This increases the cost of an 275 offline attack upon the compromise of the server as the attacker will 276 need to perform n iterations for each guess of PwdU it tries to 277 validate. For this purpose we re-define DH-OPRF as 278 F(k;x) = I^n( H(x, v, H'(x)^k) ) where I is a specialized hash function 279 designed for hashing passwords such as Argon2 [I-D.irtf-cfrg-argon2] or 280 scrypt [RFC7914]. The symbol I^n denotes n iterations of function I. We 281 note that in OPAQUE, it is the user who performs these iterations. The 282 value n can be a public constant or it can be communicated by the server as 283 part of its OPAQUE message. 285 3. OPAQUE Specification 287 OPAQUE consists of the concurrent run of an OPRF protocol and a key- 288 exchange protocol KE (one that provides mutual authentication based 289 on public keys and satisfies the KCI requirement). We first define 290 OPAQUE in a generic way based on any OPRF and any PK-based KE, and 291 later show specific instantiation using DH-OPRF (defined in 292 Section 2) and several KE protocols. The user takes the role of 293 initiator in these protocols and the server the responder's. The 294 private-public keys for the user are denoted PrivU and PubU, and for 295 the server PrivS and PubS. 297 3.1. Password registration 299 Password registration is run between a user U and a server S. It is 300 assumed that the user can authenticate the server during this 301 registration phase (this is the only part in OPAQUE that requires 302 some form of authenticated channel, either physical, out-of-band, 303 cryptographic, etc.) 305 o U chooses password PwdU and a pair of private-public keys PrivU 306 and PubU for the given protocol KE. 308 o S chooses OPRF key kU (random and independent for each user U) and 309 sets vU = g^kU; it also chooses its own pair of private-public 310 keys PrivS and PubS for use with protocol KE (the server can use 311 the same pair of keys with multiple users), and sends PubS to U. 313 o U and S run OPRF(kU;PwdU) with only U learning the result, denoted 314 RwdU (mnemonics for "randomized password"). 316 o U generates an "envelope" EnvU defined as 318 EnvU = AuthEnc(RwdU; PrivU, PubU, PubS, vU) 320 where AuthEnc is an authenticated encryption function with the 321 "key committing" property (see note below). In EnvU only PrivU 322 requires encryption while all values (except vU) require 323 authentication. PubU can be omitted if it can be reconstructed 324 from PrivU (although it will be generally more efficient to 325 include it under EnvU). vU can be completely omitted from EnvU but 326 then the server will have to send it with its OPRF response in 327 addition to EnvU. 329 o U sends EnvU and PubU to S and erases PwdU, RwdU and all keys. 330 S stores (EnvU, PubS, PrivS, PubU, kU, vU) in a user-specific 331 record. If PrivS and PubS are used for different users, they can 332 be stored separately and omitted from the record. 334 Note (password rules). The above procedure has the significant 335 advantage that the user's password is not disclosed to the server 336 even during registration. Some sites require learning the user's 337 password for enforcing password rules. Doing so voids this important 338 security property of OPAQUE and is not recommended. Moving the 339 password check procedure to the client side is a more secure 340 alternative. 342 Note (key committing authenticated encryption). The function AuthEnc 343 used to compute EnvU needs to satisfy a property called "key 344 committing". That is, given a pair of random AuthEnc keys, it should 345 be infeasible to create an authenticated ciphertext that successfully 346 decrypts under the two keys. One method is to use encrypt-then-MAC 347 where the MAC is collision resistant with respect to keys, i.e., 348 given two random keys it is hard to find a message that has the same 349 authentication tag under the two keys. In particular, HMAC with an 350 output of 256 or more bits has this property. 352 Note (salt). We note that in OPAQUE the OPRF key acts as the secret 353 salt value that ensures the infeasibility of pre-computation attacks. 355 3.2. Online OPAQUE protocol 357 After registration, the user and server can run the OPAQUE protocol 358 as a password-authenticated key exchange. The protocol consists of: 360 o transmitting user/account information to the server so that the 361 server can retrieve the user's record; 363 o OPRF execution between user and server through which the user 364 obtains the value RwdU; 366 o the sending of EnvU from server to user; 368 o decryption by the user of EnvU using RwdU to obtain the user's 369 private and public key as well as the authenticated server's 370 public key; 372 o use of the public and private keys of each party to run the 373 specified KE protocol. 375 OPAQUE is optimized by running the OPRF and KE concurrently with 376 interleaved and combined messages (while preserving the internal 377 ordering of messages in each protocol). In all cases, the user needs 378 to obtain RwdU and EnvU before it can use its own private key PrivU 379 and the server's public key PubS in the run of KE. 381 3.3. OPAQUE Instantiations 383 We present several instantiations of OPAQUE using DH-OPRF as the OPRF 384 and different KE protocols. For the sake of concreteness and 385 performance we focus on KE protocols consisting of two or three 386 messages, denoted K1, K2, K3, and such that K1 and K2 include DH 387 values sent by user and server, respectively. These DH values will 388 ensure forward secrecy. 390 Generic OPAQUE with 3-message KE: 392 o C to S: Uid, a=H'(PwdU)^r, KE1 394 o S to C: b=a^k, EnvU, KE2 396 o C to S: KE3 398 Key derivation and other details of the protocol are fully 399 specified by the KE scheme. 401 We provide two instantiations of OPAQUE (with HMQV and SIGMA-I) 402 next and discuss integration with TLS in Section 4). 404 3.3.1. Instantiation with HMQV 406 The integration of OPAQUE with HMQV [HMQV] leads to the most 407 efficient instantiation of OPAQUE. It results in a full aAPKE 408 protocol with implicit authentication in just two messages (this 409 inludes the DH-OPRF messages) and with explicit mutual authentication 410 in three. Performance is close to optimal due to the negligible cost 411 of authentication in HMQV: Just 1/6 of an exponentiation for each 412 party over the cost of a regular DH exchange. The private and public 413 keys of the parties are Diffie-Hellman keys, namely, PubU=g^PrivU and 414 PubS=g^PrivS. The HMQV exchange can be represented schematically as 415 follows: 417 o KE1 = g^x 419 o KE2 = g^y, Mac(Km1; g^x, g^y) 421 o KE3 = Mac(Km2; g^y, g^x) 423 The third message can be removed (as well as the server's Mac) if 424 one is to provide implicit authentication only (e.g., if explicit 425 authentication is achieved by the subsequent protocol or 426 application). 428 Keys in HMQV, namely, MAC keys Km1, Km2 and session/traffic keys 429 are derived from a common key K computed as follows: 431 C computes K = H((g^y * PubS^e)^{x + d*PrivU)) 433 S computes K = H((g^x * PubU^d)^{y + e*PrivS)) 435 where d = H(g^x, IdS) and e = H(g^y, IdU), and Idu, IdS represent 436 the identities of user and server. The computation of K involves 437 a single multi-exponentiation whose cost is only 17% more than a 438 regular exponentiation. 440 This is a minimal skeleton. A fully-specified protocol will 441 include additional details and a careful key derivation scheme. 442 In particular, the Mac computation will cover the whole preceding 443 transcript. In addition, the parties will check group membership 444 for g^x, g^y or use co-factor computation [I-D.irtf-cfrg-spake2] 445 (the check for PubU and PubS can be done only once at user 446 registration). 448 Note (HMQV patent): IBM has a patent that covers HMQV. While the 449 author does not speak in the name of IBM or with any legal 450 authority, he has reason to believe that if there will be a 451 serious interest in standardizing OPAQUE with HMQV, the patent may 452 not be an impediment. 454 3.3.2. Instantiation with SIGMA-I 456 We show how OPAQUE can be built around the 3-message SIGMA-I protocol 457 [SIGMA]. This example is significant as it shows integration with a 458 signature-based KE protocol and because TLS 1.3 follows the design of 459 SIGMA-I hence the example helps understanding the proposed 460 integration of OPAQUE with TLS in Section 4). 462 SIGMA-I can be represented schematically as follows: 464 o KE1 = g^x 466 o KE2 = g^y, Sig(PrivS; g^x, g^y), Mac(Km1; IdS) 468 o KE3 = Sig(PrivU; g^y, g^x), Mac(Km2; IdU) 470 In this case, the private keys of both users and servers are 471 signature keys. Key derivation is based on the DH value g^xy. 473 As before, this is only a skeleton to illustrate the protocol. 474 Full details need to be filled in for a full specification. 476 3.4. Hardening OPAQUE via user iterations 478 As noted in Section 2.1 one can add further security to OPAQUE by 479 applying an iterated hash on top of the regular DH-OPRF. For this 480 one changes the computation of RwdU by the user (in the password 481 registration stage and in each online run of OPAQUE) as follows. The 482 user computes DH-OPRF on its password (namely, the value F(kU; PwdU) 483 = H(PwdU, v, (H'(PwdU))^kU)) in interaction with the server using the 484 regular procedure from Section 2. Then it computes RwdU by applying 485 n iterations of a hardening password hash function (see Section 2.1) 486 to F(kU; PwdU). The iteration count n is set at the time of password 487 registration and can be stored at the server and communicated to the 488 user during OPAQUE executions together with the second OPRF message. 490 4. Integrating OPAQUE with TLS 1.3 492 Note: This section is intended as a basis for discussion on ways to 493 integrate OPAQUE with TLS (particularly TLS 1.3). Precise protocol 494 details are left for a future specification. 496 As stated in the introduction, the typical password-over-TLS 497 mechanism for password authentication suffers from significant 498 weaknesses due to the essential reliance of the protocol on PKI and 499 the exposure of passwords to the server (and other observers) upon 500 TLS decryption. Here we propose integrating OPAQUE with TLS in order 501 to remove these vulnerabilities while at the same time armoring TLS 502 itself against PKI failures. Such integration also benefits OPAQUE 503 by leveraging the standardized negotiation and record-layer security 504 of TLS. Furthermore, TLS can offer an initial PKI-authenticated 505 channel to protect the privacy of account information such as user 506 name transmitted between client and server. 508 If one is willing to forgo protection of user account information 509 transmitted between user and server, integrating OPAQUE with TLS 510 RELATIVELY 1.3 is straightforward and follows essentially the same 511 approach as with SIGMA-I in Section 3.3.2. Specifically, one reuses 512 the Diffie-Hellman exchange from TLS and uses the user's private key 513 PrivU retrieved from the server as a signature key for TLS client 514 authentication. The integrated protocol will have as its first 515 message the TLS's Client Hello augmented with user account 516 information and the DH-OPRF first message (the value a). The 517 server's response includes the regular TLS 1.3 second flight 518 augmented with the second OPRF message which includes the values b, 519 vU and EnvU. For its TLS signature, the server uses the private key 520 PrivS whose corresponding public key PubS is authenticated as part of 521 the user envelope EnvU (there is no need to send a regular TLS 522 certificate in this case). Finally, the third flight consists of the 523 standard client Finish message with client authentication where the 524 client's signature is produced with the user's private key PrivU 525 retrieved from EnvU and verified by the server with public key PubU. 527 The above scheme is depicted in Figure 1 where the sign + indicates 528 fields added by OPAQUE; in particular, DH-OPRF1 and DH-OPRF2 denote 529 the two DH-OPRF messages. Other messages in the figure are the same 530 as in TLS 1.3. Notation {...} indicates encryption under handshake 531 keys. Note that ServerSignature and ClientSignature are performed 532 with the private keys defined by OPAQUE and they replace signatures 533 by traditional TLS certificates. 535 Client Server 537 ClientHello 538 key_share 539 + userid + DH-OPRF1 --------> 540 ServerHello 541 key_share 542 {+ DH-OPRF2 + EnvU} 543 {+ ServerSignature} 544 <-------- {ServerFinished} 546 {+ ClientSignature} 547 {ClientFinished} --------> 549 Figure 1: Integration of OPAQUE in TLS 1.3 (no userid confidentiality) 551 Adding protection of user's account information is simple using TLS 552 1.3 pre-shared/resumption mechanisms where the account information 553 appended to the first handshake message would be encrypted under the 554 pre-shared key. The rest of the protocol follows the above 555 description. 557 When a resumable session or pre-shared key between the client and the 558 server do not exist, user account protection requires a server 559 certificate. In this case, the TLS 1.3 handshake is augmented with 560 the two OPAQUE messages interleaved between the second and third 561 flight of the regular TLS handshake. That is, the protocol consists 562 of five flights as follows: (i) A regular 2-flight 1-RTT handshake to 563 produce handshake traffic keys authenticated by the server's TLS 564 certificate; (ii) two messages that include user identification 565 information, the DH-OPRF messages exchanged between client and 566 server, and the retrieved EnvU, all encrypted under the handshake 567 traffic keys (thus providing privacy to user account information); 568 (iii) the TLS 1.3 client authentication flight where client 569 authentication uses the user's private signature key PrivU retrieved 570 from the server in step (ii). 572 Note that server authentication in (i) uses TLS certificates hence 573 user privacy (but not user authentication) is dependent on PKI. In 574 cases where PKI authentication for the server is deemed acceptable 575 then there is no need for further server authentication. However, if 576 one wants to enforce server authentication without reliance on PKI, 577 then the server needs to authenticate using the private key PrivS 578 whose corresponding public key PubS is sent to the user as part of 579 EnvU. There are two options: If PubS is the same as the public key 580 the server used in the 1-RTT authentication (step (i)) then there is 581 no need for further authentication. In this case, U gets assurance 582 from the authenticated EnvU, not from the PKI certificates. 583 Otherwise, the server needs to send a signature under PrivS that is 584 piggybacked to the second OPAQUE message in (ii). In this case the 585 signature would cover the running transcript hash as is standard in 586 TLS 1.3. The client signature in the last message also covers the 587 transcript hash including the regular handshake and OPAQUE messages. 589 The above scheme is depicted in Figure 2. Please refer to the text 590 before Figure 1 describing notation. Note the asterisk in the 591 ServerSignature message. This indicates that this message is 592 optional as it is used only if the server's key PubS in OPAQUE is 593 different than the one in the server's certificate (transmitted in 594 the second protocol flight). 596 Client Server 598 ClientHello 599 key_share --------> 600 ServerHello 601 key_share 602 {Certificate} 603 {CertificateVerify} 604 <-------- {ServerFinished} 606 {+ userid + DH-OPRF1} --------> 608 {+ DH-OPRF2 + EnvU} 609 <-------- {+ ServerSignature*} 611 {ClientSignature} 612 {ClientFinished} --------> 614 Figure 2: Integration of OPAQUE in TLS 1.3 (with userid confidentiality) 615 We note that the above approaches for integarion of OPAQUE with TLS 616 can benefit from the post-handshake client authentication mechanism 617 of TLS 1.3 and the exported authenticators from 618 [I-D.ietf-tls-exported-authenticator]. Also, formatting of messages 619 and negotiation information suggested in [I-D.barnes-tls-pake] can be 620 used in the OPAQUE setting. 622 5. User enumeration 624 User enumeration refers to attacks where the attacker tries to learn 625 whether a given user identity is registered with a server. 626 Preventing such attack requires the server to act with unknown user 627 identities in a way that is indistinguishable from its behavior with 628 existing users. Supporting such defense in OPAQUE requires a 629 modification of the protocol. Note that the server's response to an 630 existing user identity includes two values: a^kU and EnvU. So for a 631 non-existing user these two values need to be sent too. Moreover, 632 the response needs to be the same each time that the same user 633 identity and value a are sent to the server. To achieve this a 634 server can choose the OPRF key kU for a (valid or fake) user "UId" as 635 kU=f(MK; UId) where f is a regular PRF and MK is a server's global 636 key. 638 The above does not change the protocol as it is a matter of 639 implementation. However, dealing with EnvU for unknown users 640 requires the following change in OPAQUE. In addition to storing EnvU 641 during password registration, the server will also store a value EEK 642 (for EnvU Encryption Key) derived from RwdU by the user. During 643 login, instead of sending EnvU, the server will send a fresh 644 randomized encryption of EnvU under key EEK which the user can 645 decrypt to obtain EnvU after computing RwdU via the OPRF (the rest is 646 the same as before). Since different encryptions of EnvU by the 647 server are independently randomized, the server can simulate such 648 encryption for an unexisting user by encrypting a string of, say, all 649 zeros (or simply sending a random string of the ciphertext's length 650 if the ciphertexts themselves are pseudorandom as in the case of 651 counter mode). Note that both the EEK and the key used to generate 652 EnvU need to be derived from RwdU via a KDF. 654 [Question: How significant is the user enumeration issue? Should we 655 define OPAQUE as above with built-in defense against enumeration?] 657 6. Security considerations 659 This is an early draft presenting the OPAQUE concept and its 660 potential instantiations. More information on implementation and 661 security considerations will be provided in future drafts. We note 662 that the security of OPAQUE is formally proved in [OPAQUE] under a 663 strong model of aPAKE security assuming the security of the OPRF 664 function and of the underlying key-exchange protocol. In turn, the 665 security of DH-OPRF is proven in the random oracle model under the 666 One-More Diffie-Hellman assumption. 668 While one can expect the practical security of the OPRF function 669 (namely, the hardness of computing the function without knowing the 670 key) to be in the order of computing discrete logarithms or solving 671 Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an 672 attack that slightly improves on generic attacks. For the case that 673 q-1 or q+1, where q is the order of the group G, has a t-bit divisor, 674 they show an attack that calls the OPRF on 2^t chosen inputs and 675 reduces security by t/2 bits, i.e., it can find the OPRF key in time 676 2^{p/2-t/2} and 2^{p/2-t/2} memory. For typical curves, the attack 677 requires an infeasible number of calls and/or results in insignificant 678 security loss [*]. Moreover, in the OPAQUE application, attempting such 679 attacks is completely impractical as the number of calls to the function 680 translates to an equal number of failed authentication attempts by a 681 _single_ user (e.g., one would need a billion impersonation attempts to 682 reduce security by 15 bits and a trillion to reduce it by 20 bits - and 683 most curves will not even allow for such attacks in the first place). 685 [*] Some examples (courtesy of Dan Brown): For P-384 2^90 calls 686 reduce security from 192 to 147 bits; for NIST P-256 the options are 687 6-bit reduction with 2153 OPRF calls, about 14 bit reduction with 187 688 million calls and 20 bits with a trillion calls. For Curve25519, 689 attacks are completely infeasible (require over 2^100 calls) but its 690 twist form allows an attack with 25759 calls that reduces security by 691 7 bits and one with 117223 calls that reduces security by 8.4 bits. 693 7. References 695 7.1. Normative References 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", BCP 14, RFC 2119, March 1997. 700 7.2. Informative References 702 [Boyen09] Boyen, X., "HPAKE: Password authentication secure against 703 cross-site user impersonation", Cryptology and Network 704 Security (CANS) , 2009. 706 [BG04] Brown, D. and R. Galant, "The static Diffie-Hellman 707 problem", http://eprint.iacr.org/2004/306 , 2004. 709 [Canetti01] 710 Canetti, R., "Universally composable security: A new 711 paradigm for cryptographic protocols", IEEE Symposium on 712 Foundations of Computer Science (FOCS) , 2001. 714 [Cheon06] Cheon, J., "Security analysis of the strong Diffie-Hellman 715 problem", Euroctypt 2006 , 2006. 717 [FK00] Ford, W. and B. Kaliski, Jr, "Server-assisted generation 718 of a strong secret from a password", WETICE , 2000. 720 [GMR06] Gentry, C., MacKenzie, P., and . Z, Ramzan, "A method for 721 making password-based key exchange resilient to server 722 compromise", CRYPTO , 2006. 724 [I-D.ietf-tls-exported-authenticator] 725 Sullivan, N., "Exported Authenticators in TLS", draft- 726 ietf-tls-exported-authenticator-07 (work in progress), 727 June 2018. 729 [I-D.barnes-tls-pake] 730 Barnes, R. and O. Friel, "Usage of SPAKE with TLS 1.3", 731 draft-barnes-tls-pake-02 (work in progress), June 2018. 733 [I-D.irtf-cfrg-argon2] 734 Biryukov, A., Dinu, D., Khovratovich, D., and S. 735 Josefsson, "The memory-hard Argon2 password hash and 736 proof-of-work function", draft-irtf-cfrg-argon2-03 (work 737 in progress), August 2017. 739 [I-D.irtf-cfrg-spake2] 740 Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", draft-irtf-cfrg- 741 spake2-05 (work in progress), February 2018. 743 [I-D.ietf-tls-tls13] 744 Rescorla, E., "The Transport Layer Security (TLS) Protocol 745 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 746 March 2018. 748 [I-D.irtf-cfrg-hash-to-curve] 749 Scott, S., Sullivan, N., and C. Wood, "Hashing to Elliptic 750 Curves", draft-irtf-cfrg-hash-to-curve-01 (work in 751 progress), July 2018. 753 [OPAQUE] Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An 754 Asymmetric PAKE Protocol Secure Against Pre-Computation 755 Attacks", Eurocrypt , 2018. 757 [JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu, 758 "Highly-efficient and composable password-protected secret 759 sharing (or: how to protect your bitcoin wallet online)", 760 IEEE European Symposium on Security and Privacy , 2016. 762 [SIGMA] Krawczyk, H., "SIGMA: The SIGn-and-MAc approach to 763 authenticated Diffie-Hellman and its use in the IKE 764 protocols", CRYPTO , 2003. 766 [HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie- 767 Hellman protocol", CRYPTO , 2005. 769 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 770 RFC 2945, DOI 10.17487/RFC2945, September 2000, 771 . 773 [RFC6628] Shin, S. and K. Kobara, "Efficient Augmented Password-Only 774 Authentication and Key Exchange for IKEv2", RFC 6628, DOI 775 10.17487/RFC6628, June 2012, . 778 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 779 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 780 August 2016, . 782 Author's Address 784 Hugo Krawczyk 785 IBM Research 787 Email: hugo@ee.technion,ac.il