idnits 2.17.1 draft-krawczyk-cfrg-opaque-05.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 date (May 29, 2020) is 1428 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3686' is mentioned on line 1222, but not defined -- Looks like a reference, but probably isn't: '1' on line 1228 -- Looks like a reference, but probably isn't: '2' on line 1228 -- Looks like a reference, but probably isn't: '0' on line 1256 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-06 == 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-07 == 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 (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Crypto Forum Research Group H. Krawczyk 3 Internet-Draft Algorand Foundation 4 Intended status: Informational May 29, 2020 5 Expires: November 30, 2020 7 The OPAQUE Asymmetric PAKE Protocol 8 draft-krawczyk-cfrg-opaque-05 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 current scope of this document 34 (which may be expanded in future revisions or done separately). 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on November 30, 2020. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 72 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 73 2. DH-OPRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.1. DH-OPRF instantiation and detailed specification . . . . 8 75 2.2. Hardening OPRF via user iterations . . . . . . . . . . . 8 76 3. OPAQUE Specification . . . . . . . . . . . . . . . . . . . . 8 77 3.1. Password registration . . . . . . . . . . . . . . . . . . 9 78 3.2. Online OPAQUE protocol (Login and key exchange)) . . . . 10 79 3.3. Parties' identities . . . . . . . . . . . . . . . . . . . 10 80 4. Specification of the EnvU envelope . . . . . . . . . . . . . 11 81 5. OPAQUE Instantiations . . . . . . . . . . . . . . . . . . . . 13 82 5.1. Instantiation of OPAQUE with HMQV and 3DH . . . . . . . . 14 83 5.2. Instantiation of OPAQUE with SIGMA-I . . . . . . . . . . 17 84 6. Integrating OPAQUE with TLS 1.3 . . . . . . . . . . . . . . . 18 85 7. User enumeration . . . . . . . . . . . . . . . . . . . . . . 21 86 8. Security considerations . . . . . . . . . . . . . . . . . . . 22 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 89 9.2. Informative References . . . . . . . . . . . . . . . . . 24 90 Appendix A. Counter mode encryption . . . . . . . . . . . . . . 26 91 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 27 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 94 1. Introduction 96 Password authentication is the prevalent form of authentication in 97 the web and in most other applications. In the most common 98 implementation, a user authenticates to a server by entering its user 99 id and password where both values are transmitted to the server under 100 the protection of TLS. This makes the password vulnerable to TLS 101 failures, including many forms of PKI attacks, certificate 102 mishandling, termination outside the security perimeter, visibility 103 to middle boxes, and more. Moreover, even under normal operation, 104 passwords are always visible in plaintext form at the server upon TLS 105 decryption (in particular, storage of plaintext passwords is not an 106 uncommon security incident, even among security-conscious companies). 108 Asymmetric (or augmented) Password Authenticated Key Exchange (aPAKE) 109 protocols are designed to provide password authentication and 110 mutually authenticated key exchange without relying on PKI (except 111 during user/password registration) and without disclosing passwords 112 to servers or other entities other than the client machine. A secure 113 aPAKE should provide the best possible security for a password 114 protocol, namely, it should only be open to inevitable attacks: 115 online impersonation attempts with guessed user passwords and offline 116 dictionary attacks upon the compromise of a server and leakage of its 117 password file. In the latter case, the attacker learns a mapping of 118 a user's password under a one-way function and uses such a mapping to 119 validate potential guesses for the password. Crucially important is 120 for the password protocol to use an unpredictable one-way mapping or 121 otherwise the attacker can pre-compute a deterministic list of mapped 122 passwords leading to almost instantaneous leakage of passwords upon 123 server compromise. 125 Quite surprisingly, in spite of the existence of multiple designs for 126 (PKI-free) aPAKE protocols, none of these protocols is secure against 127 pre-computation attacks. In particular, none of these protocols can 128 use the standard technique against pre-computation that combines 129 _secret_ random values ("salt") into the one-way password mappings. 130 Either these protocols do not use salt at all or, if they do, they 131 transmit the salt from server to user in the clear, hence losing the 132 secrecy of the salt and its defense against pre-computation. 133 Furthermore, the transmission of salt may incur additional protocol 134 messages. 136 This draft describes OPAQUE, a PKI-free secure aPAKE that is secure 137 against pre-computation attacks and capable of using secret salt. 138 OPAQUE has been recently defined and studied by Jarecki et al. 139 [OPAQUE] who prove the security of the protocol in a strong aPAKE 140 model that ensures security against pre-computation attacks and is 141 formulated in the Universal Composability (UC) framework [Canetti01] 142 under the random oracle model. In contrast, very few aPAKE protocols 143 have been proven formally and those proven were analyzed in a weak 144 security model that allows for pre-computation attacks (e.g., 145 [GMR06]). This is not just a formal issue: these protocols are 146 actually vulnerable to such attacks. This includes protocols that 147 have recent analyses in the UC model such as AuCPace [AuCPace] and 148 SPAKE2+ [SPAKE2plus]. We note that as shown in [OPAQUE], these 149 protocols, and any aPAKE in the model from [GMR06], can be converted 150 into an aPAKE secure against pre-computation attacks at the expense 151 of an additional OPRF execution. 153 It is worth noting that the currently most deployed (PKI-free) aPAKE 154 is SRP [RFC2945], which is open to pre-computation attacks, is 155 inefficient relative to OPAQUE. Moreover, SRP requires a ring as it 156 mixes addition and multiplication operations, and thus does not work 157 over plain elliptic curves. OPAQUE is therefore a suitable 158 replacement. 160 OPAQUE's design builds on a line of work initiated in the seminal 161 paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol 162 of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et 163 al. [JKKX16]. None of these papers considered security against pre- 164 computation attacks or presented a proof of aPAKE security (not even 165 in a weak model). 167 In addition to its proven resistance to pre-computation attacks, 168 OPAQUE's security features include forward secrecy (essential for 169 protecting past communications in case of password leakage) and the 170 ability to hide the password from the server - even during password 171 registration. Moreover, good performance and an array of additional 172 features make OPAQUE a natural candidate for practical use and for 173 adoption as a standard. Such features include the ability to 174 increase the difficulty of offline dictionary attacks via iterated 175 hashing or other hardening schemes, and offloading these operations 176 to the client (that also helps against online guessing attacks); 177 extensibility of the protocol to support storage and retrieval of 178 user's secrets solely based on a password; and being amenable to a 179 multi-server distributed implementation where offline dictionary 180 attacks are not possible without breaking into a threshold of servers 181 (such distributed solution requires no change or awareness on the 182 client side relative to a single-server implementation). 184 OPAQUE is defined and proven as the composition of two 185 functionalities: An Oblivious PRF (OPRF) and a key-exchange protocol. 186 It can be seen as a "compiler" for transforming any key-exchange 187 protocol (with KCI security and forward secrecy - see below) into a 188 secure aPAKE protocol. In OPAQUE, the user stores a secret private 189 key at the server during password registration and retrieves this key 190 each time it needs to authenticate to the server. The OPRF security 191 properties ensure that only the correct password can unlock the 192 private key while at the same time avoiding potential offline 193 guessing attacks. This general composability property provides great 194 flexibility and enables a variety of OPAQUE instantiations, from 195 optimized performance to integration with TLS. The latter aspect is 196 of prime importance as the use of OPAQUE with TLS constitutes a major 197 security improvement relative to the standard password-over-TLS 198 practice. At the same time, the combination with TLS builds OPAQUE 199 as a fully functional secure communications protocol and can help 200 provide privacy to account information sent by the user to the server 201 prior to authentication. 203 The KCI property required from KE protocols for use with OPAQUE 204 states that knowledge of a party's private key does not allow an 205 attacker to impersonate others to that party. This is an important 206 security property achieved by most public-key based KE protocols, 207 including protocols that use signatures or public key encryption for 208 authentication. It is also a property of many implicitly 209 authenticated protocols (e.g., HMQV) but not all of them. We also 210 note that key exchange protocols based on shared keys do not satisfy 211 the KCI requirement, hence they are not considered in the OPAQUE 212 setting. We note that KCI is needed to ensure a crucial property of 213 OPAQUE: even upon compromise of the server, the attacker cannot 214 impersonate the user to the server without first running an 215 exhaustive dictionary attack. Another essential requirement from KE 216 protocols for use in OPAQUE is to provide forward secrecy (against 217 active attackers). 219 This draft presents a high-level description of OPAQUE highlighting 220 its components and modular design. It also provides the basis for a 221 specification for standardization but a detailed specification ready 222 for implementation is beyond the current scope of this document 223 (which may be expanded in future revisions or done separately). 225 We describe OPAQUE with a specific instantiation of the OPRF 226 component over elliptic curves and with a few KE schemes, including 227 the HMQV [HMQV], 3DH [SIGNAL] and SIGMA [SIGMA] protocols. We also 228 present several strategies for integrating OPAQUE with TLS 1.3 229 [RFC8446] offering different tradeoffs between simplicity, 230 performance and user privacy. In general, the modularity of OPAQUE's 231 design makes it easy to integrate with additional key-exchange 232 protocols, e.g., IKEv2. 234 The computational cost of OPAQUE is determined by the cost of the 235 OPRF, the cost of a regular Diffie-Hellman exchange, and the cost of 236 authenticating such exchange. In our elliptic-curve implementation 237 of the OPRF, the cost for the client is two exponentiations (one or 238 two of which can be fixed base) and one hashing-into-curve operation 239 [I-D.irtf-cfrg-hash-to-curve]; for the server, it is just one 240 exponentiation. The cost of a Diffie-Hellman exchange is as usual 241 two exponentiations per party (one of which is fixed-base). Finally, 242 the cost of authentication per party depends on the specific KE 243 protocol: it is just 1/6 of an exponentiation with HMQV, two 244 exponentiations for 3DH, and it is one signature generation and 245 verification in the case of SIGMA and TLS 1.3. These instantiations 246 preserve the number of messages in the underlying KE protocol except 247 in one of the TLS instantiations where user privacy may require an 248 additional round trip. 250 1.1. Terminology 252 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 253 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 254 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 255 [RFC2119] 257 1.2. Notation 259 Throughout this document the first argument to a keyed function 260 represents the key; separated by a semicolon are the function inputs 261 typically implemented as an unambiguous concatenation of strings 262 (details of encodings are left for a future, more detailed 263 specification). 265 Except if said otherwise, random choices in this specification refer 266 to drawing with uniform distribution from a given set (i.e., "random" 267 is short for "uniformly random"). Random choices can be replaced 268 with fresh outputs from a cryptographically strong pseudorandom 269 generator or pseudorandom function. 271 The name OPAQUE: A homonym of O-PAKE where O is for Oblivious (the 272 name OPAKE was taken). 274 2. DH-OPRF 276 OPAQUE uses in a fundamental way an Oblivious Pseudo Random Function 277 (OPRF). 279 An Oblivious PRF (OPRF) is an interactive protocol between a server S 280 and a user U defined by a special pseudorandom function (PRF), 281 denoted F. The server's input to the protocol is a key k for PRF F 282 and the user's input is a value x in the domain of F. At the end of 283 the protocol, U learns F(k; x) and nothing else while S learns 284 nothing from the protocol execution (in particular nothing about x or 285 the value F(k; x)). 287 OPAQUE uses a specific OPRF instantiation, called DH-OPRF, where the 288 PRF, denoted F, is defined next, generically. 290 Parameters: Hash function H (e.g., SHA2 or SHA3 function) with 291 256-bit output at least, a cyclic group G of prime order q, a 292 generator g of G, and hash function H' mapping arbitrary strings into 293 G (where H' is modeled as a random oracle). 295 o DH-OPRF domain: Any string 297 o DH-OPRF range: The range of the hash function H 299 o DH-OPRF key: A random element k in [0..q-1] 301 o DH-OPRF Operation: F(k; x) = H(x, H'(x)^k) 303 Protocol for computing DH-OPRF, U with input x and S with input k: 305 o U: choose random r in [0..q-1], send alpha=H'(x)^r to S 307 o S: upon receiving a value alpha, respond with beta=alpha^k 309 o U: upon receiving beta set the PRF output to H(x, beta^{1/r}) 311 Received values alpha, beta are checked to be elements in G other 312 than the identity and the receiving party aborts if the check fails 313 (alternatively, co-factor exponentiation can be applied to the 314 received values). 316 Note (fixed-base blinding): An alternative way of computing DH-OPRF 317 is for U to choose random r in [0..q-1] and send alpha=H'(x)*g^r to 318 S, who responds with beta=alpha^k as well as with the value v=g^k 319 (that S may store together with k). U then sets the OPRF output F(k; 320 x) to H(x, beta*v^{-r}). This reduces the computation at U from two 321 variable-base exponentiations in the above protocol to one fixed-base 322 and one variable-base exponentiation. Moreover, if U stores g^k 323 (e.g., for servers to which it logins frequently), then the 324 computation takes two fixed-base exponentiations (with bases g and 325 g^k). The downside of fixed-base blinding is the need for the server 326 to store g^k and to sent it to the client, which is otherwise not 327 necessary. Applications can choose any of the blinding options as 328 both compute the same function. 330 We note that prior versions of this document defined the OPRF to 331 include g^k under the hash function H in order to provide security 332 for fixed-base blinding. However, [Blinding] proved recently that 333 fixed-base blinding is secure also without hashing g^k. 335 2.1. DH-OPRF instantiation and detailed specification 337 The above description of DH-OPRF is generic and applicable to any 338 cyclic group. Detailed specification for concrete implementations of 339 DH-OPRF can be found in [I-D.irtf-cfrg-voprf] which defines several 340 instantiation suites for DH-OPRF, including the choice of hash-to- 341 curve functions (denoted H' above) as detailed in 342 [I-D.irtf-cfrg-hash-to-curve]. OPAQUE will adopt some of these 343 instantiation suites and their underlying elliptic curves. The 344 latter will determine implementation details for such curves 345 including ways to check curve membership, the suitability of co- 346 factor mechanisms, etc. 348 2.2. Hardening OPRF via user iterations 350 Protocol OPAQUE is strengthened against offline dictionary attacks by 351 applying to the output of DH-OPRF a hardening procedure such as via 352 repeated iterations, memory hard operations, etc. This greatly 353 increases the cost of an offline attack upon the compromise of the 354 password file at the server. For this purpose, we define the 355 extended DH-OPRF F* as 356 F*(k; x) = I^n( H(x, H'(x)^k) ) where I is a hardening function and n 357 is a measure of hardness. For example, I can represent the iterative 358 function of PBKDF2 [RFC8018] and n the number of iterations; in the 359 case of memory-hard functions such as Argon2 [I-D.irtf-cfrg-argon2] 360 and scrypt [RFC7914], I is a more involved memory-hard function and n 361 measures cost factors and other parameters. 363 Parameters to the hardening function can be set to public values or 364 set at the time of password registration and stored at the server. 365 In this case, the server communicates these parameters to the user 366 during OPAQUE executions together with the second OPRF message. We 367 note that the salt value typically input into the KDF can be set to a 368 constant, e.g., all zeros. 370 3. OPAQUE Specification 372 OPAQUE consists of the concurrent run of an OPRF protocol and a key- 373 exchange protocol KE (one that provides mutual authentication based 374 on public keys and satisfies the KCI requirement discussed in the 375 introduction). We first define OPAQUE in a generic way based on any 376 OPRF and any PK-based KE, and later show specific instantiation using 377 DH-OPRF (defined in Section 2) and several KE protocols. The user, 378 running on a client machine, takes the role of initiator in these 379 protocols and the server the responder's. The private-public keys 380 for the user are denoted PrivU and PubU, and for the server PrivS and 381 PubS. 383 3.1. Password registration 385 Password registration is executed between a user U (running on a 386 client machine) and a server S. It is assumed the server can 387 identify the user and the client can authenticate the server during 388 this registration phase. This is the only part in OPAQUE that 389 requires an authenticated channel, either physical, out-of-band, PKI- 390 based, etc. 392 o U chooses password PwdU and a pair of private-public keys PrivU 393 and PubU for the given protocol KE. 395 o S chooses OPRF key kU (random and independent for each user), 396 chooses its own pair of private-public keys PrivS and PubS for use 397 with protocol KE (S can use the same pair of keys with multiple 398 users), and sends PubS to the client. 400 o Client and S run the OPRF F(kU; PwdU) as defined in Section 2 with 401 only the client learning the result. The client then applies a 402 hardening function, as described in Section 2.2, to this result 403 obtaining a value denoted RwdU (for "Randomized PwdU"). The 404 parameters of the hardening function can be public and known to 405 client machines or they can be stored by S and communicated to the 406 client during registration and login sessions. 408 o Client generates an "envelope" EnvU that contains PrivU and PubS 409 protected under RwdU. PrivU is encrypted and authenticated while 410 PubS is authenticated and optionally encrypted. EnvU may also 411 include the user's public key and parties' identities. 413 EnvU can be thought of as an authenticated encryption scheme with 414 optional authenticated-only data. However, for technical reasons, 415 not all authenticated encryption schemes can be used for building 416 EnvU, therefore we provide a precise specification of the 417 enveloping function in Section 4. 419 o The client sends EnvU and PubU to S and erases PwdU, RwdU and all 420 keys. S stores (EnvU, PubS, PrivS, PubU, kU) in a user-specific 421 record. If PrivS and PubS are used for multiple users, S can 422 store these values separately and omit them from the user's 423 record. 425 Note (salt). We note that in OPAQUE the OPRF key acts as the secret 426 salt value that ensures the infeasibility of pre-computation attacks. 427 No extra salt value is needed. 429 Note (password rules). The above procedure has the significant 430 advantage that the user's password is never disclosed to the server 431 even during registration. Some sites require learning the user's 432 password for enforcing password rules. Doing so voids this important 433 security property of OPAQUE and is not recommended. Moving the 434 password check procedure to the client side is a more secure 435 alternative (limited checks at the server are possible to implement, 436 e.g., detecting repeated passwords). 438 3.2. Online OPAQUE protocol (Login and key exchange)) 440 After registration, the user (through a client machine) and server 441 can run the OPAQUE protocol as a password-authenticated key exchange. 442 The protocol proceeds as follows: 444 o Client transmits user/account information to the server so that 445 the server can retrieve the user's record. 447 o Server and client execute the OPRF protocol as defined in 448 Section 2; client sets RwdU to the result of this computation (if 449 this computation includes a hardening function as in Section 2.2, 450 the parameters of this function are either known to the client or 451 communicated by the server). 453 o Server sends EnvU to client. 455 o Client authenticates/decrypts EnvU using RwdU to obtain PrivU, 456 PubU, PubS. If authentication fails, client aborts. 458 o Client and server run the specified KE protocol using their 459 respective public and private keys. 461 Note that the steps preceding the run of KE can be arranged in just 462 two messages (one from the client and a response from the server). 463 Furthermore, OPAQUE is optimized by running the OPRF and KE 464 concurrently with interleaved and combined messages (while preserving 465 the internal ordering of messages in each protocol). In all cases, 466 the client needs to obtain EnvU and RwdU (i.e., complete the OPRF 467 protocol) before it can use its own private key PrivU and the 468 server's public key PubS in the run of KE. 470 3.3. Parties' identities 472 Authenticated key-exchange protocols generate keys that need to be 473 uniquely and verifiably bound to a pair of identities, in the case of 474 OPAQUE a user and a server. Thus, it is essential for the parties to 475 agree on such identities, including an agreed bit representation of 476 these identities as needed, for example, when inputting identities to 477 a key derivation function. When referring to identities IdU and IdS 478 in this document, we refer to such agreed identities. Applications 479 may have different policies about how and when identities are 480 determined. A natural approach is to tie IdU to the identity the 481 server uses to fetch EnvU (hence determined during password 482 registration) and to tie IdS to the server identity used by the 483 client to initiate a password registration or login sessions. IdS 484 and IdU can also be part of EnvU or be tied to the parties' public 485 keys. In principle, it is possible that identities change across 486 different sessions as long as there is a policy that can establish if 487 the identity is acceptable or not to the peer. However, we note that 488 the public keys of both the server and the user must always be those 489 defined at time of password registration. 491 4. Specification of the EnvU envelope 493 In Section 3.1, EnvU was defined as an envelope containing the user's 494 private key PrivU and server's public key PubS protected under RwdU. 495 Optionally, EnvU may also contain PubU and identities IdS, IdU. Part 496 of this information, e.g., PrivU, requires secrecy and authentication 497 while other values may only need authentication. A natural way to 498 build EnvU is using authenticated encryption with additional 499 authenticated data. However, as proven in [OPAQUE], the security of 500 OPAQUE requires the authenticated encryption scheme, AuthEnc, used to 501 build EnvU to satisfy the property of "random-key robustness". That 502 is, given a pair of random AuthEnc keys, it should be infeasible to 503 create an authenticated ciphertext that successfully decrypts (i.e., 504 passes authentication) under the two keys. Some natural AuthEnc 505 schemes, including GCM, do not satisfy this property and therefore, 506 here we specify a particular scheme for implementing EnvU that enjoys 507 this property. It is based on counter-mode encryption and HMAC. 509 We define EnvU on the basis of two fields, AEenv and AOenv, one of 510 which (but not both) can be empty. AEenv contains information that 511 needs to be protected under authenticated encryption while AOenv only 512 requires authentication. Typically, AEenv includes PrivU, and AOenv 513 includes PubS and possibly PubU (PubU may be omitted if not needed 514 for running the user side of the key exchange, or if it is re- 515 computed by the client on the basis of PrivU). On the other hand, 516 some applications may want to hide the public key(s) from 517 eavesdroppers in which case these keys would go under AEenv. As 518 noted below, there is also the possibility of omitting PrivU from 519 EnvU and derive it from RwdU in which case AEenv may be empty. In 520 all cases, EnvU must include the authenticated PubS, either under 521 AEenv or AOenv. Additionally, EnvU may be used to transmit the user 522 and/or server identities (see Section 3.3). 524 EnvU is built by encrypting AEenv (if not empty), concatenating to it 525 AOenv (if not empty), and computing HMAC on the concatenation (which 526 must never be empty). HMAC must use a hash of length 256 bits or 527 more to ensure collision resistance. For the benefit of 528 interoperability we specify the use of a block cipher (AES256) in 529 counter mode as the encryption function, however, any secure (not 530 necessarily authenticated) encryption scheme can be used for the 531 encryption of AEenv. HMAC can also be replaced but only by a 532 collision resistant MAC (not all MAC functions are collision 533 resistant!) 535 We start by defining the key derivation function to derive three 536 keys: a HMAC key HMACkey, an AES256 key EncKey and a third key KdKey 537 for applications that choose to process user information beyond the 538 OPAQUE functionality (e.g., additional secrets or credentials). We 539 specify KdKey to be of the same length as HMACkey so it can be used, 540 if needed, with HKDF-Expand. 542 Let L1, L2, L3 be the lengths in octets of HmacKey, EncKey and KdKey, 543 respectively, where L3=L1. If any one of EncKey or KdKey is omitted, 544 its length is set to 0. We define: 546 KEYS = HKDF(salt=0, IKM=RwdU, info="EnvU", Length=L1+L2+L3) 548 and set HmacKey to the most significant L1 bytes of KEYS, EncKey to 549 the next significant L2 bytes, and KdKey to the next L3 bytes. (For 550 AES256 and HMAC-SHA256, the keys are of length 32 bytes each.) 552 We define EnvU to be the concatenation of E and the authentication 553 tag HMAC(HmacKey; E) where E is the concatenation of AES-CTR(EncKey; 554 AEenv) and AOenv. 556 Recall that EnvU is computed during password registration and is 557 decrypted by the client during login. Decryption proceeds by 558 deriving HmacKey and EncKey, verifying the HMAC tag, and if this is 559 successful, decrypting E. If HMAC verification fails, the session is 560 aborted. 562 [[TODO: More precise specification needed here, such as default order 563 of elements, their encodings, etc.]] 565 In this specification, encryption of AEenv uses AES256 in counter 566 mode with key EncKey and an initial counter value (that is part of 567 the ciphertext) defined as the concatenation of a random 8-byte nonce 568 chosen by the encrypting party (i.e., the client during password 569 registration) and an 8-byte representation of 1 (7 zero bytes 570 followed by 0x01). We refer to this initial value as CTRBASE. 572 For completeness, we specify AES-CTR in Appendix A. 574 [[TODO: If an RFC defining this mode exists, we should refer to it 575 instead. The mode is defined in [RFC3686] but in the context of 576 IPsec's ESP, so having a distilled version as in the Appendix may be 577 worthwhile, particularly as we use a different initial value (the 578 above RFC assumes a given IV which we do not have here).]] 580 Note (rationale of CTRBASE): The nonce used in defining CTRBASE is 581 needed, for example, for the case where a user registers the same 582 password repeatedly, choosing a fresh PrivU each time while the value 583 of the server's OPRF key kU stays fixed. This results in the same 584 encryption key but different plaintexts which requires a changing 585 nonce. Eight bytes are more than enough for this. 587 Note (using GCM): Can one replace AES-CTR with GCM-AES for encrypting 588 AEenv? Yes, as long as one keeps the HMAC authentication. As said, 589 any secure encryption can be used for encrypting AEenv. However, GCM 590 also produces an authentication tag that is not needed here. As a 591 result, using GCM may tempt someone to drop the HMAC authentication 592 which would be insecure since standalone GCM is not random-key 593 robust. For this reason it may be better not to replace plain AES- 594 CTR with GCM or any other authenticated encryption. 596 Note (storage/communication efficient authentication-only EnvU): It 597 is possible to dispense with encryption in the construction of EnvU 598 to obtain a shorter EnvU (resulting in less storage at the server and 599 less communication from server to client). The idea is to derive 600 PrivU from RwdU. However, for cases where PrivU is not a random 601 string of a given length, we define a more general procedure. 602 Namely, what's derived from RwdU is a random seed used as an input to 603 a key generation procedure that generates the pair (PrivU, PubU). In 604 this case, AEenv is empty and AOenv contains PubS. The random key 605 generation seed is defined as HKDF-Expand(KdKey; info="KG seed", L) 606 where L is the required seed length. We note that in this 607 encryption-less scheme, the authentication still needs to be random- 608 key robust which HMAC satisfies. 610 To further minimize storage space, the server can derive per-user 611 OPRF keys kU from a single global secret key, and it can use the same 612 pair (PrivS,PubS) for all users. In this case, the per-user OPAQUE 613 storage consists of PubU and HMAC(Khmac; Pubs), a total of 64-byte 614 overhead with a 256-bit curve and hash. EnvU communicated to the 615 user is of the same length, consisting of PubS and HMAC(Khmac; Pubs). 617 5. OPAQUE Instantiations 619 We present several instantiations of OPAQUE using DH-OPRF and 620 different KE protocols. For the sake of concreteness we focus on KE 621 protocols consisting of three messages, denoted KE1, KE2, KE3, and 622 such that KE1 and KE2 include DH values sent by user and server, 623 respectively, and KE3 provides explicit user authentication. As 624 shown in [OPAQUE], OPAQUE cannot use less than three messages so the 625 3-message instantiations presented here are optimal in terms of 626 number of messages. On the other hand, there is no impediment of 627 using OPAQUE with protocols with more than 3 messages as in the case 628 of IKEv2 (or the underlying SIGMA-R protocol [SIGMA]). 630 OPAQUE generic outline with 3-message KE: 632 o C to S: IdU, alpha=H'(PwdU)^r, KE1 634 o S to C: beta=alpha^kU, EnvU, KE2 636 o C to S: KE3 638 Key derivation and other details of the protocol are specified by the 639 KE scheme. We do note that by the results in [OPAQUE], KE2 and KE3 640 should include authentication of the OPRF messages (or at least of 641 the value alpha) for binding between the OPRF run and the KE session. 643 Next, we present three instantiations of OPAQUE - with HMQV, 3DH and 644 SIGMA-I. In Section 6 we discuss integration with TLS 1.3 [RFC8446]. 646 5.1. Instantiation of OPAQUE with HMQV and 3DH 648 The integration of OPAQUE with HMQV [HMQV] leads to the most 649 efficient instantiation of OPAQUE in terms of exponentiations count. 650 Performance is close to optimal due to the low cost of authentication 651 in HMQV: Just 1/6 of an exponentiation for each party over the cost 652 of a regular DH exchange. However, HMQV is encumbered by an IBM 653 patent, hence we also present OPAQUE with 3DH which only differs in 654 the key derivation function at the cost of an extra exponentiation 655 (and less resilience to the compromise of ephemeral exponents). We 656 note that 3DH serves as a basis for the key-exchange protocol of 657 [SIGNAL]. 659 Importantly, many other protocols follow a similar format with 660 differences mainly in the key derivation function. This includes the 661 Noise family of protocols. Extension may also apply to KEM-based KE 662 protocols as in many post-quantum candidates. 664 The private and public keys of the parties in these examples are 665 Diffie-Hellman keys, namely, PubU=g^PrivU and PubS=g^PrivS. 667 Specification/implementation details that are specific to the choice 668 of group G will be adapted from the corresponding standards for 669 different elliptic curves. 671 PROTOCOL MESSAGES. OPAQUE with HMQV and OPAQUE with 3DH comprises: 673 o KE1 = OPRF1, nonceU, info1*, IdU*, ePubU 675 o KE2 = OPRF2, EnvU, nonceS, info2*, ePubS, Einfo2*, Mac(Km3; 676 xcript2), 678 o KE3 = info3*, Einfo3*, Mac(Km3; xcript3)} 680 where: 682 o * denotes optional elements; 684 o OPRF1, OPRF2 denote the DH-OPRF values alpha, beta sent by user 685 and server, respectively, as defined in Section 2; 687 o EnvU is the OPAQUE's envelope stored by the server containing 688 keying information for the client to run the AKE with the server; 690 o nonceU, nonceS are fresh random nonces chosen by client and 691 server, respectively; 693 o info1, info2, info3 denote optional application-specific 694 information sent in the clear (e.g., they can include parameter 695 negotiation, parameters for a hardening function, etc.); 697 o Einfo2, Einfo3 denotes optional application-specific information 698 sent encrypted under keys Ke2, Ke3 defined below; 700 o IdU is the user's identity used by the server to fetch the 701 corresponding user record, including EnvU, OPRF key, etc. (it can 702 be omitted from message KE1 if the information is available to the 703 server in some other way); 705 o IdS, the server's identity, is not shown explicitly, it can be 706 part of an info field (encrypted or not), part of EnvU, or can be 707 known from other context (see Section 3.3); it is used crucially 708 for key derivation (see below); 710 o ePubU, ePubS are Diffie-Hellman ephemeral public keys chosen by 711 user and server, respectively; 713 o xcript2 includes the concatenation of the values OPRF1, nonceU, 714 info1*, IdU*, ePubU, OPRF2, EnvU, nonceS, info2*, ePubS, Einfo2*; 716 o xscript3 includes the concatenation of all elements in xscript2 717 followed by info3*, Einfo3*; 719 Notes: 721 o The explicit concatenation of elements under xscript2 and xscript3 722 can be replaced with hashed values of these elements, or their 723 combinations, using a collision-resistant hash (e.g., as in the 724 transcript-hash of TLS 1.3). 726 o The inclusion of the values OPRF1 and OPRF2 under xscript2 is 727 needed for binding the OPRF execution to that of the KE session. 728 On the other hand, including EnvU in xscript2 is not mandatory. 730 o The ephemeral keys ePubU, ePubS, can be exchanged prior to the 731 above 3 messages, e.g., when running these protocols under TLS 732 1.3. 734 [[TODO: Specify that in the login phase, ephemeral DH values need to 735 be verified to belong to the correct group (via membership tests or 736 cofactor exponentiation). Same hold for public keys during the 737 registration phase. Details of verification depend on the particular 738 group/curve.]] 740 KEY DERIVATION. The above protocol requires MAC keys Km2, Km3, and 741 optional encryption keys Ke2, Ke3, as well as generating a session 742 key SK which is the AKE output for protecting subsequent traffic (or 743 for generating further key material). Key derivation uses HKDF 744 [RFC5869] with a combination of the parties static and ephemeral 745 private-public key pairs and the parties' identities IdU, IdS. See 746 Section 3.3. 748 SK, Km2, Km3, Ke2, Ke3 = HKDF(salt=0, IKM, info, L) 750 where L is the sum of lengths of SK, Km2, Km3, Ke2, Ke3, and SK gets 751 the most significant bytes of the HKDF output, Km2 the next bytes, 752 etc. 754 Values IKM and info are defined for each protocol: 756 For HMQV: 758 o info = "HMQV keys" | nonceU | nonceS | IdU | IdS 760 o IKM = Khmqv 762 where Khmqv is computed: 764 * by the client: Khmqv = (ePubS * PubS^s)^{ePrivU + u*PrivU} 766 * by the server: Khmqv = (ePubU * PubU^u)^{ePrivS + s*PrivS} 767 and u = H(ePubU | "user" | info); s = H(ePubS | "srvr" | info). 769 FOR 3DH: 771 o info = "3DH keys" | nonceU | nonceS | IdU | IdS 773 o IKM = K3dh 775 where K3dh is the concatenation of three DH values computed: 777 * by the client: K3dh = ePubS^ePrivU | PubS^ePrivU | ePubS^PrivU 779 * by the server: K3dh = ePubU^ePrivS | ePubU^PrivS | PubU^ePrivS 781 5.2. Instantiation of OPAQUE with SIGMA-I 783 We show how OPAQUE is built around the 3-message SIGMA-I protocol 784 [SIGMA]. This is an example of a signature-based protocol and also 785 serves as a basis for integration of OPAQUE with TLS 1.3, as the 786 latter follows the design of SIGMA-I (see Section 6. This 787 specification can be extended to the 4-message SIGMA-R protocol as 788 used in IKEv2. 790 PROTOCOL MESSAGES. OPAQUE with SIGMA-I comprises: 792 o KE1 = OPRF1, nonceU, info1*, IdU*, ePubU 794 o KE2 = OPRF2, EnvU, nonceS, info2*, ePubS, Einfo2*, Sign(PrivS; 795 xcript2-), Mac(Km2; IdU), 797 o KE3 = info3*, Einfo3*, Sign(PrivU; xcript3-), Mac(Km3; IdS)} 799 See explanation of fields above. In addition, for the signed 800 material, xscript2- is defined similarly to xscript2, however if 801 xscript2 includes information that identifies the user, such 802 information can be eliminated in xscript2- (this is advised if 803 signing user's identification information by the server is deemed to 804 have adverse privacy consequences). In SIGMA, including the peer's 805 identity under the MAC is necessary and sufficient for security, but 806 including it under the signature is not necessary. Similarly, 807 xscript3- is defined as xcript3 with server identification 808 information removed if so desired. 810 KEY DERIVATION. Key in SIGMA-I are derived as 812 SK, Km2, Km3, Ke2, Ke3 = HKDF(salt=0, IKM, info, L) 814 where 815 o L is the sum of lengths of SK, Km2, Km3, Ke2, Ke3, and SK gets the 816 most significant bytes of the HKDF output, Km2 the next bytes, 817 etc., 819 o info = "SIGMA-I keys" | nonceU | nonceS | IdU | IdS 821 o IKM = Ksigma 823 and Ksigma is computed: 825 * by the client: Ksigma = ePubS^ePrivU 827 * by the server: Ksigma = ePubU^ePrivS 829 6. Integrating OPAQUE with TLS 1.3 831 This section is intended as a discussion of ways to integrate OPAQUE 832 with TLS 1.3. Precise protocol details are left for a future 833 separate specification. A very preliminary draft is 834 [I-D.sullivan-tls-opaque]. 836 As stated in the introduction, the security of the standard password- 837 over-TLS mechanism for password authentication suffers from its 838 essential reliance on PKI and the exposure of passwords to the server 839 (and possibly others) upon TLS decryption. Integrating OPAQUE with 840 TLS removes these vulnerabilities while at the same time it armors 841 TLS itself against PKI failures. Such integration also benefits 842 OPAQUE by leveraging the standardized negotiation and record-layer 843 security of TLS. Furthermore, TLS offers an initial PKI- 844 authenticated channel to protect the privacy of account information 845 such as user name transmitted between client and server. 847 If one is willing to forgo protection of user account information 848 transmitted between user and server, integrating OPAQUE with TLS 1.3 849 is relatively straightforward and follows essentially the same 850 approach as with SIGMA-I in Section 5.2. Specifically, one reuses 851 the Diffie-Hellman exchange from TLS and uses the user's private key 852 PrivU retrieved from the server as a signature key for TLS client 853 authentication. The integrated protocol will have as its first 854 message the TLS's Client Hello augmented with user account 855 information and with the DH-OPRF first message (the value alpha). 856 The server's response includes the regular TLS 1.3 second flight 857 augmented with the second OPRF message which includes the values beta 858 and EnvU. For its TLS signature, the server uses the private key 859 PrivS whose corresponding public key PubS is authenticated as part of 860 the user envelope EnvU (there is no need to send a regular TLS 861 certificate in this case). Finally, the third flight consists of the 862 standard client Finish message with client authentication where the 863 client's signature is produced with the user's private key PrivU 864 retrieved from EnvU and verified by the server using public key PubU. 866 The above scheme is depicted in Figure 1 where the sign + indicates 867 fields added by OPAQUE, and OPRF1, OPRF2 denote the two DH-OPRF 868 messages. Other messages in the figure are the same as in TLS 1.3. 869 Notation {...} indicates encryption under handshake keys. Note that 870 ServerSignature and ClientSignature are performed with the private 871 keys defined by OPAQUE and they replace signatures by traditional TLS 872 certificates. 874 Client Server 876 ClientHello 877 key_share 878 + userid + OPRF1 --------> 879 ServerHello 880 key_share 881 {+ OPRF2 + EnvU} 882 {ServerSignature} 883 <-------- {ServerFinished} 885 {ClientSignature} 886 {ClientFinished} --------> 888 Figure 1: Integration of OPAQUE in TLS 1.3 (no userid 889 confidentiality) 891 Note that in order to send OPRF1 in the first message, the client 892 needs to know the DH group the server uses for OPRF, or it needs to 893 "guess" it. This issue already appears in TLS 1.3 where the client 894 needs to guess the key_share group and it should be handled similarly 895 in OPAQUE (e.g., the client may try one or more groups in its first 896 message). 898 Protection of user's account information can be added through TLS 1.3 899 pre-shared/resumption mechanisms where the account information 900 appended to the ClientHello message would be encrypted under the pre- 901 shared key. 903 When a resumable session or pre-shared key between the client and the 904 server do not exist, user account protection requires a server 905 certificate. One option that does not add round trips is to use a 906 mechanism similar to the proposed ESNI extension [I-D.ietf-tls-esni] 907 or a semi-static TLS exchange as in [I-D.ietf-tls-semistatic-dh]. 908 Without such extensions, one would run a TLS 1.3 handshake augmented 909 with the two first OPAQUE messages interleaved between the second and 910 third flight of the regular TLS handshake. That is, the protocol 911 consists of five flights as follows: (i) A regular 2-flight 1-RTT 912 handshake to produce handshake traffic keys authenticated by the 913 server's TLS certificate; (ii) two OPAQUE messages that include user 914 identification information, the DH-OPRF messages exchanged between 915 client and server, and the retrieved EnvU, all encrypted under the 916 handshake traffic keys (thus providing privacy to user account 917 information); (iii) the TLS 1.3 client authentication flight where 918 client authentication uses the user's private signature key PrivU 919 retrieved from the server in step (ii). 921 Note that server authentication in step (i) uses TLS certificates 922 hence PKI is used for user account privacy but not for user 923 authentication or other purposes. (In some applications, PKI may be 924 trusted also for server authentication in which case server 925 authentication through OPAQUE may be forgone). In OPAQUE the server 926 authenticates using the private key PrivS whose corresponding public 927 key PubS is sent to the user as part of EnvU. There are two options: 928 If PubS is the same as the public key the server used in the 1-RTT 929 authentication (step (i)) then there is no need for further 930 authentication. Otherwise, the server needs to send a signature 931 under PrivS that is piggybacked to the second OPAQUE message in (ii). 932 In this case, the signature would cover the running transcript hash 933 as is standard in TLS 1.3. The client signature in the last message 934 also covers the transcript hash including the regular handshake and 935 OPAQUE messages. 937 The described scheme is depicted in Figure 2. Please refer to the 938 text before Figure 1 describing notation. Note the asterisk in the 939 ServerSignature message. This indicates that this message is 940 optional as it is used only if the server's key PubS in OPAQUE is 941 different than the one in the server's certificate (transmitted in 942 the second protocol flight). 944 Client Server 946 ClientHello 947 key_share --------> 948 ServerHello 949 key_share 950 {Certificate} 951 {CertificateVerify} 952 <-------- {ServerFinished} 954 {+ userid + OPRF1} --------> 956 {+ OPRF2 + EnvU} 957 <-------- {+ ServerSignature*} 959 {ClientSignature} 960 {ClientFinished} --------> 962 Figure 2: Integration of OPAQUE in TLS 1.3 (with userid 963 confidentiality) 965 We note that the above approaches for integration of OPAQUE with TLS 966 may benefit from the post-handshake client authentication mechanism 967 of TLS 1.3 and the exported authenticators from 968 [I-D.ietf-tls-exported-authenticator]. Also, formatting of messages 969 and negotiation information suggested in [I-D.barnes-tls-pake] can be 970 used in the OPAQUE setting. 972 7. User enumeration 974 User enumeration refers to attacks where the attacker tries to learn 975 whether a given user identity is registered with a server. 976 Preventing such attack requires the server to act with unknown user 977 identities in a way that is indistinguishable from its behavior with 978 existing users. Here we suggest a way to implement such defense, 979 namely, a way for simulating the values beta and EnvU for non- 980 existing users. Note that if the same pair of user identity IdU and 981 value alpha is received twice by the server, the response needs to be 982 the same in both cases (since this would be the case for real users). 983 For protection against this attack, one would apply the encryption 984 function in the construction of EnvU (Section 4) to all the key 985 material in EnvU, namely, AOenv will be empty. The server S will 986 have two keys MK, MK' for a PRF f (this refers to a regular PRF such 987 as HMAC or CMAC). Upon receiving a pair of user identity IdU and 988 value alpha for a non-existing user IdU, S computes kU=f(MK; IdU) and 989 kU'=f(MK'; IdU) and responds with values beta=alpha^kU and EnvU, 990 where the latter is computed as follows. RwdU is set to kU' and 991 AEenv is set to the all-zero string (of the length of a regular EnvU 992 plaintext). Care needs to be taken to avoid side channel leakage 993 (e.g., timing) from helping differentiate these operations from a 994 regular server response. The above requires changes to the server- 995 side implementation but not to the protocol itself or the client 996 side. 998 There is one form of leakage that the above allows and whose 999 prevention would require a change in OPAQUE. Note that an attacker 1000 that tests a IdU (and same alpha) twice and receives different 1001 responses can conclude that either the user registered with the 1002 service between these two activations or that the user was registered 1003 before but changed its password in between the activations (assuming 1004 the server changes kU at the time of a password change). In any 1005 case, this indicates that IdU is a registered user at the time of the 1006 second activation. To conceal this information, S can implement the 1007 derivation of kU as kU=f(MK; IdU) also for registered users. Hiding 1008 changes in EnvU, however, requires a change in the protocol. Instead 1009 of sending EnvU as is, S would send an encryption of EnvU under a key 1010 that the user derives from the OPRF result (similarly to RwdU) and 1011 that S stores during password registration. During login, the user 1012 will derive this key from the OPRF result, will use it to decrypt 1013 EnvU, and continue with the regular protocol. If S uses a randomized 1014 encryption, the encrypted EnvU will look each time as a fresh random 1015 string, hence S can simulate the encrypted EnvU also for non-existing 1016 users. 1018 Note that the first case above does not change the protocol so its 1019 implementation is a server's decision (the client side is not 1020 changed). The second case, requires changes on the client side so it 1021 changes OPAQUE itself. 1022 [[TODO: Should this variant be documented/standardized?]] 1024 8. Security considerations 1026 This is an early draft presenting the OPAQUE concept and its 1027 potential instantiations. More precise details and security 1028 considerations will be provided in future drafts. We note that the 1029 security of OPAQUE is formally proved in [OPAQUE] under a strong 1030 model of aPAKE security assuming the security of the OPRF function 1031 and of the underlying key-exchange protocol. In turn, the security 1032 of DH-OPRF is proven in the random oracle model under the One-More 1033 Diffie-Hellman assumption [JKKX16]. 1035 Best practices regarding implementation of cryptographic schemes 1036 apply to OPAQUE. Particular care needs to be given to the 1037 implementation of the OPRF regarding testing group membership and 1038 avoiding timing and other side channel leakage in the hash-to-curve 1039 mapping. Drafts [I-D.irtf-cfrg-hash-to-curve] and 1041 [I-D.irtf-cfrg-voprf] have detailed instantiation and implementation 1042 guidance. 1044 While one can expect the practical security of the OPRF function 1045 (namely, the hardness of computing the function without knowing the 1046 key) to be in the order of computing discrete logarithms or solving 1047 Diffie-Hellman, Brown and Gallant [BG04] and Cheon [Cheon06] show an 1048 attack that slightly improves on generic attacks. For the case that 1049 q-1 or q+1, where q is the order of the group G, has a t-bit divisor, 1050 they show an attack that calls the OPRF on 2^t chosen inputs and 1051 reduces security by t/2 bits, i.e., it can find the OPRF key in time 1052 2^{q/2-t/2} and 2^{q/2-t/2} memory. For typical curves, the attack 1053 requires an infeasible number of calls and/or results in 1054 insignificant security loss (*). Moreover, in the OPAQUE 1055 application, these attacks are completely impractical as the number 1056 of calls to the function translates to an equal number of failed 1057 authentication attempts by a _single_ user. For example, one would 1058 need a billion impersonation attempts to reduce security by 15 bits 1059 and a trillion to reduce it by 20 bits - and most curves will not 1060 even allow for such attacks in the first place (note that this 1061 theoretical loss of security is with respect to computing discrete 1062 logarithms, not in reducing the password strength). 1064 (*) Some examples (courtesy of Dan Brown): For P-384, 2^90 calls 1065 reduce security from 192 to 147 bits; for NIST P-256 the options are 1066 6-bit reduction with 2153 OPRF calls, about 14 bit reduction with 187 1067 million calls and 20 bits with a trillion calls. For Curve25519, 1068 attacks are completely infeasible (require over 2^100 calls) but its 1069 twist form allows an attack with 25759 calls that reduces security by 1070 7 bits and one with 117223 calls that reduces security by 8.4 bits. 1072 Note on user authentication vs. authenticated key exchange. OPAQUE 1073 provides PAKE (password-based authenticated key exchange) 1074 functionality in the client-server setting. While in the case of 1075 user identification, focus is often on the authentication part, we 1076 stress that the key exchange element is not less crucial. Indeed, in 1077 most cases user authentication is performed to enforce some policy, 1078 and the key exchange part is essential for binding this enforcement 1079 to the authentication step. Skipping the key exchange part is 1080 analogous to carefully checking a visitor's credential at the door 1081 and then leaving the door open for others to enter freely. 1083 This draft complies with the requirements for PAKE protocols set 1084 forth in [RFC8125]. 1086 9. References 1088 9.1. Normative References 1090 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1091 Requirement Levels", BCP 14, RFC 2119, 1092 DOI 10.17487/RFC2119, March 1997, 1093 . 1095 9.2. Informative References 1097 [AuCPace] Haase, B. and B. Labrique, "AuCPace: Efficient verifier- 1098 based PAKE protocol tailored for the IIoT", 1099 http://eprint.iacr.org/2018/286 , 2018. 1101 [BG04] Brown, D. and R. Galant, "The static Diffie-Hellman 1102 problem", http://eprint.iacr.org/2004/306 , 2004. 1104 [Blinding] 1105 Jarecki, S., Krawczyk, H., and J. Xu, "Multiplicative DH- 1106 OPRF and Its Applications to Password Protocols", 1107 Manuscript , 2020. 1109 [Boyen09] Boyen, X., "HPAKE: Password authentication secure against 1110 cross-site user impersonation", Cryptology and Network 1111 Security (CANS) , 2009. 1113 [Canetti01] 1114 Canetti, R., "Universally composable security: A new 1115 paradigm for cryptographic protocols", IEEE Symposium on 1116 Foundations of Computer Science (FOCS) , 2001. 1118 [Cheon06] Cheon, J., "Security analysis of the strong Diffie-Hellman 1119 problem", Euroctypt 2006 , 2006. 1121 [FK00] Ford, W. and B. Kaliski, Jr, "Server-assisted generation 1122 of a strong secret from a password", WETICE , 2000. 1124 [GMR06] Gentry, C., MacKenzie, P., and . Z, Ramzan, "A method for 1125 making password-based key exchange resilient to server 1126 compromise", CRYPTO , 2006. 1128 [HMQV] Krawczyk, H., "HMQV: A high-performance secure Diffie- 1129 Hellman protocol", CRYPTO , 2005. 1131 [I-D.barnes-tls-pake] 1132 Barnes, R. and O. Friel, "Usage of PAKE with TLS 1.3", 1133 draft-barnes-tls-pake-04 (work in progress), July 2018. 1135 [I-D.ietf-tls-esni] 1136 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 1137 "Encrypted Server Name Indication for TLS 1.3", draft- 1138 ietf-tls-esni-06 (work in progress), March 2020. 1140 [I-D.ietf-tls-exported-authenticator] 1141 Sullivan, N., "Exported Authenticators in TLS", draft- 1142 ietf-tls-exported-authenticator-12 (work in progress), May 1143 2020. 1145 [I-D.ietf-tls-semistatic-dh] 1146 Rescorla, E., Sullivan, N., and C. Wood, "Semi-Static 1147 Diffie-Hellman Key Establishment for TLS 1.3", draft-ietf- 1148 tls-semistatic-dh-01 (work in progress), March 2020. 1150 [I-D.irtf-cfrg-argon2] 1151 Biryukov, A., Dinu, D., Khovratovich, D., and S. 1152 Josefsson, "The memory-hard Argon2 password hash and 1153 proof-of-work function", draft-irtf-cfrg-argon2-10 (work 1154 in progress), March 2020. 1156 [I-D.irtf-cfrg-hash-to-curve] 1157 Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and 1158 C. Wood, "Hashing to Elliptic Curves", draft-irtf-cfrg- 1159 hash-to-curve-07 (work in progress), April 2020. 1161 [I-D.irtf-cfrg-voprf] 1162 Davidson, A., Sullivan, N., and C. Wood, "Oblivious 1163 Pseudorandom Functions (OPRFs) using Prime-Order Groups", 1164 draft-irtf-cfrg-voprf-03 (work in progress), March 2020. 1166 [I-D.sullivan-tls-opaque] 1167 Sullivan, N., Krawczyk, H., Friel, O., and R. Barnes, 1168 "Usage of OPAQUE with TLS 1.3", draft-sullivan-tls- 1169 opaque-00 (work in progress), March 2019. 1171 [JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu, 1172 "Highly-efficient and composable password-protected secret 1173 sharing (or: how to protect your bitcoin wallet online)", 1174 IEEE European Symposium on Security and Privacy , 2016. 1176 [OPAQUE] Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An 1177 Asymmetric PAKE Protocol Secure Against Pre-Computation 1178 Attacks", Eurocrypt , 2018. 1180 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 1181 RFC 2945, DOI 10.17487/RFC2945, September 2000, 1182 . 1184 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1185 Key Derivation Function (HKDF)", RFC 5869, 1186 DOI 10.17487/RFC5869, May 2010, 1187 . 1189 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 1190 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 1191 August 2016, . 1193 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 1194 Password-Based Cryptography Specification Version 2.1", 1195 RFC 8018, DOI 10.17487/RFC8018, January 2017, 1196 . 1198 [RFC8125] Schmidt, J., "Requirements for Password-Authenticated Key 1199 Agreement (PAKE) Schemes", RFC 8125, DOI 10.17487/RFC8125, 1200 April 2017, . 1202 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1203 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1204 . 1206 [SIGMA] Krawczyk, H., "SIGMA: The SIGn-and-MAc approach to 1207 authenticated Diffie-Hellman and its use in the IKE 1208 protocols", CRYPTO , 2003. 1210 [SIGNAL] "Signal recommended cryptographic algorithms", 1211 https://signal.org/docs/specifications/ 1212 doubleratchet/#recommended-cryptographic-algorithms , 1213 2016. 1215 [SPAKE2plus] 1216 Shoup, V., "Security Analysis of SPAKE2+", 1217 http://eprint.iacr.org/2020/313 , 2020. 1219 Appendix A. Counter mode encryption 1221 We define counter mode encryption to be used with EnvU (Section 4). 1222 The specification is based on [RFC3686] with a different initial 1223 value of CTRBLK. The description refers to AES but it applies to any 1224 block cipher (with its corresponding block size). 1226 Let PT be the plaintext to be encrypted and CTRBASE a 128-bit initial 1227 value (see Section 4 for the OPAQUE-specific CTRBASE value). 1228 Partition PT into 128-bit blocks PT = PT[1] PT[2] ... PT[n] where the 1229 final block can be shorter than 128 bits. To compute the ciphertext 1230 CT, each block PT[i] is XORed with a block KS[i] of a key stream KS 1231 obtained by applying AES to a 128-bit counter CTRBLK initialized to 1232 CTRBASE and incremented for each block KS[i]. The last value KS[n] 1233 is truncated, if necessary, to the length of PT[n]. The ciphertext 1234 CT includes n+1 blocks defined as CT[0]=CTRBASE and CT[i]=PT[i] xor 1235 KS[i], for i=1,...,n, with the final block possibly shorter than 128 1236 bits. 1238 The encryption of n plaintext blocks can be summarized as: 1240 CT[0] := CTRBASE 1241 CTRBLK := CTRBASE 1242 FOR i := 1 to n-1 DO 1243 CT[i] := PT[i] XOR AES(CTRBLK) 1244 CTRBLK := CTRBLK + 1 1245 END 1246 CT[n] := PT[n] XOR TRUNC(AES(CTRBLK)) 1248 The AES() function performs AES encryption with key EncKey. The 1249 TRUNC() function truncates the output of the AES encrypt operation to 1250 the same length as the final plaintext block, returning the most 1251 significant bits. 1253 Decryption is similar. The decryption of ciphertext CT= CT[0] ... 1254 CT[n] summarized as: 1256 CTRBLK := C[0] 1257 FOR i := 1 to n-1 DO 1258 PT[i] := CT[i] XOR AES(CTRBLK) 1259 CTRBLK := CTRBLK + 1 1260 END 1261 PT[n] := CT[n] XOR TRUNC(AES(CTRBLK)) 1263 Appendix B. Acknowledgments 1265 The OPAQUE protocol and its analysis is joint work of the author with 1266 Stas Jarecki and Jiayu Xu. We are indebted to the OPAQUE reviewers 1267 during CFRG's aPAKE selection process, particularly Julia Hesse and 1268 Bjorn Tackmann. This draft has benefited from comments by multiple 1269 people. Special thanks to Richard Barnes, Dan Brown, Eric Crockett, 1270 Paul Grubbs, Fredrik Kuivinen, Kevin Lewi, Payman Mohassel, Jason 1271 Resch, Nick Sullivan. 1273 Author's Address 1275 Hugo Krawczyk 1276 Algorand Foundation 1278 Email: hugokraw@gmail.com