idnits 2.17.1 draft-sullivan-tls-opaque-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 February 2021) is 1156 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) == Unused Reference: 'RFC5869' is defined on line 536, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-14 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-09 == Outdated reference: A later version (-14) exists of draft-irtf-cfrg-opaque-03 == Outdated reference: A later version (-26) exists of draft-irtf-cfrg-spake2-18 Summary: 0 errors (**), 0 flaws (~~), 6 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: 26 August 2021 IBM Research 6 O. Friel 7 R. Barnes 8 Cisco 9 22 February 2021 11 OPAQUE with TLS 1.3 12 draft-sullivan-tls-opaque-01 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 https://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 26 August 2021. 36 Copyright Notice 38 Copyright (c) 2021 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 (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 54 3. OPAQUE . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Password Registration . . . . . . . . . . . . . . . . . . . . 4 56 5. Password Authentication . . . . . . . . . . . . . . . . . . . 4 57 5.1. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 5 58 6. Use of extensions in TLS handshake flows . . . . . . . . . . 7 59 6.1. OPAQUE-KEX . . . . . . . . . . . . . . . . . . . . . . . 7 60 6.2. OPAQUE-Sign . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. Integration into Exported Authenticators . . . . . . . . . . 9 62 8. Summary of properties . . . . . . . . . . . . . . . . . . . . 10 63 9. Privacy considerations . . . . . . . . . . . . . . . . . . . 10 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 12.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 Note that this draft has not received significant security review and 75 should not be the basis for production systems. 77 OPAQUE [opaque-paper] is a mutual authentication method that enables 78 the establishment of an authenticated cryptographic key between a 79 client and server based on a user's password, without ever exposing 80 the password to servers or other entities other than the client 81 machine and without relying on a Public Key Infrastructure (PKI). 82 OPAQUE leverages a primitive called a Strong symmetric Password 83 Authenticated Key Exchange (Strong aPAKE) to provide desirable 84 properties including resistance to pre-computation attacks in the 85 event of a server compromise. 87 In some cases, it is desirable to combine password-based 88 authentication with traditional PKI-based authentication as a 89 defense-in-depth measure. For example, in the case of IoT devices, 90 it may be useful to validate that both parties were issued a 91 certificate from a certain manufacturer. Another desirable property 92 for password-based authentication systems is the ability to hide the 93 client's identity from the network. This document describes the use 94 of OPAQUE in TLS 1.3 [TLS13] both as part of the TLS handshake and 95 post-handshake facilitated by Exported Authenticators 96 [I-D.ietf-tls-exported-authenticator], how the different approaches 97 satisfy the above properties and the trade-offs associated with each 98 design. 100 The in-handshake instantiations of OPAQUE can be used to authenticate 101 a TLS handshake with a password alone, or in conjunction with 102 certificate-based (mutual) authentication but does not provide 103 identity hiding for the client. The Exported Authenticators 104 instantiation of OPAQUE provides client identity hiding by default 105 and allows the application to do password authentication at any time 106 during the connection, but requires PKI authentication for the 107 initial handshake and application-layer semantics to be defined for 108 transporting authentication messages. 110 2. Conventions and Definitions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 3. OPAQUE 120 OPAQUE [opaque-paper] is a Strong Asymmetric Password-Authenticated 121 Key Exchange (Strong aPAKE) built on an oblivious pseudo-random 122 function (OPRF) and authenticated key exchange protocol that is 123 secure against key-compromise impersonation (KCI) attacks. Unlike 124 previous PAKE methods such as SRP [RFC2945] and SPAKE-2 125 [I-D.irtf-cfrg-spake2], which require a public salt value, a Strong 126 aPAKE leverages the OPRF private key as salt, making it resistant to 127 pre-computation attacks on the password database stored on the 128 server. 130 TLS 1.3 provides a KCI-secure key agreement algorithm suitable for 131 use with OPAQUE. This document describes two instantiations of 132 OPAQUE in TLS 1.3: one based on digital signatures, called OPAQUE- 133 Sign, and one on Diffie-Hellman key agreement, called OPAQUE-KEX. 135 OPAQUE consists of two distinct phases: password registration and 136 authentication. We will describe the mechanisms for password 137 registration in this document but it is assumed to have been done 138 outside of a TLS connection. During password registration, the 139 client and server establish a shared set of parameters for future 140 authentication and two private-public key pairs are generated, one 141 for the client and one for the server. The server keeps its private 142 key and stores an encapsulated copy of the client's key pair along 143 with its own public key in an "envelope" that is encrypted with the 144 result of the OPRF operation. Note that it is possible for the 145 server to use the same key for multiple clients. It may be necessary 146 to permit multiple simultaneous server keys in the even of a key 147 rollover. The client does not store any state nor any PKI 148 information. 150 In OPAQUE-Sign, the key pairs generated at password registration time 151 are digital signature keys. These signature keys are used in place 152 of certificate keys for both server and client authentication in a 153 TLS handshake. Client authentication is technically optional, though 154 in practice is almost universally required. OPAQUE-Sign cannot be 155 used alongside certificate-based handshake authentication. This 156 instantiation can also be leveraged to do part of a post-handshake 157 authentication using Exported Authenticators 158 [I-D.ietf-tls-exported-authenticator] given an established TLS 159 connection protected with certificate-based authentication. 161 In OPAQUE-KEX, the key pairs are Diffie-Hellman keys and are used to 162 establish a shared secret that is fed into the key schedule for the 163 handshake. The handshake continues to use Certificate-based 164 authentication and establishes the shared key using Diffie-Hellman. 165 This instantiations is best suited to use cases in which both 166 password and certificate-based authentication are needed during the 167 initial handshake, which is useful in some scenarios. There is no 168 unilateral authentication in this context, mutual authentication is 169 demonstrated explicitly through the finished messages. 171 4. Password Registration 173 Password registration is run between a client U and a server S. It 174 is assumed that U can authenticate S during this registration phase 175 (this is the only part in OPAQUE that requires some form of 176 authenticated channel, either physical, out-of-band, PKI-based, etc.) 177 During this phase, clients run the registration flow in 178 [I-D.irtf-cfrg-opaque] using a specific OPAQUE configuration 179 consisting of a tuple (OPRF, Hash, MHF, AKE). The specific AKE is 180 not used during registration. It is only used during login. 182 During this phase, a specific OPAQUE configuration is chosen, which 183 consists of a tuple (OPRF, Hash, MHF, AKE). See 184 [I-D.irtf-cfrg-opaque] for details about configuration parameters. 185 In this context, AKE is either OPAQUE-Sign or OPAQUE-KEX. 187 5. Password Authentication 189 Password authentication integrates TLS into OPAQUE in such a way that 190 clients prove knowledge of a password to servers. In this section, 191 we describe TLS extensions that support this integration for both 192 OPAQUE-KEX and OPAQUE-Sign. 194 5.1. TLS Extensions 196 We define several TLS extensions to signal support for OPAQUE and 197 transport the parameters. The extensions used here have a similar 198 structure to those described in Usage of PAKE with TLS 1.3 199 [I-D.barnes-tls-pake]. The permitted messages that these extensions 200 are allowed and the expected protocol flows are described below. 202 First, this document specifies extensions used to convey OPAQUE 203 client and server messages, called "opaque_client_auth" and 204 "opaque_server_auth" respectively. 206 enum { 207 ... 208 opaque_client_auth(TBD), 209 opaque_server_auth(TBD), 210 (65535) 211 } ExtensionType; 213 The "opaque_client_auth" extension contains a 214 "PAKEClientAuthExtension" struct and can only be included in the 215 "CertificateRequest" and "Certificate" messages. 217 struct { 218 opaque identity<0..2^16-1>; 219 } PAKEClientAuthExtension; 221 The "opaque_server_auth" extension contains a 222 "PAKEServerAuthExtension" struct and can only be included in the 223 "ClientHello", "EncryptedExtensions", "CertificateRequest" and 224 "Certificate" messages, depending on the type. 226 struct { 227 opaque idU<0..2^16-1>; 228 CredentialRequest request; 229 } PAKEShareClient; 231 struct { 232 opaque idS<0..2^16-1>; 233 CredentialResponse response; 234 } PAKEShareServer; 236 struct { 237 select (Handshake.msg_type) { 238 ClientHello: 239 PAKEShareClient client_shares<0..2^16-1>; 240 OPAQUEType types<0..2^16-1>; 241 EncryptedExtensions, Certificate: 242 PAKEShareServer server_share; 243 OPAQUEType type; 244 } 245 } PAKEServerAuthExtension; 247 This document also defines the following set of types; 249 enum { 250 OPAQUE-Sign(1), 251 OPAQUE-KEX(2), 252 } OPAQUEType; 254 Servers use PAKEShareClient.idU to index the user's record on the 255 server and create the PAKEShareServer.response. The types field 256 indicates the set of supported auth types by the client. 257 PAKEShareClient.request and PAKEShareServer.response, of type 258 CredentialRequest and CredentialResponse, respectively, are defined 259 in [I-D.irtf-cfrg-opaque]. 261 This document also describes a new CertificateEntry structure that 262 corresponds to an authentication via a signature derived using 263 OPAQUE. This structure serves as a placeholder for the 264 PAKEServerAuthExtension extension. 266 struct { 267 select (certificate_type) { 268 case OPAQUESign: 269 /* Defined in this document */ 270 opaque null<0> 272 case RawPublicKey: 273 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 274 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 276 case X509: 277 opaque cert_data<1..2^24-1>; 278 }; 279 Extension extensions<0..2^16-1>; 280 } CertificateEntry; 282 We request that IANA add an additional type to the "TLS Certificate 283 Types" registry for this OPAQUESign. 285 Support for the OPAQUESign Certificate type for server authentication 286 can be negotiated using the server_certificate_type [RFC7250] and the 287 Certificate type for client authentication can be negotiated using 288 the client_certificate_type extension [RFC7250]. 290 Note that there needs to be a change to the client_certificate_type 291 row in the IANA "TLS ExtensionType Values" table to allow 292 client_certificate_type extension to be used as an extension to the 293 CertificateRequest message. 295 6. Use of extensions in TLS handshake flows 297 6.1. OPAQUE-KEX 299 In this mode, OPAQUE private keys are used for key agreement 300 algorithm and the result is fed into the TLS key schedule. Password 301 validation is confirmed by the validation of the finished message. 302 These modes can be used in conjunction with optional Certificate- 303 based authentication. 305 It should be noted that since the identity of the client it is not 306 encrypted as it is sent as an extension to the ClientHello. This may 307 present a privacy problem unless a mechanism like Encrypted Client 308 Hello [ECH] is created to protect it. 310 Upon receiving a PAKEServerAuth extension, the server checks to see 311 if it has a matching record for this identity. If the record does 312 not exist, the handshake is aborted with a "illegal_parameter" alert. 313 If the record does exist, but the key type of the record does not 314 match any of the supported_groups sent in the key_share extension of 315 the ClientHello, an HRR is sent containing the set of valid key types 316 that it found records for. 318 Given a matching key_share and an identity with a matching 319 supported_group, the server returns its PAKEServerAuth as an 320 extension to its EncryptedExtensions. Both parties then derive a 321 shared OPAQUE key as follows: 323 U computes 324 K = H(g^y ^ PrivU || PubU ^ x || PubS ^ PrivU || IdU || IdS ) 325 S computes 326 K = H(g^x ^ PrivS || PubS ^ y || PubU ^ PrivS || IdU || IdS ) 328 IdU, IdS represent the identities of user (sent as identity in 329 PAKEShareClient) and server (Certificate message). H is the HKDF 330 function agreed upon in the TLS handshake. 332 The result, K, is then added as an input to the Master Secret in 333 place of the 0 value defined in TLS 1.3. Specifically, 335 0 -> HKDF-Extract = Master Secret 337 becomes 339 K -> HKDF-Extract = Master Secret 341 In this construction, the finished messages cannot be validated 342 unless the OPAQUE computation was done correctly on both sides, 343 authenticating both client and server. 345 6.2. OPAQUE-Sign 347 In this modes of operation, the OPAQUE private keys are used for 348 digital signatures and are used to define a new Certificate type and 349 CertificateVerify algorithm. Like the OPAQUE-KEX instantiations 350 above, the identity of the client is sent in the clear in the 351 client's first flight unless a mechanism like Encrypted Client Hello 352 [ECH] is created to protect it. 354 Upon receiving a PAKEServerAuth extension, the server checks to see 355 if it has a matching record for this identity. If the record does 356 not exist, the handshake is aborted with a TBD error message. If the 357 record does exist, but the key type of the record does not match any 358 of the supported_signatures sent in the the ClientHello, the 359 handshake must be aborted with a "illegal_parameter" error. 361 We define a new Certificate message type for an OPAQUE-Sign 362 authenticated handshake. 364 enum { 365 X509(0), 366 RawPublicKey(2), 367 OPAQUE-Sign(3), 368 (255) 369 } CertificateType; 371 Certificates of this type have CertificateEntry structs of the form: 373 struct { 374 Extension extensions<0..2^16-1>; 375 } CertificateEntry; 377 Given a matching signature_scheme and an identity with a matching key 378 type, the server returns a certificate message with type OPAQUE-Sign 379 with PAKEServerAuth as an extension. The private key used in the 380 CertificateVerify message is set to the private key used during 381 account registration, and the client verifies it using the server 382 public key contained in the client's envelope. 384 It is RECOMMENDED that the server includes a CertificateRequest 385 message with a PAKEClientAuth and the identity originally sent in the 386 PAKEServerAuth extension from the client hello. On receiving a 387 CertificateRequest message with a PAKEClientAuth extension, the 388 client returns a CertificateVerify message signed by PrivC which is 389 validated by the server using PubC. 391 7. Integration into Exported Authenticators 393 Neither of the above mechanisms provides privacy for the user during 394 the authentication phase, as the user id is sent in the clear. 395 Additionally, OPAQUE-Sign has the drawback that it cannot be used in 396 conjunction with certificate-based authentication. 398 It is possible to address both the privacy concerns and the 399 requirement for certificate-based authentication by using OPAQUE-Sign 400 in an Exported Authenticator [I-D.ietf-tls-exported-authenticator] 401 flow, since exported authenticators are sent over a secure channel 402 that is typically established with certificate-based authentication. 403 Using Exported Authenticators for OPAQUE has the additional benefit 404 that it can be triggered at any time after a TLS session has been 405 established, which better fits modern web-based authentication 406 mechanism. 408 The ClientHello contains PAKEServerAuth, PAKEClientAuth with empty 409 identity values to indicate support for these mechanisms. 411 1. Client creates Authenticator Request with CR extension 412 PAKEServerAuth. 414 2. Server creates Exported Authenticator with OPAQUE-Sign 415 (PAKEServerAuth) and CertificateVerify (signed with the OPAQUE 416 private key). 418 If the server would like to then establish mutual authentication, it 419 can do the following: 421 1. Server creates Authenticator Request with CH extension 422 PAKEClientAuth (identity) 424 2. Client creates Exported Authenticator with OPAQUE-Sign 425 Certificate and CertificateVerify (signed with user private key 426 derived from the envelope). 428 Support for Exported Authenticators is negotiated at the application 429 layer. 431 8. Summary of properties 433 +-----------+--------+-----------+-----------+--------------+-------+ 434 | Variant \ |Identity|Certificate|Server-only|Post-handshake|Minimum| 435 | Property | hiding | auth | auth | auth | round | 436 | | | | | | trips | 437 +===========+========+===========+===========+==============+=======+ 438 |OPAQUE-Sign| yes | yes | yes | yes | 2-RTT | 439 | with EA | | | | | | 440 +-----------+--------+-----------+-----------+--------------+-------+ 441 |OPAQUE-Sign| no | no | yes | no | 1-RTT | 442 +-----------+--------+-----------+-----------+--------------+-------+ 443 |OPAQUE-KEX | no | no | no | no | 1-RTT | 444 +-----------+--------+-----------+-----------+--------------+-------+ 446 Table 1 448 9. Privacy considerations 450 TBD: cleartext identity, etc 452 10. Security Considerations 454 TODO: protecting against user enumeration 456 11. IANA Considerations 458 * Existing IANA references have not been updated yet to point to 459 this document. 461 IANA is asked to register a new value in the "TLS Certificate 462 Types" registry of Transport Layer Security (TLS) Extensions (TLS- 463 Certificate-Types-Registry), as follows: 465 * Value: 4 Description: OPAQUE Authentication Reference: This RFC 467 Correction request: The client_certificate_type row in the IANA TLS 468 ExtensionType Values table to allow client_certificate_type extension 469 to be used as an extension to the CertificateRequest message. 471 12. References 473 12.1. Normative References 475 [I-D.ietf-tls-exported-authenticator] 476 Sullivan, N., "Exported Authenticators in TLS", Work in 477 Progress, Internet-Draft, draft-ietf-tls-exported- 478 authenticator-14, 25 January 2021, 479 . 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, 484 DOI 10.17487/RFC2119, March 1997, 485 . 487 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 488 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 489 Transport Layer Security (TLS) and Datagram Transport 490 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 491 June 2014, . 493 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 494 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 495 May 2017, . 497 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 498 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 499 . 501 12.2. Informative References 503 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 504 Encrypted Client Hello", Work in Progress, Internet-Draft, 505 draft-ietf-tls-esni-09, 16 December 2020, 506 . 509 [I-D.barnes-tls-pake] 510 Barnes, R. and O. Friel, "Usage of PAKE with TLS 1.3", 511 Work in Progress, Internet-Draft, draft-barnes-tls-pake- 512 04, 16 July 2018, . 515 [I-D.irtf-cfrg-opaque] 516 Krawczyk, H., Lewi, K., and C. A. Wood, "The OPAQUE 517 Asymmetric PAKE Protocol", Work in Progress, Internet- 518 Draft, draft-irtf-cfrg-opaque-03, 21 February 2021, 519 . 522 [I-D.irtf-cfrg-spake2] 523 Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", Work in Progress, 524 Internet-Draft, draft-irtf-cfrg-spake2-18, 17 January 525 2021, . 528 [opaque-paper] 529 Xu, J., "OPAQUE: An Asymmetric PAKE Protocol Secure 530 Against Pre-Computation Attacks", 2018. 532 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 533 RFC 2945, DOI 10.17487/RFC2945, September 2000, 534 . 536 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 537 Key Derivation Function (HKDF)", RFC 5869, 538 DOI 10.17487/RFC5869, May 2010, 539 . 541 Appendix A. Acknowledgments 543 Authors' Addresses 545 Nick Sullivan 546 Cloudflare 548 Email: nick@cloudflare.com 549 Hugo Krawczyk 550 IBM Research 552 Email: hugo@ee.technion.ac.il 554 Owen Friel 555 Cisco 557 Email: ofriel@cisco.com 559 Richard Barnes 560 Cisco 562 Email: rlb@ipv.sx