idnits 2.17.1 draft-sullivan-tls-opaque-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1866 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-http2-secondary-certs-03 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-08 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-03 == Outdated reference: A later version (-26) exists of draft-irtf-cfrg-spake2-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Sullivan 3 Internet-Draft Cloudflare 4 Intended status: Standards Track H. Krawczyk 5 Expires: September 12, 2019 IBM Research 6 O. Friel 7 R. Barnes 8 Cisco 9 March 11, 2019 11 Usage of OPAQUE with TLS 1.3 12 draft-sullivan-tls-opaque-00 14 Abstract 16 This document describes two mechanisms for enabling the use of the 17 OPAQUE password-authenticated key exchange in TLS 1.3. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 12, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 55 3. OPAQUE . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Password Registration . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Implementing EnvU . . . . . . . . . . . . . . . . . . . . 5 58 5. TLS extensions . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Use of extensions in TLS handshake flows . . . . . . . . . . 8 60 6.1. OPAQUE-3DH, OPAQUE-HMQV . . . . . . . . . . . . . . . . . 8 61 6.2. OPAQUE-Sign . . . . . . . . . . . . . . . . . . . . . . . 10 62 7. Integration into Exported Authenticators . . . . . . . . . . 11 63 8. Summary of properties . . . . . . . . . . . . . . . . . . . . 11 64 9. Example OPRF . . . . . . . . . . . . . . . . . . . . . . . . 12 65 9.1. OPRF_1 . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 9.2. OPRF_2 . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 10. Privacy considerations . . . . . . . . . . . . . . . . . . . 13 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 13.2. Informative References . . . . . . . . . . . . . . . . . 15 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 Note that this draft has not received significant security review and 79 should not be the basis for production systems. 81 OPAQUE [opaque-paper] is a mutual authentication method that enables 82 the establishment of an authenticated cryptographic key between a 83 client and server based on a user's memorized password, without ever 84 exposing the password to servers or other entities other than the 85 client machine and without relying on PKI. OPAQUE leverages a 86 primitive called a Strong Asymmetrical Password Authenticated Key 87 Exchange (Strong aPAKE) to provide desirable properties including 88 resistance to pre-computation attacks in the event of a server 89 compromise. 91 In some cases, it is desirable to combine password-based 92 authentication with traditional PKI-based authentication as a 93 defense-in-depth measure. For example, in the case of IoT devices, 94 it may be useful to validate that both parties were issued a 95 certificate from a certain manufacturer. Another desirable property 96 for password-based authentication systems is the ability to hide the 97 client's identity from the network. This document describes the use 98 of OPAQUE in TLS 1.3 [TLS13] both as part of the TLS handshake and 99 post-handshake facilitated by Exported Authenticators 100 [I-D.ietf-tls-exported-authenticator], how the different approaches 101 satisfy the above properties and the trade-offs associated with each 102 design. 104 The in-handshake instantiations of OPAQUE can be used to authenticate 105 a TLS handshake with a password alone, or in conjunction with 106 certificate-based (mutual) authentication but does not provide 107 identity hiding for the client. The Exported Authenticators 108 instantiation of OPAQUE provides client identity hiding by default 109 and allows the application to do password authentication at any time 110 during the connection, but requires PKI authentication for the 111 initial handshake and application-layer semantics to be defined for 112 transporting authentication messages. 114 2. Conventions and Definitions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 3. OPAQUE 124 In OPAQUE [opaque-paper], it is shown that a Strong Asymmetric 125 Password-Authenticated Key Exchange (Strong aPAKE) can be constructed 126 given an oblivious pseudo-random function (OPRF) and authenticated 127 key exchange protocol that is secure against reverse impersonation 128 (a.k.a. KCI). Unlike previous PAKE methods such as SRP [RFC2945] 129 and SPAKE-2 [I-D.irtf-cfrg-spake2], which require a public salt 130 value, a Strong aPAKE leverages the OPRF private key as salt, making 131 it resistant to pre-computation attacks on the password database 132 stored on the server. 134 TLS 1.3 provides a KCI-secure key agreement algorithm suitable for 135 use with OPAQUE. This document describes three instantiations of 136 OPAQUE in TLS 1.3: one based on digital signatures, one on Diffie- 137 Hellman key agreement, and one based on HMQV key exchange. Of the 138 three instantiations, the only one that has known IPR considerations 139 is HMQV. 141 OPAQUE consists of two distinct phases: password registration and 142 authentication. We will describe the mechanisms for password 143 registration in this document but it is assumed to have been done 144 outside of TLS. During password registration, the client and server 145 establish a shared set of parameters for future authentication and 146 two private-public key pairs are generated, one for the client and 147 one for the server. The server keeps its private key and stores an 148 encapsulated copy of the client's key pair along with its own public 149 key in an "envelope" that is encrypted with the result of the OPRF 150 operation. Note that it is possible for the server to use the same 151 key for multiple clients. It may be necessary to permit multiple 152 simultaneous server keys in the even of a key rollover. The client 153 does not store any state nor any PKI information. 155 We call the first instantiation OPAQUE-Sign. In OPAQUE-Sign, the key 156 pairs generated at password registration time are digital signature 157 keys. These signature keys are used in place of certificate keys for 158 both server and client authentication in a TLS handshake. Client 159 authentication is technically optional, but in practice is almost 160 universally required. OPAQUE-Sign cannot be used alongside 161 certificate-based handshake authentication. This instantiation can 162 also be leveraged to do part of a post-handshake authentication using 163 Exported Authenticators [I-D.ietf-tls-exported-authenticator] given 164 an established TLS connection protected with certificate-based 165 authentication. 167 The second and third instantiations are called OPAQUE-3DH and OPAQUE- 168 HMQV. In these instantiations, the key pairs are Diffie-Hellman keys 169 and are used to establish a shared secret that is fed into the key 170 schedule for the handshake. The handshake continues to use 171 Certificate-based authentication. The two methods for establishing 172 the shared key are Diffie-Hellman and HMQV. These instantiations are 173 best suited to use cases in which both password and certificate-based 174 authentication are needed during the initial handshake, which is 175 useful in some scenarios. There is no unilateral authentication in 176 this context, mutual authentication is demonstrated explicitly 177 through the finished messages. 179 4. Password Registration 181 Password registration is run between a user U and a server S. It is 182 assumed that the user can authenticate the server during this 183 registration phase (this is the only part in OPAQUE that requires 184 some form of authenticated channel, either physical, out-of-band, 185 PKI-based, etc.) 187 A set of parameters is chosen. This includes an AuthEnc function for 188 key encapsulation, a group setting for the OPRF (chosen as a cipher 189 defined in Oblivious Pseudorandom Functions (OPRFs) using Prime-Order 190 Groups [I-D.sullivan-cfrg-voprf]), an instantiation (either OPAQUE- 191 Sign, OPAQUE-3DH or OPAQUE-HMQV), and a key type (either a TLS 192 Signature Scheme [TLS13] for OPAQUE-Sign or a TLS Supported Group 193 [TLS13] for OPAQUE-3DH and OPAQUE-HMQV). 195 o U chooses password PwdU and a pair of private-public keys PrivU 196 and PubU of the chosen key type. 198 o S chooses OPRF key kU (random and independent for each user U) and 199 sets vU = g^kU; it also chooses its own pair of private-public 200 keys PrivS and PubS (the server can use the same pair of keys with 201 multiple users), and sends PubS to U. 203 o U and S run OPRF(kU;PwdU) as defined in with only U learning the 204 result, denoted RwdU (mnemonics for "Randomized PwdU"). 206 o U generates an "envelope" EnvU defined as 208 EnvU = AuthEnc(RwdU; PrivU, PubU, PubS) 210 where AuthEnc is an authenticated encryption function with the "key 211 committing" property and is specified below in section. In EnvU, all 212 values require authentication and PrivU also requires encryption. 213 PubU can be omitted from EnvU if it can be reconstructed from PrivU 214 but while it will save bits on the wire it will come at some 215 computational cost during client authentication. 217 o U sends EnvU and PubU to S and erases PwdU, RwdU and all keys. S 218 stores (EnvU, PubS, PrivS, PubU, kU, vU) in a user-specific 219 record. If PrivS and PubS are used for multiple users, S can 220 store these values separately and omit them from the user's 221 record. 223 Note (salt). We note that in OPAQUE the OPRF key acts as the secret 224 salt value that ensures the infeasibility of pre-computation attacks. 225 No extra salt value is needed. 227 4.1. Implementing EnvU 229 The encryption for EnvU is required to be a key-committing 230 authenticated encryption algorithm. This, unfortunately, eliminates 231 both AES-GCM and AES-GCM-SIV as wrapping functions. It is possible 232 to create a key-committing authenticated encryption using AES-CBC 233 [RFC3602] or AES-CTR [RFC5930] with HMAC [RFC4868] as long as the 234 keys for encryption and authentication are derived separately with a 235 key domain separation mechanism such as HKDF [RFC5869]. 237 5. TLS extensions 239 We define several TLS extensions to signal support for OPAQUE and 240 transport the parameters. The extensions used here have a similar 241 structure to those described in Usage of PAKE with TLS 1.3 242 [I-D.barnes-tls-pake]. The permitted messages that these extensions 243 are allowed and the expected protocol flows are described below. 245 This document defines the following extension code points. 247 enum { 248 ... 249 opaque_client_auth(TBD), 250 opaque_server_auth(TBD), 251 (65535) 252 } ExtensionType; 254 The opaque_client_auth extension contains a PAKEClientAuthExtension 255 struct and can only be included in the CertificateRequest and 256 Certificate messages. The opaque_client_auth extension contains a 257 PAKEServerAuthExtension struct and can only be included in the 258 ClientHello, EncryptedExtensions, CertificateRequest and Certificate 259 messages, depending on the type. 261 The structures contained in this extension are defined as: 263 struct { 264 opaque identity<0..2^16-1>; 265 opaque OPRF_1<1..2^16-1>; 266 } PAKEShareClient; 267 struct { 268 opaque identity<0..2^16-1>; 269 opaque OPRF_2<1..2^16-1>; 270 opaque vU<1..2^16-1>; 271 opaque EnvU<1..2^16-1>; 272 } PAKEShareServer; 274 struct { 275 select (Handshake.msg_type) { 276 ClientHello: 277 PAKEShareClient client_shares<0..2^16-1>; 278 OPAQUEType types<0..2^16-1>; 279 EncryptedExtensions, Certificate: 280 PAKEShareServer server_share; 281 OPAQUEType type; 282 } 283 } PAKEServerAuthExtension; 285 struct { 286 opaque identity<0..2^16-1>; 287 } PAKEClientAuthExtension; 289 This document also defines the following set of types; 291 enum { 292 OPAQUE-Sign(1), 293 OPAQUE-3DH(2), 294 OPAQUE-3DH-Cert(3), 295 OPAQUE-HMQV(4), 296 OPAQUE-HMQV-Cert(5), 297 } OPAQUEType; 299 The "identity" field is the unique user id used to index the user's 300 record on the server. The types field indicates the set of supported 301 auth types by the client. The OPRF_1 message is as defined in 302 Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups 303 [I-D.sullivan-cfrg-voprf]. The content of OPRF_1 is typically the 304 result of the password hashed into a group element and blinded by an 305 element known to the client. OPRF_2 is the OPRF_1 value operated on 306 by the OPRF private key kU. vU is the public component of kU and EnvU 307 is the envelope containing PrivU, PubS, and PubU. (Note that for 308 groups, it may be more space efficient to only include PrivU and have 309 the client derive PubU from PrivU). See Section 9 for details. 311 This document also describes a new CertificateEntry structure that 312 corresponds to an authentication via a signature derived using 313 OPAQUE. This structure serves as a placeholder for the 314 PAKEServerAuthExtension extension. 316 struct { 317 select (certificate_type) { 318 case OPAQUESign: 319 /* Defined in this document */ 320 opaque null<0> 322 case RawPublicKey: 323 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 324 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 326 case X509: 327 opaque cert_data<1..2^24-1>; 328 }; 329 Extension extensions<0..2^16-1>; 330 } CertificateEntry; 332 We request that IANA add an additional type to the "TLS Certificate 333 Types" registry for this OPAQUESign. 335 Support for the OPAQUESign Certificate type for server authentication 336 can be negotiated using the server_certificate_type [RFC7250] and the 337 Certificate type for client authentication can be negotiated using 338 the client_certificate_type extension [RFC7250]. 340 Note that there needs to be a change to the client_certificate_type 341 row in the IANA TLS ExtensionType Values table to allow 342 client_certificate_type extension to be used as an extension to the 343 CertificateRequest message. 345 6. Use of extensions in TLS handshake flows 347 6.1. OPAQUE-3DH, OPAQUE-HMQV 349 In these two modes of operation, the OPAQUE private keys are used for 350 key agreement algorithm and the result is fed into the TLS key 351 schedule. Password validation is confirmed by the validation of the 352 finished message. These modes can be used in conjunction with 353 optional Certificate-based authentication. 355 It should be noted that since the identity of the client it is not 356 encrypted as it is sent as an extension to the ClientHello. This may 357 present a privacy problem unless a mechanism like ESNI 358 [I-D.ietf-tls-esni] is created to protect it. 360 Upon receiving a PAKEServerAuth extension, the server checks to see 361 if it has a matching record for this identity. If the record does 362 not exist, the handshake is aborted with a TBD error message. If the 363 record does exist, but the key type of the record does not match any 364 of the supported_groups sent in the key_share extension of the 365 ClientHello, an HRR is sent containing the set of valid key types 366 that it found records for. 368 Given a matching key_share and an identity with a matching 369 supported_group, the server returns its PAKEServerAuth as an 370 extension to its EncryptedExtensions. Both parties then derive a 371 shared OPAQUE key using 373 HMQV 375 C computes K = (g^y * PubS^e)^{x + d*PrivU) 376 S computes K = (g^x * PubU^d)^{y + e*PrivS 378 where d = H(g^x, IdS) and e = H(g^y, IdU), and IdU, IdS represent the 379 identities of user (sent as identity in PAKEShareClient) and server 380 (EncryptedExtension or Certificate message). TODO: be more explicit 381 about content of IdS. 383 3DH 385 C computes K = H(g^y ^ PrivU || PubU ^ x || PubS ^ PrivU || IdU || IdS ) 386 S computes K = H(g^x ^ PrivS || PubS ^ y || PubU ^ PrivS || IdU || IdS ) 388 IdU, IdS represent the identities of user (sent as identity in 389 PAKEShareClient) and server (Certificate message). 391 H is the HKDF function agreed upon in the TLS handshake. 393 The result, K, is then added as an input to the Master Secret in 394 place of the 0 value defined in TLS 1.3: 396 0 -> HKDF-Extract = Master Secret 398 becomes 400 K -> HKDF-Extract = Master Secret 402 In this construction, the finished messages cannot be validated 403 unless the OPAQUE computation was done correctly on both sides, 404 authenticating both client and server. 406 For the certificate version of OPAQUE (OPAQUE-3DH-Cert, OPAQUE-HMQV- 407 Cert), the server's first flight contains the standard set of 408 messages: ServerHello, EncryptedExtension, 409 (optional)CertificateRequest, Certificate, CertificateVerify, 410 Finished. In the non-certificate cases (OPAQUE-3DH-Cert, OPAQUE- 411 HMQV-Cert), the Certificate and CertificateVerify messages are 412 omitted, similar to the PSK mode in TLS 1.3. 414 6.2. OPAQUE-Sign 416 In this modes of operation, the OPAQUE private keys are used for 417 digital signatures and are used to define a new Certificate type and 418 CertificateVerify algorithm. Like the 3DH and HKDF instantiations 419 above, the identity of the client is sent in the clear in the 420 client's first flight unless a mechanism like ESNI 421 [I-D.ietf-tls-esni] is created to protect it. 423 Upon receiving a PAKEServerAuth extension, the server checks to see 424 if it has a matching record for this identity. If the record does 425 not exist, the handshake is aborted with a TBD error message. If the 426 record does exist, but the key type of the record does not match any 427 of the supported_signatures sent in the the ClientHello, the 428 handshake must be aborted with a TBD error. 430 We define a new Certificate message type for an OPAQUE-Sign 431 authenticated handshake. 433 enum { 434 X509(0), 435 RawPublicKey(2), 436 OPAQUE-Sign(3), 437 (255) 438 } CertificateType; 440 Certificates of this type have CertificateEntry structs of the form: 442 struct { 443 Extension extensions<0..2^16-1>; 444 } CertificateEntry; 446 Given a matching signature_scheme and an identity with a matching key 447 type, the server returns a certificate message with type OPAQUE-Sign 448 with PAKEServerAuth as an extension. The private key used in the 449 CertificateVerify message is set to PrivS, and the client verifies it 450 using PubS. 452 It is RECOMMENDED that the server includes a CertificateRequest 453 message with a PAKEClientAuth and the identity originally sent in the 454 PAKEServerAuth extension from the client hello. On receiving a 455 CertificateRequest message with a PAKEClientAuth extension, the 456 client returns a CertificateVerify message signed by PrivC which is 457 validated by the server using PubC. 459 7. Integration into Exported Authenticators 461 Neither of the above mechanisms provides privacy for the user during 462 the authentication phase, as the user id is sent in the clear. It is 463 possible to create an encryption mechanism like ESNI 464 [I-D.ietf-tls-esni] to protect these values, but this is not in scope 465 for this document. Additionally, OPAQUE-Sign has the drawback that 466 it cannot be used in conjunction with certificate-based 467 authentication. 469 It is possible to address both the privacy concerns and the 470 requirement for certificate-based authentication by using OPAQUE-Sign 471 in Exported Authenticator [I-D.ietf-tls-exported-authenticator] flow, 472 since exported authenticators are sent over a secure channel that is 473 typically established with certificate-based authentication. Using 474 Exported Authenticators for OPAQUE has the additional benefit that it 475 can be triggered at any time after a TLS session has been 476 established, which better fits modern web-based authentication 477 mechanism. 479 The client hello contains PAKEServerAuth, PAKEClientAuth with empty 480 identity values to indicate support for these mechanisms. 482 1. Client creates Authenticator Request with CR extension 483 PAKEServerAuth (identity, OPRF_1) 485 2. Server creates Exported Authenticator with OPAQUE-Sign 486 (PAKEServerAuth) and CertificateVerify (signed with PrivS) 488 If the server would like to then establish mutual authentication, it 489 can do the following: 1. Server creates Authenticator Request with 490 CH extension PAKEClientAuth (identity) 2. Client creates Exported 491 Authenticator with OPAQUE-Sign Certificate and CertificateVerify 492 (signed with PrivU) 494 Support for Exported Authenticators is negotiated at the application 495 layer. For example, OPAQUE-Sign in EAs could be defined as an 496 extension to Secondary Certificates in HTTP/2 497 [I-D.ietf-httpbis-http2-secondary-certs]. 499 8. Summary of properties 500 +-------------+-------+------------+----------+------------+--------+ 501 | Variant \ | Ident | Certificat | Server- | Post- | Minimu | 502 | Property | ity H | e Authenti | only | handshake | m | 503 | | iding | cation | Auth | auth | round | 504 | | | | | | trips | 505 +-------------+-------+------------+----------+------------+--------+ 506 | OPAQUE- | yes | yes | yes | yes | 2-RTT | 507 | Sign-EA | | | | | | 508 | | | | | | | 509 | OPAQUE-Sign | no | no | yes | no | 1-RTT | 510 | | | | | | | 511 | OPAQUE-3DH | no | no | no | no | 1-RTT | 512 | | | | | | | 513 | OPAQUE-3DH- | no | yes | no | no | 1-RTT | 514 | Cert | | | | | | 515 | | | | | | | 516 | OPAQUE-HMQV | no | no | no | no | 1-RTT | 517 | | | | | | | 518 | OPAQUE- | no | yes | no | no | 1-RTT | 519 | HMQV-Cert | | | | | | 520 +-------------+-------+------------+----------+------------+--------+ 522 9. Example OPRF 524 This is an example OPRF instantiation based on the ECOPRF-P256-HKDF- 525 SHA256-SSWU ciphersuite in [I-D.sullivan-cfrg-voprf]. We use 526 additive group notation in this description because we specifically 527 target the elliptic curve case. All operations can be replaced with 528 their multiplicative group counterparts. 530 The example ECOPRF-P256-HKDF-SHA256-SSWU instantiation uses the 531 following parameters: 533 o Curve: SECP256K1 curve 535 o H_1: H2C-P256-SHA256-SSWU- [I-D.sullivan-cfrg-voprf] 537 o label: voprf_h2c 539 o H_2: SHA256 541 See [I-D.sullivan-cfrg-voprf] for more details about how each of the 542 above components are used. In the following we will use the 543 functions OPRF_Blind, OPRF_Sign, OPRF_Unblind, OPRF_Finalize that are 544 defined in the same document. 546 9.1. OPRF_1 548 Let p be the prime order of the base field of the curve that is used 549 (e.g. 2^256 - 2^224 + 2^192 + 2^96 - 1 for P-256). Let I2OSP, OS2IP 550 be functions as defined in [RFC8017]. Then OPRF_1 is computed using 551 the OPRF_Blind function on the password P follows: 553 1. r <-$ GF(p) 555 2. M := rH_1(P) 557 3. Output (r, M) 559 H_1 = hash-to-curve(P) = 1. t1 = H("h2c" || label || I2OSP(len(x), 560 4) || P) 2. t2 = OS2IP(t1) 3. y = t^2 mod p 4. H_1(P) = 561 map2curve_simple_swu(y) 5. M = rH_1(P) 563 The client keeps the blind r, and sends the OPRF_1 value M as an 564 EllipticCurve point [TLS13]. 566 9.2. OPRF_2 568 The server now computes OPRF_2 by applying OPRF_Sign on the received 569 message M: 1. Z := kM 2. Output Z Note that the server should 570 multiply M by the cofactor of the given curve before it outputs Z. 571 In the case of P-256, this cofactor is equal to 1 and so it is not 572 necessary. 574 The output Z of OPRF_2 is sent as an EllipticCurve point "[]" back to 575 the client. 577 When the client receives the output of OPRF_2, it derives the 578 envelope decryption key using OPRF_Unblind followed by OPRF_Finalize. 580 1. N := (1/r)Z (OPRF_Unblind) 582 2. y := H_2(P, N) (OPRF_Finalize). Here, we require that N is 583 serialized before it is input to H_2. The client can now stores 584 (P, y) for future usage. 586 10. Privacy considerations 588 TBD 590 11. Security Considerations 592 TODO: protecting against user enumeration 594 12. IANA Considerations 596 o Existing IANA references have not been updated yet to point to 597 this document. 599 IANA is asked to register a new value in the "TLS Certificate 600 Types" registry of Transport Layer Security (TLS) Extensions (TLS- 601 Certificate-Types-Registry), as follows: 603 o Value: 4 Description: OPAQUE Authentication Reference: This RFC 605 Correction request: The client_certificate_type row in the IANA TLS 606 ExtensionType Values table to allow client_certificate_type extension 607 to be used as an extension to the CertificateRequest message. 609 13. References 611 13.1. Normative References 613 [I-D.ietf-httpbis-http2-secondary-certs] 614 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 615 Certificate Authentication in HTTP/2", draft-ietf-httpbis- 616 http2-secondary-certs-03 (work in progress), October 2018. 618 [I-D.ietf-tls-exported-authenticator] 619 Sullivan, N., "Exported Authenticators in TLS", draft- 620 ietf-tls-exported-authenticator-08 (work in progress), 621 October 2018. 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, 625 DOI 10.17487/RFC2119, March 1997, . 628 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 629 Algorithm and Its Use with IPsec", RFC 3602, 630 DOI 10.17487/RFC3602, September 2003, . 633 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 634 384, and HMAC-SHA-512 with IPsec", RFC 4868, 635 DOI 10.17487/RFC4868, May 2007, . 638 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 639 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 640 Transport Layer Security (TLS) and Datagram Transport 641 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 642 June 2014, . 644 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 645 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 646 May 2017, . 648 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 649 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 650 . 652 13.2. Informative References 654 [I-D.barnes-tls-pake] 655 Barnes, R. and O. Friel, "Usage of PAKE with TLS 1.3", 656 draft-barnes-tls-pake-04 (work in progress), July 2018. 658 [I-D.ietf-tls-esni] 659 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 660 "Encrypted Server Name Indication for TLS 1.3", draft- 661 ietf-tls-esni-03 (work in progress), March 2019. 663 [I-D.irtf-cfrg-spake2] 664 Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", draft-irtf-cfrg- 665 spake2-08 (work in progress), March 2019. 667 [I-D.sullivan-cfrg-voprf] 668 Davidson, A., Sullivan, N., and C. Wood, "Oblivious 669 Pseudorandom Functions (OPRFs) using Prime-Order Groups", 670 draft-sullivan-cfrg-voprf-03 (work in progress), March 671 2019. 673 [opaque-paper] 674 Xu, J., "OPAQUE: An Asymmetric PAKE Protocol Secure 675 Against Pre-Computation Attacks", 2018. 677 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 678 RFC 2945, DOI 10.17487/RFC2945, September 2000, 679 . 681 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 682 Key Derivation Function (HKDF)", RFC 5869, 683 DOI 10.17487/RFC5869, May 2010, . 686 [RFC5930] Shen, S., Mao, Y., and NSS. Murthy, "Using Advanced 687 Encryption Standard Counter Mode (AES-CTR) with the 688 Internet Key Exchange version 02 (IKEv2) Protocol", 689 RFC 5930, DOI 10.17487/RFC5930, July 2010, 690 . 692 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 693 "PKCS #1: RSA Cryptography Specifications Version 2.2", 694 RFC 8017, DOI 10.17487/RFC8017, November 2016, 695 . 697 Appendix A. Acknowledgments 699 Authors' Addresses 701 Nick Sullivan 702 Cloudflare 704 Email: nick@cloudflare.com 706 Hugo Krawczyk 707 IBM Research 709 Email: hugo@ee.technion.ac.il 711 Owen Friel 712 Cisco 714 Email: ofriel@cisco.com 716 Richard Barnes 717 Cisco 719 Email: rlb@ipv.sx