idnits 2.17.1 draft-barnes-tls-pake-04.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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2018) is 2111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-28 == Outdated reference: A later version (-26) exists of draft-irtf-cfrg-spake2-05 == Outdated reference: A later version (-04) exists of draft-harkins-tls-dragonfly-03 == Outdated reference: A later version (-13) exists of draft-irtf-cfrg-argon2-03 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft O. Friel 4 Intended status: Informational Cisco 5 Expires: January 17, 2019 July 16, 2018 7 Usage of PAKE with TLS 1.3 8 draft-barnes-tls-pake-04 10 Abstract 12 The pre-shared key mechanism available in TLS 1.3 is not suitable for 13 usage with low-entropy keys, such as passwords entered by users. 14 This document describes an extension that enables the use of 15 password-authenticated key exchange protocols with TLS 1.3. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 17, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Compatible PAKE Protocols . . . . . . . . . . . . . . . . . . 5 56 6. SPAKE2+ Implementation . . . . . . . . . . . . . . . . . . . 6 57 7. Pre-provisioned Parameters . . . . . . . . . . . . . . . . . 6 58 8. Content of the TLS Extensions . . . . . . . . . . . . . . . . 7 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 9.1. Security when using SPAKE2+ . . . . . . . . . . . . . . . 8 61 10. Open Items . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 10.1. PAKE Algorithm Negotiation . . . . . . . . . . . . . . . 9 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 12.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 DISCLAIMER: This is a work-in-progress draft and has not yet seen 72 significant security analysis. It should not be used as a basis for 73 building production systems. 75 In some applications, it is desireable to enable a client and server 76 to authenticate to one another using a low-entropy pre-shared value, 77 such as a user-entered password. 79 In prior versions of TLS, this functionality has been provided by the 80 integration of the Secure Remote Password PAKE protocol (SRP) 81 [RFC5054]. The specific SRP integration described in RFC 5054 does 82 not immediately extend to TLS 1.3 because it relies on the Client Key 83 Exchange and Server Key Exchange messages, which no longer exist in 84 1.3. 86 TLS 1.3 itself provides a mechanism for authentication with pre- 87 shared keys (PSKs). However, PSKs used with this protocol need to be 88 "full-entropy", because the binder values used for authentication can 89 be used to mount a dictionary attack on the PSK. So while the TLS 90 1.3 PSK mechanism is suitable for the session resumption cases for 91 which it is specified, it cannot be used when the client and server 92 share only a low-entropy secret. 94 Enabling TLS to address this use case effectively requires the TLS 95 handshake to execute a password-authenticated key establishment 96 (PAKE) protocol. This document describes a TLS extension "pake" that 97 can carry data necessary to execute a PAKE. 99 This extension is generic, in that it can be used to carry key 100 exchange information for multiple different PAKEs. We assume that 101 the client and server have pre-negotiated a choice of PAKE (and any 102 required parameters) in addition to the password itself. As a first 103 case, this document defines a concrete protocol for executing the 104 SPAKE2+ PAKE protocol [I-D.irtf-cfrg-spake2]. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 The mechanisms described in this document also apply to DTLS 1.3 113 [I-D.ietf-tls-dtls13], but for brevity, we will refer only to TLS 114 throughout. 116 3. Setup 118 In order to use this protocol, a TLS client and server need to have 119 pre-provisioned the values required to execute the protocol: 121 o A choice of PAKE protocol 123 o Any parameters required by the PAKE protocol 125 o A password (or a derived value as described by the PAKE protocol) 127 Servers will of course have multiple instances of this configuration 128 information for different clients. Clients may also have multiple 129 identities, even within a given server. We assume that in either 130 case, a single opaque "identity" value is sufficient to identify the 131 required parameters. 133 4. TLS Extensions 135 A client offers to authenticate with PAKE by including a "pake" 136 extension in its ClientHello. The content of this exension is a 137 "PAKEClientHello" value, providing a list of identities under which 138 the client can authenticate, and for each identity, the client's 139 first message from the underlying PAKE protocol. 141 If a client sends the "pake" extension, then it MAY also send the 142 "key_share" and "pre_shared_key" extensions, to allow the server to 143 choose an authentication mode. Unlike PSK-based authentication, 144 however, authentication with PAKE cannot be combined with the normal 145 TLS ECDH mechanism. Forward secrecy is provided by the PAKE itself. 147 struct { 148 opaque identity<0..2^16-1>; 149 opaque pake_message<1..2^16-1>; 150 } PAKEShare; 152 struct { 153 PAKEShare client_shares<0..2^16-1>; 154 } PAKEClientHello; 156 A server that receives a "pake" extension examines the list of client 157 shares to see if there is one with an identity the server recognizes. 158 If so, the server may indicate its choice of PAKE authentication by 159 including a "pake" extension in its ServerHello. The content of this 160 exension is a "PAKEServerHello" value, specifying the identity value 161 for the password the server has selected, and the server's first 162 message in the PAKE protocol. 164 Use of PAKE authenication is compatible with standard certificate- 165 based authentication of both clients and servers. If a server 166 includes an "pake" extension in its ServerHello, it may still send 167 the Certificate and CertificateVerify messages, and/or send a 168 CertificateRequest message to the client. 170 If a server uses PAKE authentication, then it MUST NOT send an 171 extension of type "key_share", "pre_shared_key", or "early_data". 173 struct { 174 PAKEShare server_share; 175 } PAKEServerHello; 177 Based on the messages exchanged in the ClientHello and ServerHello, 178 the client and server execute the specified PAKE protocol to derive a 179 shared key. This key is used as the "ECHD(E)" input to the TLS 1.3 180 key schedule. 182 As with client authentication via certificates, the server has not 183 authenticated the client until after it has received the client's 184 Finished message. When a server negotiates the use of this mechanism 185 for authentication, it MUST NOT send application data before it has 186 received the client's Finished message. 188 5. Compatible PAKE Protocols 190 In order to be usable with the "pake" extension, a PAKE protocol must 191 specify some syntax for its messages, and the protocol itself must be 192 compatible with the message flow described above. A specification 193 describing the use of a particular PAKE protocol with TLS must 194 provide the following details: 196 o Parameters that must be pre-provisioned 198 o Content of the "pake_message" field in a ClientHello 200 o Content of the "pake_message" field in a ServerHello 202 o How the PAKE protocol is executed based on those messages 204 o How the outputs are of the PAKE protocol are used to populate the 205 "PSK" and "ECDH(E)" inputs to the TLS key schedule. 207 The underlying cryptographic protocol must be compatible with the 208 message flow described above: 210 o It must be possible to execute in one round-trip, with the client 211 speaking first 213 o The Finished MAC must provide sufficient key confirmation for the 214 protocol, taking into account the contents of the handshake 215 messages 217 In addition, to be compatible with the security requirements of TLS 218 1.3, PAKE protocols defined for use with TLS 1.3 MUST provide forward 219 secrecy. 221 Several current PAKE protocols satisfy these requirements, for 222 example: 224 o SPAKE2+ (described below) [I-D.irtf-cfrg-spake2] 226 o SPEKE and derivatives such as Dragonfly [speke] 227 [I-D.harkins-tls-dragonfly] 229 o OPAQUE [opaque] 231 o SRP [RFC2945] 233 6. SPAKE2+ Implementation 235 7. Pre-provisioned Parameters 237 In order to use SPAKE2+, a TLS client and server need to have pre- 238 provisioned the values required to execute the SPAKE2+ protocol (see 239 Section 3.1 of [I-D.irtf-cfrg-spake2]): 241 o A DH group of order "p*h", with "p" a large prime, and generator 242 "G" 244 o Fixed elements "M" and "N" for the group 246 o A hash function "H" 248 o A password "pw" 250 Note that the hash function "H" might be different from the hash 251 function associated with the ciphersuite negotiated by the two 252 parties. The hash function "H" MUST be a hash function suitable for 253 hashing passwords, e.g., Argon2 or scrypt [I-D.irtf-cfrg-argon2] 254 [RFC7914]. 256 The TLS client and server roles map to the "A" and "B" roles in the 257 SPAKE2+ specification, respectively. The identity of the server is 258 the domain name sent in the "server_name" extension of the 259 ClientHello message. The identity of the client is an opaque octet 260 string, specified in the "spake2" ClientHello extension, defined 261 below. 263 From the shared password, each party computes two shared integers 264 "w0" and "w1" by running the following algorithm twice (changing the 265 "context" value each time): 267 struct { 268 uint16 context; 269 opaque client\_identity<0..255>; 270 opaque server\_name<0..255>; 271 opaque password<0..255>; 272 } PasswordInput; 274 o Encode the following values into a "PasswordInput" structure: 276 * "client_identity": The client's identity, as described above. 278 * "server_name": The server's identity, as described above. 280 * "password": The password "pw" 281 * "context": One of the following values: 283 + 0x7730, when generating "w0" 285 + 0x7731, when generating "w1" 287 o Use the hash function "H" with the encoded "PasswordInput" 288 structure as input to derive an "n"-byte string, where "n" is the 289 byte-length of "p". 291 o Interpret the "n"-bit string as an integer "w" in network byte 292 order. Return the result "(w % p) * h" of reducing "w" mod p and 293 multiplying it by "h". 295 Servers MUST store only the value "w0" and the product "L = w1*G", 296 where "G" is the fixed generator of the group. Clients will need to 297 have access to the values "w0" and "w1" directly, but SHOULD generate 298 these values dynamically, rather than caching them. 300 8. Content of the TLS Extensions 302 The content of a "pake_message" in a ClientHello is the client's key 303 share "T". The value "T" is computed as specified in 304 [I-D.irtf-cfrg-spake2], as "T = w*M + X", where "M" is a fixed value 305 for the DH group and "X" is the public key of a fresh DH key pair. 306 The format of the key share "T" is the same as for a 307 "KeyShareEntry.key_exchange" value from the same group. 309 The content of a "pake_message" in a ServerHello is the server's key 310 share "S". The value "S" is computed as specified in 311 [I-D.irtf-cfrg-spake2], as "S = w*N + Y", where "N" is a fixed value 312 for the DH group and "Y" is the public key of a fresh DH key pair. 313 The format of the key share "S" is the same as for a 314 "KeyShareEntry.key_exchange" value from the same group. 316 Based on these messages, both the client and server can compute the 317 two shared values as specified in [I-D.irtf-cfrg-spake2]. 319 +------+--------+---------------+--------------+ 320 | Name | Value | Client | Server | 321 +------+--------+---------------+--------------+ 322 | Z | x*y*G | x*(S - w0*N) | x*(T - w0*M) | 323 | | | | | 324 | V | w1*y*G | w1*(S - w0*N) | y*L | 325 +------+--------+---------------+--------------+ 327 The following value is used as the "(EC)DHE" input to the TLS 1.3 key 328 schedule: 330 K = H(Z || V) 332 Here "H" is the hash function corresponding to the TLS cipher suite 333 in use and "||" represents concatenation of octet strings. 335 9. Security Considerations 337 Many of the security properties of this protocol will derive from the 338 PAKE protocol being used. Security considerations for PAKE protocols 339 are noted in Section 5. 341 The mechanism defined in this document does not provide protection 342 for the client's identity, in contrast to TLS client authentication 343 with certificates. 345 TLS servers that offer this mechanism can be used by third party 346 attackers as an oracle for two questions: 348 1. Whether the server knows about a given identity 350 2. Whether the server recognizes a given (identity, password) pair 352 The former is signaled by whether the server returns a "pake" 353 extension. 355 [[TODO: Similar to https://tools.ietf.org/html/rfc5054#section- 356 2.5.1.3, the server could run through a complete handshake 357 calculation and fail at the end so that the attacker only knows that 358 the identity/password pair is incorrect, but does not know if the 359 identity is recognized or not. This requires that the server can 360 interpret the pake_message and ascertain the associated PAKE 361 algorithm, group parameters, etc., which requires a reworking of some 362 text in this draft as the identity is currently defined as providing 363 a map to said group parameters. This is related to the discussion in 364 the Open Items section.]] 366 The latter is signaled by whether the connection succeeds. These 367 oracles are all-or-nothing: If the attacker does not have the correct 368 identity or password, he does not learn anything about the correct 369 value. 371 9.1. Security when using SPAKE2+ 373 For the most part, the security properties of the password-based 374 authentication described in this document are the same as those 375 described in the Security Considerations of [I-D.irtf-cfrg-spake2]. 376 The TLS Finished MAC provides the key confirmation required for the 377 security of the protocol. Note that all of the elements covered by 378 the example confirmation hash listed in that document are also 379 covered by the Finished MAC: 381 o "A", "B", and "T" are included via the ClientHello 383 o "S" via the ServerHello 385 o "K", and "w" via the TLS key schedule 387 The "x" and "y" values used in the SPAKE2 protocol MUST have the same 388 ephemerality properties as the key shares sent in the "key_shares" 389 extension. In particular, "x" and "y" MUST NOT be equal to zero. 390 This ensures that TLS sessions using SPAKE2 have the same forward 391 secrecy properties as sessions using the normal TLS (EC)DH mechanism. 393 10. Open Items 395 10.1. PAKE Algorithm Negotiation 397 It is possible that a client may know the password to use, but may 398 not know in advance which PAKE protocols(s) a particular server 399 supports. A potential solution to this is similar to TLS1.3 400 ClientHello "key_share" operation: the client may send an empty 401 "client_shares" vector in its PAKEClientHello extension. The server 402 can then send an HelloRetryRequest indicating which PAKE protocol, 403 and associated group parameters, the client should use. The client 404 then sends another ClientHello that includes "pake_message" in the 405 PAKEClientHello extension calculated using the correct algorithm. 406 This requires definition of a suitable field for transporting PAKE 407 algorithm and group parameters. 409 As an optimaisation, similar to TLS1.3 key_share operation, the 410 client could guess the PAKE protocol and include a "pake_message" 411 derived from its guess in the initial ClientHello. If the server 412 does not support the selected PAKE protcol (or protocol group 413 parameter, etc.), the server can send an HelloRetryRequest indicating 414 the supported PAKE protocol and group parameters. Note: it is TBD if 415 sending two different "pake_messages" derived from two different 416 protocol and/or group parameters in two different ClientHello 417 messages constitutes a significant attack vector. This needs 418 cryptographic review. 420 11. IANA Considerations 422 This document requests that IANA add a value to the TLS ExtensionType 423 Registry with the following contents: 425 +-------+----------------+---------+-----------+ 426 | Value | Extension Name | TLS 1.3 | Reference | 427 +-------+----------------+---------+-----------+ 428 | TBD | pake | CH, SH | RFC XXXX | 429 +-------+----------------+---------+-----------+ 431 [[ RFC EDITOR: Please replace "TBD" in the above table with the value 432 assigned by IANA, and replace "XXXX" with the RFC number assigned to 433 this document. ]] 435 12. References 437 12.1. Normative References 439 [I-D.ietf-tls-dtls13] 440 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 441 Datagram Transport Layer Security (DTLS) Protocol Version 442 1.3", draft-ietf-tls-dtls13-28 (work in progress), July 443 2018. 445 [I-D.irtf-cfrg-spake2] 446 Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", draft-irtf-cfrg- 447 spake2-05 (work in progress), February 2018. 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 12.2. Informative References 456 [I-D.harkins-tls-dragonfly] 457 Harkins, D., "Secure Password Ciphersuites for Transport 458 Layer Security (TLS)", draft-harkins-tls-dragonfly-03 459 (work in progress), July 2018. 461 [I-D.irtf-cfrg-argon2] 462 Biryukov, A., Dinu, D., Khovratovich, D., and S. 463 Josefsson, "The memory-hard Argon2 password hash and 464 proof-of-work function", draft-irtf-cfrg-argon2-03 (work 465 in progress), August 2017. 467 [opaque] Xu, J., "OPAQUE: An Asymmetric PAKE Protocol Secure 468 Against Pre-Computation Attacks", 2018. 470 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 471 RFC 2945, DOI 10.17487/RFC2945, September 2000, 472 . 474 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 475 "Using the Secure Remote Password (SRP) Protocol for TLS 476 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 477 2007, . 479 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 480 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 481 August 2016, . 483 [speke] Jablon, D., "Extended Password Key Exchange Protocols 484 Immune to Dictionary Attacks", 1997. 486 Authors' Addresses 488 Richard Barnes 489 Cisco 491 Email: rlb@ipv.sx 493 Owen Friel 494 Cisco 496 Email: ofriel@cisco.com