idnits 2.17.1 draft-krawczyk-cfrg-opaque-06.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: ---------------------------------------------------------------------------- No issues found here. 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 19, 2020) is 1406 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-07 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-12 == Outdated reference: A later version (-13) exists of draft-irtf-cfrg-argon2-10 == Outdated reference: A later version (-16) exists of draft-irtf-cfrg-hash-to-curve-08 == Outdated reference: A later version (-21) exists of draft-irtf-cfrg-voprf-03 == Outdated reference: A later version (-01) exists of draft-sullivan-tls-opaque-00 Summary: 1 error (**), 0 flaws (~~), 8 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 Algorand Foundation 4 Intended status: Informational June 19, 2020 5 Expires: December 21, 2020 7 The OPAQUE Asymmetric PAKE Protocol 8 draft-krawczyk-cfrg-opaque-06 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 reliance on PKI and 15 with security against pre-computation attacks upon server compromise. 16 Prior aPAKE protocols did not use salt and if they did, the salt was 17 transmitted in the clear from server to user allowing for the 18 building of targeted pre-computed dictionaries. OPAQUE security has 19 been proven by Jarecki et al. (Eurocrypt 2018) in a strong and 20 universally composable formal model of aPAKE security. In addition, 21 the protocol provides forward secrecy and the ability to hide the 22 password from the server even during password registration. 24 Strong security, versatility through modularity, good performance, 25 and an array of additional features make OPAQUE a natural candidate 26 for practical use and for adoption as a standard. To this end, this 27 draft presents several instantiations of OPAQUE and ways of 28 integrating OPAQUE with TLS. 30 This draft presents a high-level description of OPAQUE, highlighting 31 its components and modular design. It also provides the basis for a 32 specification for standardization but a detailed specification ready 33 for implementation is beyond the scope of this document. 35 Implementers of OPAQUE should ONLY follow the precise specification 36 in the upcoming draft-irtf-cfrg-opaque. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 21, 2020. 55 Copyright Notice 57 Copyright (c) 2020 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 74 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2. DH-OPRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.1. DH-OPRF instantiation and detailed specification . . . . 8 77 2.2. Hardening OPRF via user iterations . . . . . . . . . . . 8 78 3. OPAQUE Specification . . . . . . . . . . . . . . . . . . . . 8 79 3.1. Password registration . . . . . . . . . . . . . . . . . . 9 80 3.2. Online OPAQUE protocol (Login and key exchange) . . . . . 10 81 3.3. Parties' identities . . . . . . . . . . . . . . . . . . . 10 82 4. Specification of the EnvU envelope . . . . . . . . . . . . . 11 83 5. OPAQUE Instantiations . . . . . . . . . . . . . . . . . . . . 13 84 5.1. Instantiation of OPAQUE with HMQV and 3DH . . . . . . . . 13 85 5.2. Instantiation of OPAQUE with SIGMA-I . . . . . . . . . . 16 86 6. Integrating OPAQUE with TLS 1.3 . . . . . . . . . . . . . . . 17 87 7. User enumeration . . . . . . . . . . . . . . . . . . . . . . 20 88 8. Security considerations . . . . . . . . . . . . . . . . . . . 21 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 92 10.2. Informative References . . . . . . . . . . . . . . . . . 24 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 95 1. Introduction 97 Password authentication is the prevalent form of authentication in 98 the web and in most other applications. In the most common 99 implementation, a user authenticates to a server by entering its user 100 id and password where both values are transmitted to the server under 101 the protection of TLS. This makes the password vulnerable to TLS 102 failures, including many forms of PKI attacks, certificate 103 mishandling, termination outside the security perimeter, visibility 104 to middle boxes, and more. Moreover, even under normal operation, 105 passwords are always visible in plaintext form at the server upon TLS 106 decryption (in particular, storage of plaintext passwords is not an 107 uncommon security incident, even among security-conscious companies). 109 Asymmetric (or augmented) Password Authenticated Key Exchange (aPAKE) 110 protocols are designed to provide password authentication and 111 mutually authenticated key exchange without relying on PKI (except 112 during user/password registration) and without disclosing passwords 113 to servers or other entities other than the client machine. A secure 114 aPAKE should provide the best possible security for a password 115 protocol, namely, it should only be open to inevitable attacks: 116 online impersonation attempts with guessed user passwords and offline 117 dictionary attacks upon the compromise of a server and leakage of its 118 password file. In the latter case, the attacker learns a mapping of 119 a user's password under a one-way function and uses such a mapping to 120 validate potential guesses for the password. Crucially important is 121 for the password protocol to use an unpredictable one-way mapping or 122 otherwise the attacker can pre-compute a deterministic list of mapped 123 passwords leading to almost instantaneous leakage of passwords upon 124 server compromise. 126 Quite surprisingly, in spite of the existence of multiple designs for 127 (PKI-free) aPAKE protocols, none of these protocols is secure against 128 pre-computation attacks. In particular, none of these protocols can 129 use the standard technique against pre-computation that combines 130 _secret_ random values ("salt") into the one-way password mappings. 131 Either these protocols do not use salt at all or, if they do, they 132 transmit the salt from server to user in the clear, hence losing the 133 secrecy of the salt and its defense against pre-computation. 134 Furthermore, the transmission of salt may incur additional protocol 135 messages. 137 This draft describes OPAQUE, a PKI-free secure aPAKE that is secure 138 against pre-computation attacks and capable of using secret salt. 139 OPAQUE has been recently defined and studied by Jarecki et al. 140 [OPAQUE] who prove the security of the protocol in a strong aPAKE 141 model that ensures security against pre-computation attacks and is 142 formulated in the Universal Composability (UC) framework [Canetti01] 143 under the random oracle model. In contrast, very few aPAKE protocols 144 have been proven formally and those proven were analyzed in a weak 145 security model that allows for pre-computation attacks (e.g., 146 [GMR06]). This is not just a formal issue: these protocols are 147 actually vulnerable to such attacks. This includes protocols that 148 have recent analyses in the UC model such as AuCPace [AuCPace] and 149 SPAKE2+ [SPAKE2plus]. We note that as shown in [OPAQUE], these 150 protocols, and any aPAKE in the model from [GMR06], can be converted 151 into an aPAKE secure against pre-computation attacks at the expense 152 of an additional OPRF execution. 154 It is worth noting that the currently most deployed (PKI-free) aPAKE 155 is SRP [RFC2945], which is open to pre-computation attacks, is 156 inefficient relative to OPAQUE. Moreover, SRP requires a ring as it 157 mixes addition and multiplication operations, and thus does not work 158 over plain elliptic curves. OPAQUE is therefore a suitable 159 replacement. 161 OPAQUE's design builds on a line of work initiated in the seminal 162 paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol 163 of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et 164 al. [JKKX16]. None of these papers considered security against pre- 165 computation attacks or presented a proof of aPAKE security (not even 166 in a weak model). 168 In addition to its proven resistance to pre-computation attacks, 169 OPAQUE's security features include forward secrecy (essential for 170 protecting past communications in case of password leakage) and the 171 ability to hide the password from the server - even during password 172 registration. Moreover, good performance and an array of additional 173 features make OPAQUE a natural candidate for practical use and for 174 adoption as a standard. Such features include the ability to 175 increase the difficulty of offline dictionary attacks via iterated 176 hashing or other hardening schemes, and offloading these operations 177 to the client (that also helps against online guessing attacks); 178 extensibility of the protocol to support storage and retrieval of 179 user's secrets solely based on a password; and being amenable to a 180 multi-server distributed implementation where offline dictionary 181 attacks are not possible without breaking into a threshold of servers 182 (such distributed solution requires no change or awareness on the 183 client side relative to a single-server implementation). 185 OPAQUE is defined and proven as the composition of two 186 functionalities: An Oblivious PRF (OPRF) and a key-exchange protocol. 187 It can be seen as a "compiler" for transforming any key-exchange 188 protocol (with KCI security and forward secrecy - see below) into a 189 secure aPAKE protocol. In OPAQUE, the user stores a secret private 190 key at the server during password registration and retrieves this key 191 each time it needs to authenticate to the server. The OPRF security 192 properties ensure that only the correct password can unlock the 193 private key while at the same time avoiding potential offline 194 guessing attacks. This general composability property provides great 195 flexibility and enables a variety of OPAQUE instantiations, from 196 optimized performance to integration with TLS. The latter aspect is 197 of prime importance as the use of OPAQUE with TLS constitutes a major 198 security improvement relative to the standard password-over-TLS 199 practice. At the same time, the combination with TLS builds OPAQUE 200 as a fully functional secure communications protocol and can help 201 provide privacy to account information sent by the user to the server 202 prior to authentication. 204 The KCI property required from KE protocols for use with OPAQUE 205 states that knowledge of a party's private key does not allow an 206 attacker to impersonate others to that party. This is an important 207 security property achieved by most public-key based KE protocols, 208 including protocols that use signatures or public key encryption for 209 authentication. It is also a property of many implicitly 210 authenticated protocols (e.g., HMQV) but not all of them. We also 211 note that key exchange protocols based on shared keys do not satisfy 212 the KCI requirement, hence they are not considered in the OPAQUE 213 setting. We note that KCI is needed to ensure a crucial property of 214 OPAQUE: even upon compromise of the server, the attacker cannot 215 impersonate the user to the server without first running an 216 exhaustive dictionary attack. Another essential requirement from KE 217 protocols for use in OPAQUE is to provide forward secrecy (against 218 active attackers). 220 This draft presents a high-level description of OPAQUE highlighting 221 its components and modular design. It also provides the basis for a 222 specification for standardization but a detailed specification ready 223 for implementation is beyond the current scope of this document 224 (which may be expanded in future revisions or done separately). 226 We describe OPAQUE with a specific instantiation of the OPRF 227 component over elliptic curves and with a few KE schemes, including 228 the HMQV [HMQV], 3DH [SIGNAL] and SIGMA [SIGMA] protocols. We also 229 present several strategies for integrating OPAQUE with TLS 1.3 230 [RFC8446] offering different tradeoffs between simplicity, 231 performance and user privacy. In general, the modularity of OPAQUE's 232 design makes it easy to integrate with additional key-exchange 233 protocols, e.g., IKEv2. 235 The computational cost of OPAQUE is determined by the cost of the 236 OPRF, the cost of a regular Diffie-Hellman exchange, and the cost of 237 authenticating such exchange. In our elliptic-curve implementation 238 of the OPRF, the cost for the client is two exponentiations (one or 239 two of which can be fixed base) and one hashing-into-curve operation 240 [I-D.irtf-cfrg-hash-to-curve]; for the server, it is just one 241 exponentiation. The cost of a Diffie-Hellman exchange is as usual 242 two exponentiations per party (one of which is fixed-base). Finally, 243 the cost of authentication per party depends on the specific KE 244 protocol: it is just 1/6 of an exponentiation with HMQV, two 245 exponentiations for 3DH, and it is one signature generation and 246 verification in the case of SIGMA and TLS 1.3. These instantiations 247 preserve the number of messages in the underlying KE protocol except 248 in one of the TLS instantiations where user privacy may require an 249 additional round trip. 251 1.1. Terminology 253 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 254 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 255 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 256 [RFC2119] 258 1.2. Notation 260 Throughout this document the first argument to a keyed function 261 represents the key; separated by a semicolon are the function inputs 262 typically implemented as an unambiguous concatenation of strings 263 (details of encodings are left for a future, more detailed 264 specification). 266 Except if said otherwise, random choices in this specification refer 267 to drawing with uniform distribution from a given set (i.e., "random" 268 is short for "uniformly random"). Random choices can be replaced 269 with fresh outputs from a cryptographically strong pseudorandom 270 generator or pseudorandom function. 272 The name OPAQUE: A homonym of O-PAKE where O is for Oblivious (the 273 name OPAKE was taken). 275 2. DH-OPRF 277 OPAQUE uses in a fundamental way an Oblivious Pseudo Random Function 278 (OPRF). 280 An Oblivious PRF (OPRF) is an interactive protocol between a server S 281 and a user U defined by a special pseudorandom function (PRF), 282 denoted F. The server's input to the protocol is a key k for PRF F 283 and the user's input is a value x in the domain of F. At the end of 284 the protocol, U learns F(k; x) and nothing else while S learns 285 nothing from the protocol execution (in particular nothing about x or 286 the value F(k; x)). 288 OPAQUE uses a specific OPRF instantiation, called DH-OPRF, where the 289 PRF, denoted F, is defined next, generically. 291 Parameters: Hash function H (e.g., SHA2 or SHA3 function) with 292 256-bit output at least, a cyclic group G of prime order q, a 293 generator g of G, and hash function H' mapping arbitrary strings into 294 G (where H' is modeled as a random oracle). 296 o DH-OPRF domain: Any string 298 o DH-OPRF range: The range of the hash function H 300 o DH-OPRF key: A random element k in [0..q-1] 302 o DH-OPRF Operation: F(k; x) = H(x, H'(x)^k) 304 Protocol for computing DH-OPRF, U with input x and S with input k: 306 o U: choose random r in [0..q-1], send alpha=H'(x)^r to S 308 o S: upon receiving a value alpha, respond with beta=alpha^k 310 o U: upon receiving beta set the PRF output to H(x, beta^{1/r}) 312 Received values alpha, beta are checked to be elements in G other 313 than the identity and the receiving party aborts if the check fails 314 (alternatively, co-factor exponentiation can be applied to the 315 received values). 317 Note (fixed-base blinding): An alternative way of computing DH-OPRF 318 is for U to choose random r in [0..q-1] and send alpha=H'(x)*g^r to 319 S, who responds with beta=alpha^k as well as with the value v=g^k 320 (that S may store together with k). U then sets the OPRF output F(k; 321 x) to H(x, beta*v^{-r}). This reduces the computation at U from two 322 variable-base exponentiations in the above protocol to one fixed-base 323 and one variable-base exponentiation. Moreover, if U stores g^k 324 (e.g., for servers to which it logins frequently), then the 325 computation takes two fixed-base exponentiations (with bases g and 326 g^k). The downside of fixed-base blinding is the need for the server 327 to store g^k and to sent it to the client, which is otherwise not 328 necessary. Applications can choose any of the blinding options as 329 both compute the same function. 331 We note that prior versions of this document defined the OPRF to 332 include g^k under the hash function H in order to provide security 333 for fixed-base blinding. However, [Blinding] proved recently that 334 fixed-base blinding is secure also without hashing g^k. 336 2.1. DH-OPRF instantiation and detailed specification 338 The above description of DH-OPRF is generic and applicable to any 339 cyclic group. Detailed specification for concrete implementations of 340 DH-OPRF can be found in [I-D.irtf-cfrg-voprf] which defines several 341 instantiation suites for DH-OPRF, including the choice of hash-to- 342 curve functions (denoted H' above) as detailed in 343 [I-D.irtf-cfrg-hash-to-curve]. OPAQUE will adopt some of these 344 instantiation suites and their underlying elliptic curves. The 345 latter will determine implementation details for such curves 346 including ways to check curve membership, the suitability of co- 347 factor mechanisms, etc. 349 2.2. Hardening OPRF via user iterations 351 Protocol OPAQUE is strengthened against offline dictionary attacks by 352 applying to the output of DH-OPRF a hardening procedure such as via 353 repeated iterations, memory hard operations, etc. This greatly 354 increases the cost of an offline attack upon the compromise of the 355 password file at the server. For this purpose, we define the 356 extended DH-OPRF F* as 357 F*(k; x) = I^n( H(x, H'(x)^k) ) where I is a hardening function and n 358 is a measure of hardness. For example, I can represent the iterative 359 function of PBKDF2 [RFC8018] and n the number of iterations; in the 360 case of memory-hard functions such as Argon2 [I-D.irtf-cfrg-argon2] 361 and scrypt [RFC7914], I is a more involved memory-hard function and n 362 measures cost factors and other parameters. 364 Parameters to the hardening function can be set to public values or 365 set at the time of password registration and stored at the server. 366 In this case, the server communicates these parameters to the user 367 during OPAQUE executions together with the second OPRF message. We 368 note that the salt value typically input into the KDF can be set to a 369 constant, e.g., all zeros. 371 3. OPAQUE Specification 373 OPAQUE consists of the concurrent run of an OPRF protocol and a key- 374 exchange protocol KE (one that provides mutual authentication based 375 on public keys and satisfies the KCI requirement discussed in the 376 introduction). We first define OPAQUE in a generic way based on any 377 OPRF and any PK-based KE, and later show specific instantiation using 378 DH-OPRF (defined in Section 2) and several KE protocols. The user, 379 running on a client machine, takes the role of initiator in these 380 protocols and the server the responder's. The private-public keys 381 for the user are denoted PrivU and PubU, and for the server PrivS and 382 PubS. 384 3.1. Password registration 386 Password registration is executed between a user U (running on a 387 client machine) and a server S. It is assumed the server can 388 identify the user and the client can authenticate the server during 389 this registration phase. This is the only part in OPAQUE that 390 requires an authenticated channel, either physical, out-of-band, PKI- 391 based, etc. 393 o U chooses password PwdU and a pair of private-public keys PrivU 394 and PubU for the given protocol KE. 396 o S chooses OPRF key kU (random and independent for each user), 397 chooses its own pair of private-public keys PrivS and PubS for use 398 with protocol KE (S can use the same pair of keys with multiple 399 users), and sends PubS to the client. 401 o Client and S run the OPRF F(kU; PwdU) as defined in Section 2 with 402 only the client learning the result. The client then applies a 403 hardening function, as described in Section 2.2, to this result 404 obtaining a value denoted RwdU (for "Randomized PwdU"). The 405 parameters of the hardening function can be public and known to 406 client machines or they can be stored by S and communicated to the 407 client during registration and login sessions. 409 o Client generates an "envelope" EnvU that contains PrivU and PubS, 410 and optionally also PubU and the parties' identities (see 411 Section 3.3), all protected under RwdU. PrivU needs secrecy and 412 authentication protection, while the other values require 413 authentication and optionally secrecy. We provide a precise 414 specification of the enveloping function in Section 4. 415 Implementations of OPAQUE MUST NOT use any enveloping scheme other 416 than as specified in that section. 418 o The client sends EnvU and PubU to S and erases PwdU, RwdU and all 419 keys. S stores (EnvU, PubS, PrivS, PubU, kU) in a user-specific 420 record. If PrivS and PubS are used for multiple users, S can 421 store these values separately and omit them from the user's 422 record. 424 Note (salt). We note that in OPAQUE the OPRF key acts as the secret 425 salt value that ensures the infeasibility of pre-computation attacks. 426 No other salt value is needed. 428 Note (password rules). The above procedure has the significant 429 advantage that the user's password is never disclosed to the server 430 even during registration. Some sites require learning the user's 431 password for enforcing password rules. Doing so voids this important 432 security property of OPAQUE and is not recommended. Moving the 433 password check procedure to the client side is a more secure 434 alternative (limited checks at the server are possible to implement, 435 e.g., detecting repeated passwords). 437 3.2. Online OPAQUE protocol (Login and key exchange) 439 After registration, the user (through a client machine) and server 440 can run the OPAQUE protocol as a password-authenticated key exchange. 441 The protocol proceeds as follows: 443 o Client transmits user/account information to the server so that 444 the server can retrieve the user's record. 446 o Server and client execute the OPRF protocol as defined in 447 Section 2; client sets RwdU to the result of this computation (if 448 this computation includes a hardening function as in Section 2.2, 449 the parameters of this function are either known to the client or 450 communicated by the server). 452 o Server sends EnvU to client. 454 o Client authenticates/decrypts EnvU using RwdU to obtain PrivU, 455 PubS, and any of the optional values (PubU and parties' 456 identities) if included under EnvU. If authentication fails, 457 client aborts. 459 o Client and server run the specified KE protocol using their 460 respective public and private keys. 462 Note that the steps preceding the run of KE can be arranged in just 463 two messages (one from the client and a response from the server). 464 Furthermore, OPAQUE is optimized by running the OPRF and KE 465 concurrently with interleaved and combined messages (while preserving 466 the internal ordering of messages in each protocol). In all cases, 467 the client needs to obtain EnvU and RwdU (i.e., complete the OPRF 468 protocol) before it can use its own private key PrivU and the 469 server's public key PubS in the run of KE. 471 3.3. Parties' identities 473 Authenticated key-exchange protocols generate keys that need to be 474 uniquely and verifiably bound to a pair of identities, in the case of 475 OPAQUE a user and a server. Thus, it is essential for the parties to 476 agree on such identities, including an agreed bit representation of 477 these identities as needed, for example, when inputting identities to 478 a key derivation function. When referring to identities IdU and IdS 479 in this document, we refer to such agreed identities. Applications 480 may have different policies about how and when identities are 481 determined. A natural approach is to tie IdU to the identity the 482 server uses to fetch EnvU (hence determined during password 483 registration) and to tie IdS to the server identity used by the 484 client to initiate a password registration or login sessions. IdS 485 and IdU can also be part of EnvU or be tied to the parties' public 486 keys. In principle, it is possible that identities change across 487 different sessions as long as there is a policy that can establish if 488 the identity is acceptable or not to the peer. However, we note that 489 the public keys of both the server and the user must always be those 490 defined at time of password registration. 492 4. Specification of the EnvU envelope 494 In Section 3.1, EnvU was defined as an envelope containing the user's 495 private key PrivU and server's public key PubS protected under RwdU. 496 Optionally, EnvU may also contain PubU and identities IdS, IdU. The 497 private key PrivU requires secrecy and authentication while the other 498 values need authentication but not necessarily secrecy. Here we 499 specify how such protection is implemented in OPAQUE. This is the 500 only mechanism specified for generating EnvU, it MUST NOT be modified 501 or replaced with other schemes (see the Security Considerations 502 section). 504 We define EnvU on the basis of two fields, SecEnv and ClrEnv. The 505 former contains information to be concealed by the envelope while 506 ClrEnv contains information included in cleartext form in EnvU. 507 PrivU is always included in SecEnv while PubS can be part of SecEnv 508 or ClrEnv as decided by the application. The latter also holds for 509 the optional values PubU, IdU, IdS. 511 Inputs to the enveloping function are SecEnv, ClrEnv (which may be 512 empty), and a fresh random nonce Nonce of length LH, where LH is the 513 output length in bytes of the hash function underlying HKDF. 514 Let LS be the length in bytes of SecEnv. Define: 516 KEYS = HKDF-Expand(key=RwdU, info=(nonce | "EnvU"), Length=LS+LH+LH) 518 Let PAD denote the LS left-most bytes of KEYS, HmacKey the next LH 519 bytes, and ExportKey the last LH bytes. 521 EnvU is generated during the Password Registration phase as follows: 523 (1) Set C = SecEnv XOR PAD 525 (2) Set E = Nonce | C | ClrEnv 527 (3) Set T = HMAC(HmacKey; E) 528 (4) Set EnvU to the pair (E,T) 530 When the client receives EnvU = (E,T) during the online OPAQUE phase, 531 it derives the stream KEYS using RwdU and Nonce as specified above, 532 it uses HmacKey to validate the received value T, and aborts if 533 verification fails. Otherwise, it uses PAD to recover SecEnv, and it 534 proceeds to run the KE part of OPAQUE using the information in SecEnv 535 and ClrEnv. 537 Note (Exporter key). The key ExportKey, part of the KEYS stream, is 538 not used by OPAQUE. Rather, it is exported to the calling 539 application for any purpose for which the application may require a 540 key. A typical example would be for the user to store additional 541 credentials or secret information (a private key, a cryptocurrency 542 wallet, a confidential file, etc.) encrypted under ExportKey at the 543 server. There is no restriction for the type of encryption scheme 544 used in this case. However, ExportKey MUST NOT be used in any way 545 before the HMAC value in EnvU is validated. 547 [[TODO: More precise specification needed here, such as default order 548 of elements in EnvU, their encodings, etc.]] 550 Note (storage/communication efficient EnvU): It is possible to 551 shorten EnvU by including PubS in ClrEnv and omitting SecEnv and any 552 other value from EnvU. In this case, the user's key PrivU is derived 553 from RwdU; e.g., the value PAD in KEYS is used as a seed for a key 554 generation procedure that outputs PrivU (the length of PAD will 555 depend on the specific key generation procedure). Such EnvU consists 556 of Nonce, PubS and the HMAC value, resulting in less storage at the 557 server and less communication from server to client. The server can 558 further minimize storage space by deriving per-user OPRF keys kU from 559 a single global secret key using a PRF, and it can use the same pair 560 (PrivS,PubS) for all its users. In this case, the per-user OPAQUE 561 storage consists of Nonce, PubU and HMAC(Khmac; PubS). While it may 562 be "tempting" to omit Nonce for space savings, this can lead to 563 vulnerabilities (see below). 565 [[TODO: Do we want to document the above option? Note that it 566 contradicts the earlier specification that mandates including PrivU 567 under SecEnv. This is to be decided according to whether people 568 think that the savings of PrivU in server's storage and communication 569 warrants this option.]] 571 Note (Necessity of Nonce): The random value Nonce used in the 572 derivation of PAD must not be omitted. Doing so leads to the 573 repeated use of the same PAD value in case that a user registers 574 twice the same password and the server reuses the same kU. This 575 results in the use of the same PAD for XORing two different values of 576 PrivU. Moreover, an adversarial server that intentionally reuses the 577 same kU with different users, will cause users with the same PwdU to 578 generate the same PAD, from which the server can learn information 579 about their respective PrivU values. This attack is particularly 580 damaging if PAD is used as a seed to derive PrivU. 582 [[Consider moving last paragraph to Security Considerations.]] 584 5. OPAQUE Instantiations 586 We present several instantiations of OPAQUE using DH-OPRF and 587 different KE protocols. For the sake of concreteness we focus on KE 588 protocols consisting of three messages, denoted KE1, KE2, KE3, and 589 such that KE1 and KE2 include DH values sent by user and server, 590 respectively, and KE3 provides explicit user authentication. As 591 shown in [OPAQUE], OPAQUE cannot use less than three messages so the 592 3-message instantiations presented here are optimal in terms of 593 number of messages. On the other hand, there is no impediment of 594 using OPAQUE with protocols with more than 3 messages as in the case 595 of IKEv2 (or its underlying SIGMA-R protocol [SIGMA]). 597 OPAQUE generic outline with 3-message KE: 599 o C to S: IdU, alpha=H'(PwdU)^r, KE1 601 o S to C: beta=alpha^kU, EnvU, KE2 603 o C to S: KE3 605 Key derivation and other details of the protocol are specified by the 606 KE scheme. We do note that by the results in [OPAQUE], KE2 and KE3 607 should include authentication of the OPRF messages (or at least of 608 the value alpha) for binding between the OPRF run and the KE session. 610 Next, we present three instantiations of OPAQUE - with HMQV, 3DH and 611 SIGMA-I. In Section 6 we discuss integration with TLS 1.3 [RFC8446]. 613 5.1. Instantiation of OPAQUE with HMQV and 3DH 615 The integration of OPAQUE with HMQV [HMQV] leads to the most 616 efficient instantiation of OPAQUE in terms of exponentiations count. 617 Performance is close to optimal due to the low cost of authentication 618 in HMQV: Just 1/6 of an exponentiation for each party over the cost 619 of a regular DH exchange. However, HMQV is encumbered by an IBM 620 patent, hence we also present OPAQUE with 3DH which only differs in 621 the key derivation function at the cost of an extra exponentiation 622 (and less resilience to the compromise of ephemeral exponents). We 623 note that 3DH serves as a basis for the key-exchange protocol of 624 [SIGNAL]. 626 Importantly, many other protocols follow a similar format with 627 differences mainly in the key derivation function. This includes the 628 Noise family of protocols. Extension may also apply to KEM-based KE 629 protocols as in many post-quantum candidates. 631 The private and public keys of the parties in these examples are 632 Diffie-Hellman keys, namely, PubU=g^PrivU and PubS=g^PrivS. 634 Specification/implementation details that are specific to the choice 635 of group G will be adapted from the corresponding standards for 636 different elliptic curves. 638 PROTOCOL MESSAGES. OPAQUE with HMQV and OPAQUE with 3DH comprises: 640 o KE1 = OPRF1, nonceU, info1*, IdU*, ePubU 642 o KE2 = OPRF2, EnvU, nonceS, info2*, ePubS, Einfo2*, Mac(Km3; 643 xcript2), 645 o KE3 = info3*, Einfo3*, Mac(Km3; xcript3)} 647 where: 649 o * denotes optional elements; 651 o OPRF1, OPRF2 denote the DH-OPRF values alpha, beta sent by user 652 and server, respectively, as defined in Section 2; 654 o EnvU is the OPAQUE's envelope stored by the server containing 655 keying information for the client to run the AKE with the server; 657 o nonceU, nonceS are fresh random nonces chosen by client and 658 server, respectively; 660 o info1, info2, info3 denote optional application-specific 661 information sent in the clear (e.g., they can include parameter 662 negotiation, parameters for a hardening function, etc.); 664 o Einfo2, Einfo3 denotes optional application-specific information 665 sent encrypted under keys Ke2, Ke3 defined below; 667 o IdU is the user's identity used by the server to fetch the 668 corresponding user record, including EnvU, OPRF key, etc. (it can 669 be omitted from message KE1 if the information is available to the 670 server in some other way); 672 o IdS, the server's identity, is not shown explicitly, it can be 673 part of an info field (encrypted or not), part of EnvU, or can be 674 known from other context (see Section 3.3); it is used crucially 675 for key derivation (see below); 677 o ePubU, ePubS are Diffie-Hellman ephemeral public keys chosen by 678 user and server, respectively; 680 o xcript2 includes the concatenation of the values OPRF1, nonceU, 681 info1*, IdU*, ePubU, OPRF2, EnvU, nonceS, info2*, ePubS, Einfo2*; 683 o xcript3 includes the concatenation of all elements in xcript2 684 followed by info3*, Einfo3*; 686 Notes: 688 o The explicit concatenation of elements under xcript2 and xcript3 689 can be replaced with hashed values of these elements, or their 690 combinations, using a collision-resistant hash (e.g., as in the 691 transcript-hash of TLS 1.3). 693 o The inclusion of the values OPRF1 and OPRF2 under xcript2 is 694 needed for binding the OPRF execution to that of the KE session. 695 On the other hand, including EnvU in xcript2 is not mandatory. 697 o The ephemeral keys ePubU, ePubS, can be exchanged prior to the 698 above 3 messages, e.g., when running these protocols under TLS 699 1.3. 701 [[TODO: Specify that in the login phase, ephemeral DH values need to 702 be verified to belong to the correct group (via membership tests or 703 cofactor exponentiation). Same hold for public keys during the 704 registration phase. Details of verification depend on the particular 705 group/curve.]] 707 KEY DERIVATION. The above protocol requires MAC keys Km2, Km3, and 708 optional encryption keys Ke2, Ke3, as well as generating a session 709 key SK which is the AKE output for protecting subsequent traffic (or 710 for generating further key material). Key derivation uses HKDF 711 [RFC5869] with a combination of the parties static and ephemeral 712 private-public key pairs and the parties' identities IdU, IdS. See 713 Section 3.3. 715 SK, Km2, Km3, Ke2, Ke3 = HKDF(salt=0, IKM, info, L) 717 where L is the sum of lengths of SK, Km2, Km3, Ke2, Ke3, and SK gets 718 the most significant bytes of the HKDF output, Km2 the next bytes, 719 etc. 721 Values IKM and info are defined for each protocol: 723 For HMQV: 725 o info = "HMQV keys" | nonceU | nonceS | IdU | IdS 727 o IKM = Khmqv 729 where Khmqv is computed: 731 * by the client: Khmqv = (ePubS * PubS^s)^{ePrivU + u*PrivU} 733 * by the server: Khmqv = (ePubU * PubU^u)^{ePrivS + s*PrivS} 735 and u = H(ePubU | "user" | info); s = H(ePubS | "srvr" | info). 737 FOR 3DH: 739 o info = "3DH keys" | nonceU | nonceS | IdU | IdS 741 o IKM = K3dh 743 where K3dh is the concatenation of three DH values computed: 745 * by the client: K3dh = ePubS^ePrivU | PubS^ePrivU | ePubS^PrivU 747 * by the server: K3dh = ePubU^ePrivS | ePubU^PrivS | PubU^ePrivS 749 5.2. Instantiation of OPAQUE with SIGMA-I 751 We show how OPAQUE is built around the 3-message SIGMA-I protocol 752 [SIGMA]. This is an example of a signature-based protocol and also 753 serves as a basis for integration of OPAQUE with TLS 1.3, as the 754 latter follows the design of SIGMA-I (see Section 6. This 755 specification can be extended to the 4-message SIGMA-R protocol as 756 used in IKEv2. 758 PROTOCOL MESSAGES. OPAQUE with SIGMA-I comprises: 760 o KE1 = OPRF1, nonceU, info1*, IdU*, ePubU 762 o KE2 = OPRF2, EnvU, nonceS, info2*, ePubS, Einfo2*, Sign(PrivS; 763 xcript2-), Mac(Km2; IdS), 765 o KE3 = info3*, Einfo3*, Sign(PrivU; xcript3-), Mac(Km3; IdU)} 767 See explanation of fields above. In addition, for the signed 768 material, xcript2- is defined similarly to xcript2, however if 769 xcript2 includes information that identifies the user, such 770 information can be eliminated in xcript2- (this is advised if signing 771 user's identification information by the server is deemed to have 772 adverse privacy consequences). Similarly, xcript3- is defined as 773 xcript3 with server identification information removed if so desired. 775 KEY DERIVATION. Key in SIGMA-I are derived as 777 SK, Km2, Km3, Ke2, Ke3 = HKDF(salt=0, IKM, info, L) 779 where 781 o L is the sum of lengths of SK, Km2, Km3, Ke2, Ke3, and SK gets the 782 most significant bytes of the HKDF output, Km2 the next bytes, 783 etc., 785 o info = "SIGMA-I keys" | nonceU | nonceS | IdU | IdS 787 o IKM = Ksigma 789 and Ksigma is computed: 791 * by the client: Ksigma = ePubS^ePrivU 793 * by the server: Ksigma = ePubU^ePrivS 795 6. Integrating OPAQUE with TLS 1.3 797 This section is intended as a discussion of ways to integrate OPAQUE 798 with TLS 1.3. Precise protocol details are left for a future 799 separate specification. A very preliminary draft is 800 [I-D.sullivan-tls-opaque]. 802 As stated in the introduction, the security of the standard password- 803 over-TLS mechanism for password authentication suffers from its 804 essential reliance on PKI and the exposure of passwords to the server 805 (and possibly others) upon TLS decryption. Integrating OPAQUE with 806 TLS removes these vulnerabilities while at the same time it armors 807 TLS itself against PKI failures. Such integration also benefits 808 OPAQUE by leveraging the standardized negotiation and record-layer 809 security of TLS. Furthermore, TLS offers an initial PKI- 810 authenticated channel to protect the privacy of account information 811 such as user name transmitted between client and server. 813 If one is willing to forgo protection of user account information 814 transmitted between user and server, integrating OPAQUE with TLS 1.3 815 is relatively straightforward and follows essentially the same 816 approach as with SIGMA-I in Section 5.2. Specifically, one reuses 817 the Diffie-Hellman exchange from TLS and uses the user's private key 818 PrivU retrieved from the server as a signature key for TLS client 819 authentication. The integrated protocol will have as its first 820 message the TLS's Client Hello augmented with user account 821 information and with the DH-OPRF first message (the value alpha). 822 The server's response includes the regular TLS 1.3 second flight 823 augmented with the second OPRF message which includes the values beta 824 and EnvU. For its TLS signature, the server uses the private key 825 PrivS whose corresponding public key PubS is authenticated as part of 826 the user envelope EnvU (there is no need to send a regular TLS 827 certificate in this case). Finally, the third flight consists of the 828 standard client Finish message with client authentication where the 829 client's signature is produced with the user's private key PrivU 830 retrieved from EnvU and verified by the server using public key PubU. 832 The above scheme is depicted in Figure 1 where the sign + indicates 833 fields added by OPAQUE, and OPRF1, OPRF2 denote the two DH-OPRF 834 messages. Other messages in the figure are the same as in TLS 1.3. 835 Notation {...} indicates encryption under handshake keys. Note that 836 ServerSignature and ClientSignature are performed with the private 837 keys defined by OPAQUE and they replace signatures by traditional TLS 838 certificates. 840 Client Server 842 ClientHello 843 key_share 844 + userid + OPRF1 --------> 845 ServerHello 846 key_share 847 {+ OPRF2 + EnvU} 848 {ServerSignature} 849 <-------- {ServerFinished} 851 {ClientSignature} 852 {ClientFinished} --------> 854 Figure 1: Integration of OPAQUE in TLS 1.3 (no userid 855 confidentiality) 857 Note that in order to send OPRF1 in the first message, the client 858 needs to know the DH group the server uses for OPRF, or it needs to 859 "guess" it. This issue already appears in TLS 1.3 where the client 860 needs to guess the key_share group and it should be handled similarly 861 in OPAQUE (e.g., the client may try one or more groups in its first 862 message). 864 Protection of user's account information can be added through TLS 1.3 865 pre-shared/resumption mechanisms where the account information 866 appended to the ClientHello message would be encrypted under the pre- 867 shared key. 869 When a resumable session or pre-shared key between the client and the 870 server do not exist, user account protection requires a server 871 certificate. One option that does not add round trips is to use a 872 mechanism similar to the proposed ESNI extension [I-D.ietf-tls-esni] 873 or a semi-static TLS exchange as in [I-D.ietf-tls-semistatic-dh]. 874 Without such extensions, one would run a TLS 1.3 handshake augmented 875 with the two first OPAQUE messages interleaved between the second and 876 third flight of the regular TLS handshake. That is, the protocol 877 consists of five flights as follows: (i) A regular 2-flight 1-RTT 878 handshake to produce handshake traffic keys authenticated by the 879 server's TLS certificate; (ii) two OPAQUE messages that include user 880 identification information, the DH-OPRF messages exchanged between 881 client and server, and the retrieved EnvU, all encrypted under the 882 handshake traffic keys (thus providing privacy to user account 883 information); (iii) the TLS 1.3 client authentication flight where 884 client authentication uses the user's private signature key PrivU 885 retrieved from the server in step (ii). 887 Note that server authentication in step (i) uses TLS certificates 888 hence PKI is used for user account privacy but not for user 889 authentication or other purposes. (In some applications, PKI may be 890 trusted also for server authentication in which case server 891 authentication through OPAQUE may be forgone). In OPAQUE the server 892 authenticates using the private key PrivS whose corresponding public 893 key PubS is sent to the user as part of EnvU. There are two options: 894 If PubS is the same as the public key the server used in the 1-RTT 895 authentication (step (i)) then there is no need for further 896 authentication. Otherwise, the server needs to send a signature 897 under PrivS that is piggybacked to the second OPAQUE message in (ii). 898 In this case, the signature would cover the running transcript hash 899 as is standard in TLS 1.3. The client signature in the last message 900 also covers the transcript hash including the regular handshake and 901 OPAQUE messages. 903 The described scheme is depicted in Figure 2. Please refer to the 904 text before Figure 1 describing notation. Note the asterisk in the 905 ServerSignature message. This indicates that this message is 906 optional as it is used only if the server's key PubS in OPAQUE is 907 different than the one in the server's certificate (transmitted in 908 the second protocol flight). 910 Client Server 912 ClientHello 913 key_share --------> 914 ServerHello 915 key_share 916 {Certificate} 917 {CertificateVerify} 918 <-------- {ServerFinished} 920 {+ userid + OPRF1} --------> 922 {+ OPRF2 + EnvU} 923 <-------- {+ ServerSignature*} 925 {ClientSignature} 926 {ClientFinished} --------> 928 Figure 2: Integration of OPAQUE in TLS 1.3 (with userid 929 confidentiality) 931 We note that the above approaches for integration of OPAQUE with TLS 932 may benefit from the post-handshake client authentication mechanism 933 of TLS 1.3 and the exported authenticators from 934 [I-D.ietf-tls-exported-authenticator]. Also, formatting of messages 935 and negotiation information suggested in [I-D.barnes-tls-pake] can be 936 used in the OPAQUE setting. 938 7. User enumeration 940 User enumeration refers to attacks where the attacker tries to learn 941 whether a given user identity is registered with a server. 942 Preventing such attack requires the server to act with unknown user 943 identities in a way that is indistinguishable from its behavior with 944 existing users. Here we suggest a way to implement such defense, 945 namely, a way for simulating the values beta and EnvU for non- 946 existing users. Note that if the same pair of user identity IdU and 947 value alpha is received twice by the server, the response needs to be 948 the same in both cases (since this would be the case for real users). 949 For protection against this attack, one would apply the encryption 950 function in the construction of EnvU (Section 4) to all the key 951 material in EnvU, namely, AOenv will be empty. The server S will 952 have two keys MK, MK' for a PRF f (this refers to a regular PRF such 953 as HMAC or CMAC). Upon receiving a pair of user identity IdU and 954 value alpha for a non-existing user IdU, S computes kU=f(MK; IdU) and 955 kU'=f(MK'; IdU) and responds with values beta=alpha^kU and EnvU, 956 where the latter is computed as follows. RwdU is set to kU' and 957 AEenv is set to the all-zero string (of the length of a regular EnvU 958 plaintext). Care needs to be taken to avoid side channel leakage 959 (e.g., timing) from helping differentiate these operations from a 960 regular server response. The above requires changes to the server- 961 side implementation but not to the protocol itself or the client 962 side. 964 There is one form of leakage that the above allows and whose 965 prevention would require a change in OPAQUE. Note that an attacker 966 that tests a IdU (and same alpha) twice and receives different 967 responses can conclude that either the user registered with the 968 service between these two activations or that the user was registered 969 before but changed its password in between the activations (assuming 970 the server changes kU at the time of a password change). In any 971 case, this indicates that IdU is a registered user at the time of the 972 second activation. To conceal this information, S can implement the 973 derivation of kU as kU=f(MK; IdU) also for registered users. Hiding 974 changes in EnvU, however, requires a change in the protocol. Instead 975 of sending EnvU as is, S would send an encryption of EnvU under a key 976 that the user derives from the OPRF result (similarly to RwdU) and 977 that S stores during password registration. During login, the user 978 will derive this key from the OPRF result, will use it to decrypt 979 EnvU, and continue with the regular protocol. If S uses a randomized 980 encryption, the encrypted EnvU will look each time as a fresh random 981 string, hence S can simulate the encrypted EnvU also for non-existing 982 users. 984 Note that the first case above does not change the protocol so its 985 implementation is a server's decision (the client side is not 986 changed). The second case, requires changes on the client side so it 987 changes OPAQUE itself. 989 [[TODO: Should this variant be documented/standardized?]] 991 8. Security considerations 993 This is a high-level draft presenting the OPAQUE concept and its 994 potential instantiations. Precise details and complete security 995 considerations will be provided in the upcoming draft-irtf-cfrg- 996 opaque. Implementations should be built on the basis of that 997 document and not the present one. 999 The security of OPAQUE is formally proved in [OPAQUE] under a strong 1000 model of aPAKE security assuming the security of the OPRF function 1001 and of the underlying key-exchange protocol. In turn, the security 1002 of DH-OPRF is proven in the random oracle model under the One-More 1003 Diffie-Hellman assumption [JKKX16]. 1005 Additionally, the above analysis sets requirements on the way 1006 elements in the envelope EnvU are protected. Specifically, while one 1007 can model such protection as an authenticated encryption scheme, 1008 AuthEnc, with optional authenticated-only data, not all authenticated 1009 encryption mechanisms are secure for creating EnvU. To be secure, 1010 such a scheme needs to have the property of "random-key robustness" 1011 (RKR). That is, given a pair of random AuthEnc keys, it should be 1012 infeasible to create an authenticated ciphertext that successfully 1013 decrypts (i.e., passes authentication) under the two keys. Some 1014 natural AuthEnc schemes, including GCM and ChaCha20-Poly1305, do not 1015 satisfy this property and MUST NOT be used for building EnvU (this is 1016 not just a theoretical concern but one that may open OPAQUE to real 1017 attacks). 1019 To avoid wrong implementation choices, we have specified a simple and 1020 efficient mechanism for generating and protecting EnvU (Section 4) 1021 that ensures the required security properties and MUST NOT be 1022 modified or replaced with other schemes. In particular, HMAC should 1023 not be replaced with arbitrary MAC functions. A suitable MAC needs 1024 to satisfy the above RKR property and many practical MAC functions, 1025 particularly Carter-Wegman constructions such as GHASH and Poly1305, 1026 are not RKR-secure. In contrast, HMAC enjoys a stronger form of 1027 robustness: It is infeasible to find keys k1, k2 and messages M1, M2 1028 so that HMAC(k1;M1) = HMAC(k2;M2) (it follows from collision 1029 resistance of the underlying hash function). Yet, another element 1030 necessary for the security of the enveloping scheme is the use of a 1031 fresh random nonce for each EnvU. 1033 Contents of EnvU should be restricted to OPAQUE-specific values 1034 required for setting the keys used in the KE phase. Any functional 1035 application-specific extensions should use the ExportKey (e.g., to 1036 pass application-specific parameters, retrieve additional user 1037 information stored at the server, etc.). ExportKey can be used with 1038 any secure key derivation function or authenticated encryption. 1039 However, it MUST NOT be used (by the client during the login phase) 1040 before the HMAC value in EnvU has been verified. 1042 Best practices regarding implementation of cryptographic schemes 1043 apply to OPAQUE. Particular care needs to be given to the 1044 implementation of the OPRF regarding testing group membership and 1045 avoiding timing and other side channel leakage in the hash-to-curve 1046 mapping. Drafts [I-D.irtf-cfrg-hash-to-curve] and 1047 [I-D.irtf-cfrg-voprf] have detailed instantiation and implementation 1048 guidance that will be integral part of the specification of OPAQUE. 1050 While one can expect the practical security of the OPRF function 1051 (namely, the hardness of computing the function without knowing the 1052 key) to be in the order of computing discrete logarithms or solving 1053 Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an 1054 attack that slightly improves on generic attacks. For the case that 1055 q-1 or q+1, where q is the order of the group G, has a t-bit divisor, 1056 they show an attack that calls the OPRF on 2^t chosen inputs and 1057 reduces security by t/2 bits, i.e., it can find the OPRF key in time 1058 2^{q/2-t/2} and 2^{q/2-t/2} memory. For typical curves, the attack 1059 requires an infeasible number of calls and/or results in 1060 insignificant security loss (*). Moreover, in the OPAQUE 1061 application, these attacks are completely impractical as the number 1062 of calls to the function translates to an equal number of failed 1063 authentication attempts by a _single_ user. For example, one would 1064 need a billion impersonation attempts to reduce security by 15 bits 1065 and a trillion to reduce it by 20 bits - and most curves will not 1066 even allow for such attacks in the first place (note that this 1067 theoretical loss of security is with respect to computing discrete 1068 logarithms, not in reducing the password strength). 1070 (*) Some examples (courtesy of Dan Brown): For P-384, 2^90 calls 1071 reduce security from 192 to 147 bits; for NIST P-256 the options are 1072 6-bit reduction with 2153 OPRF calls, about 14 bit reduction with 187 1073 million calls and 20 bits with a trillion calls. For Curve25519, 1074 attacks are completely infeasible (require over 2^100 calls) but its 1075 twist form allows an attack with 25759 calls that reduces security by 1076 7 bits and one with 117223 calls that reduces security by 8.4 bits. 1078 Note on user authentication vs. authenticated key exchange. OPAQUE 1079 provides PAKE (password-based authenticated key exchange) 1080 functionality in the client-server setting. While in the case of 1081 user identification, focus is often on the authentication part, we 1082 stress that the key exchange element is not less crucial. Indeed, in 1083 most cases user authentication is performed to enforce some policy, 1084 and the key exchange part is essential for binding this enforcement 1085 to the authentication step. Skipping the key exchange part is 1086 analogous to carefully checking a visitor's credential at the door 1087 and then leaving the door open for others to enter freely. 1089 This draft complies with the requirements for PAKE protocols set 1090 forth in [RFC8125]. 1092 9. Acknowledgments 1094 The OPAQUE protocol and its analysis is joint work of the author with 1095 Stas Jarecki and Jiayu Xu. We are indebted to the OPAQUE reviewers 1096 during CFRG's aPAKE selection process, particularly Julia Hesse and 1097 Bjorn Tackmann. This draft has benefited from comments by multiple 1098 people. Special thanks to Richard Barnes, Dan Brown, Eric Crockett, 1099 Paul Grubbs, Fredrik Kuivinen, Kevin Lewi, Payman Mohassel, Jason 1100 Resch, Nick Sullivan and Chris Wood. 1102 10. References 1104 10.1. Normative References 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, 1108 DOI 10.17487/RFC2119, March 1997, 1109 . 1111 10.2. Informative References 1113 [AuCPace] Haase, B. and B. Labrique, "AuCPace: Efficient verifier- 1114 based PAKE protocol tailored for the IIoT", 1115 http://eprint.iacr.org/2018/286 , 2018. 1117 [BG04] Brown, D. and R. Galant, "The static Diffie-Hellman 1118 problem", http://eprint.iacr.org/2004/306 , 2004. 1120 [Blinding] 1121 Jarecki, S., Krawczyk, H., and J. Xu, "Multiplicative DH- 1122 OPRF and Its Applications to Password Protocols", 1123 Manuscript , 2020. 1125 [Boyen09] Boyen, X., "HPAKE: Password authentication secure against 1126 cross-site user impersonation", Cryptology and Network 1127 Security (CANS) , 2009. 1129 [Canetti01] 1130 Canetti, R., "Universally composable security: A new 1131 paradigm for cryptographic protocols", IEEE Symposium on 1132 Foundations of Computer Science (FOCS) , 2001. 1134 [Cheon06] Cheon, J., "Security analysis of the strong Diffie-Hellman 1135 problem", Euroctypt 2006 , 2006. 1137 [FK00] Ford, W. and B. Kaliski, Jr, "Server-assisted generation 1138 of a strong secret from a password", WETICE , 2000. 1140 [GMR06] Gentry, C., MacKenzie, P., and . Z, Ramzan, "A method for 1141 making password-based key exchange resilient to server 1142 compromise", CRYPTO , 2006. 1144 [HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie- 1145 Hellman protocol", CRYPTO , 2005. 1147 [I-D.barnes-tls-pake] 1148 Barnes, R. and O. Friel, "Usage of PAKE with TLS 1.3", 1149 draft-barnes-tls-pake-04 (work in progress), July 2018. 1151 [I-D.ietf-tls-esni] 1152 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1153 Encrypted Client Hello", draft-ietf-tls-esni-07 (work in 1154 progress), June 2020. 1156 [I-D.ietf-tls-exported-authenticator] 1157 Sullivan, N., "Exported Authenticators in TLS", draft- 1158 ietf-tls-exported-authenticator-12 (work in progress), May 1159 2020. 1161 [I-D.ietf-tls-semistatic-dh] 1162 Rescorla, E., Sullivan, N., and C. Wood, "Semi-Static 1163 Diffie-Hellman Key Establishment for TLS 1.3", draft-ietf- 1164 tls-semistatic-dh-01 (work in progress), March 2020. 1166 [I-D.irtf-cfrg-argon2] 1167 Biryukov, A., Dinu, D., Khovratovich, D., and S. 1168 Josefsson, "The memory-hard Argon2 password hash and 1169 proof-of-work function", draft-irtf-cfrg-argon2-10 (work 1170 in progress), March 2020. 1172 [I-D.irtf-cfrg-hash-to-curve] 1173 Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and 1174 C. Wood, "Hashing to Elliptic Curves", draft-irtf-cfrg- 1175 hash-to-curve-08 (work in progress), June 2020. 1177 [I-D.irtf-cfrg-voprf] 1178 Davidson, A., Sullivan, N., and C. Wood, "Oblivious 1179 Pseudorandom Functions (OPRFs) using Prime-Order Groups", 1180 draft-irtf-cfrg-voprf-03 (work in progress), March 2020. 1182 [I-D.sullivan-tls-opaque] 1183 Sullivan, N., Krawczyk, H., Friel, O., and R. Barnes, 1184 "Usage of OPAQUE with TLS 1.3", draft-sullivan-tls- 1185 opaque-00 (work in progress), March 2019. 1187 [JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu, 1188 "Highly-efficient and composable password-protected secret 1189 sharing (or: how to protect your bitcoin wallet online)", 1190 IEEE European Symposium on Security and Privacy , 2016. 1192 [OPAQUE] Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An 1193 Asymmetric PAKE Protocol Secure Against Pre-Computation 1194 Attacks", Eurocrypt , 2018. 1196 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 1197 RFC 2945, DOI 10.17487/RFC2945, September 2000, 1198 . 1200 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1201 Key Derivation Function (HKDF)", RFC 5869, 1202 DOI 10.17487/RFC5869, May 2010, 1203 . 1205 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 1206 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 1207 August 2016, . 1209 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 1210 Password-Based Cryptography Specification Version 2.1", 1211 RFC 8018, DOI 10.17487/RFC8018, January 2017, 1212 . 1214 [RFC8125] Schmidt, J., "Requirements for Password-Authenticated Key 1215 Agreement (PAKE) Schemes", RFC 8125, DOI 10.17487/RFC8125, 1216 April 2017, . 1218 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1219 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1220 . 1222 [SIGMA] Krawczyk, H., "SIGMA: The SIGn-and-MAc approach to 1223 authenticated Diffie-Hellman and its use in the IKE 1224 protocols", CRYPTO , 2003. 1226 [SIGNAL] "Signal recommended cryptographic algorithms", 1227 https://signal.org/docs/specifications/ 1228 doubleratchet/#recommended-cryptographic-algorithms , 1229 2016. 1231 [SPAKE2plus] 1232 Shoup, V., "Security Analysis of SPAKE2+", 1233 http://eprint.iacr.org/2020/313 , 2020. 1235 Author's Address 1237 Hugo Krawczyk 1238 Algorand Foundation 1240 Email: hugokraw@gmail.com