idnits 2.17.1 draft-barnes-tls-pake-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 (April 13, 2018) is 2203 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-26 == Outdated reference: A later version (-26) exists of draft-irtf-cfrg-spake2-05 == Outdated reference: A later version (-13) exists of draft-irtf-cfrg-argon2-03 Summary: 0 errors (**), 0 flaws (~~), 4 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: October 15, 2018 April 13, 2018 7 Usage of SPAKE with TLS 1.3 8 draft-barnes-tls-pake-01 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 how the SPAKE password-authenticated key 15 exchange can be used 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 October 15, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 59 7.2. Informative References . . . . . . . . . . . . . . . . . 7 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 62 1. Introduction 64 DISCLAIMER: This is a work-in-progress draft of MLS and has not yet 65 seen significant security analysis. It should not be used as a basis 66 for building production systems. 68 In some applications, it is desireable to enable a client and server 69 to authenticate to one another using a low-entropy pre-shared value, 70 such as a user-entered password. 72 In prior versions of TLS, this functionality has been provided by the 73 integration of the Secure Remote Password PAKE protocol (SRP) 74 [RFC5054]. The specific SRP integration described in RFC 5054 does 75 not immediately extend to TLS 1.3 becauseit relies on the Client Key 76 Exchange and Server Key Exchange messages, which no longer exist in 77 1.3. At a more fundamental level, the messaging patterns required by 78 SRP do not map cleanly to the standard TLS 1.3 handshake, which has 79 fewer round-trips than prior versions. 81 TLS 1.3 itself provides a mechanism for authentication with pre- 82 shared keys (PSKs). However, PSKs used with this protocol need to be 83 "full-entropy", because the binder values used for authentication can 84 be used to mount a dictionary attack on the PSK. So while the TLS 85 1.3 PSK mechanism is suitable for the session resumption cases for 86 which it is specified, it cannot be used when the client and server 87 share only a low-entropy secret. 89 Enabling TLS to address this use case effectively requires the TLS 90 handshake to perform a password-authenticated key establishment 91 (PAKE) protocol. This document describes an embedding of the SPAKE2 92 PAKE protocol in TLS 1.3 [I-D.irtf-cfrg-spake2] [I-D.ietf-tls-tls13]. 93 This mechanism also applies to DTLS 1.3 [I-D.ietf-tls-dtls13], but 94 for brevity, we will refer only to TLS throughout. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Setup 104 In order to use this protocol, a TLS client and server need to have 105 pre-provisioned the values required to execute the SPAKE2 protocol 106 (see Section 3.1 of [I-D.irtf-cfrg-spake2]): 108 o A DH group "G" of order "p*h", with "p" a large prime 110 o Fixed elements "M" and "N" for the group 112 o A hash function "H" 114 o A password "p" 116 Note that the hash function "H" might be different from the hash 117 function associated with the ciphersuite negotiated by the two 118 parties. The hash function "H" MUST be a hash function suitable for 119 hashing passwords, e.g., Argon2 or scrypt [I-D.irtf-cfrg-argon2] 120 [RFC7914]. 122 The TLS client and server roles map to the "A" and "B" roles in the 123 SPAKE specification, respectively. The identity of the server is the 124 domain name sent in the "server_name" extension of the ClientHello 125 message. The identity of the client is an opaque octet string, 126 specified in the "spake2" ClientHello extension, defined below. 128 From the shared password, each party computes a shared integer "w" in 129 the following way: 131 struct { 132 opaque client_identity<0..255>; 133 opaque server_name<0..255>; 134 opaque password<0..255>; 135 } PasswordInput; 137 struct { 138 opaque salt<0..255>; 139 opaque idpass[H.length]; 140 } PasswordWithContext; 142 o Encode the following values into a "PasswordInput" structure: 144 * "client_identity": The client's identity, in the same form that 145 is presented in the "identity" field of the "SPAKE2ClientHello" 146 structure. 148 * "server_name": The server's identity, in the same form 149 presented in the "server_name" extension sent by the client. 151 * "password": The password itself 153 o Use the hash function "H" with the encoded "PasswordInput" 154 structure as input to derive an "n"-byte string, where "n" is the 155 byte-length of "p". 157 o Interpret the "n"-bit string as an integer in network byte order 158 and let "w" be the result of reducing this integer mod "p". 160 Servers SHOULD store only the product "w*N" of "w" with the fixed 161 element "N" of the group. Clients MAY compute "w" dynamically, based 162 on the password and client and server identities for a given session. 164 4. TLS Extensions 166 A client offers to authenticate with SPAKE2 by including an "spake2" 167 extension in its ClientHello. The content of this exension is an 168 "SPAKE2ClientHello" value, specifying the client's identity, where 169 the identity matches that used in 'IdentifierAndPassword', and a key 170 share "T". The value "T" is computed as specified in 171 [I-D.irtf-cfrg-spake2], as "T = w*M + X", where "M" is a fixed value 172 for the DH group and "X" is the public key of a fresh DH key pair. 173 The format of the key share "T" is the same as for a "KeyShareEntry" 174 value from the same group. 176 If a client sends the "spake2" extension, then it MAY also send the 177 "key_share" and "pre_shared_key" extensions, to allow the server to 178 choose an authentication mode. Unlike PSK-based authentication, 179 however, authentication with SPAKE2 cannot be combined with the 180 normal TLS ECDH mechanism. 182 struct { 183 opaque identity<0..2^16-1>; 184 opaque key_exchange<1..2^16-1>; 185 } SPAKE2Share; 187 struct { 188 SPAKE2Share client_shares<0..2^16-1>; 189 } SPAKE2ClientHello; 190 A server that receives an "spake2" extension examines the list of 191 client shares to see if there is one with an identity the server 192 recognizes. If so, the server may indicate its use of SPAKE2 193 authentication by including an "spake2" extension in its ServerHello. 194 The content of this exension is an "SPAKE2ServerHello" value, 195 specifying the identity value for the password the server has 196 selected, and the server's key share "S". The value "S" is computed 197 as specified in [I-D.irtf-cfrg-spake2], as "S = w*N + Y", where "N" 198 is a fixed value for the DH group and "Y" is the public key of a 199 fresh DH key pair. The format of the key share "S" is the same as 200 for a "KeyShareEntry" value from the same group. 202 Use of SPAKE2 authenication is not inconsistent with standard 203 certificate-based authentication of both clients and servers. 204 authentication are not mutually exclusive. If a server includes an 205 "spake2" extension in its ServerHello, it may still send the 206 Certificate and CertificateVerify messages, and/or send a 207 CertificateRequest message to the client. 209 If a server uses SPAKE2 authentication, then it MUST NOT send an 210 extension of type "key_share", "pre_shared_key", or "early_data". 212 struct { 213 SPAKE2Share server_share; 214 } SPAKE2ServerHello; 216 Based on these messages, both the client and server can compute the 217 shared key "K = x*(S-w*N) = y*(T-w*M)", as specified in 218 [I-D.irtf-cfrg-spake2]. The value "K" is then used as the "(EC)DHE" 219 input to the TLS key schedule. The integer "w" is used as the PSK 220 input, encoded as an integer in network byte order, using the 221 smallest number of octets possible. 223 As with client authentication via certificates, the server has not 224 authenticated the client until after it has received the client's 225 Finished message. When a server negotiates the use of this mechanism 226 for authentication, it MUST NOT send application data before it has 227 received the client's Finished message. 229 5. Security Considerations 231 For the most part, the security properties of the password-based 232 authentication described in this document are the same as those 233 described in the Security Considerations of [I-D.irtf-cfrg-spake2]. 234 The TLS Finished MAC provides the key confirmation required for the 235 security of the protocol. Note that all of the elements covered by 236 the example confirmation hash listed in that document are also 237 covered by the Finished MAC: 239 o "A", "B", and "T" are included via the ClientHello 241 o "S" via the ServerHello 243 o "K", and "w" via the TLS key schedule 245 The "x" and "y" values used in the SPAKE2 protocol MUST have the same 246 ephemerality properties as the key shares sent in the "key_shares" 247 extension. This ensures that TLS sessions using SPAKE2 have the same 248 forward secrecy properties as sessions using the normal TLS (EC)DH 249 mechanism. 251 The mechanism described above does not provide protection for the 252 client's identity, in contrast to TLS client authentication with 253 certificates. 255 [[ XXX(rlb@ipv.sx): Or maybe there's some HRR dance we could do. For 256 example: Server provides a key share in HRR, client does ECIES on 257 identity. ]] 259 6. IANA Considerations 261 This document requests that IANA add a value to the TLS ExtensionType 262 Registry with the following contents: 264 +-------+----------------+---------+-----------+ 265 | Value | Extension Name | TLS 1.3 | Reference | 266 +-------+----------------+---------+-----------+ 267 | TBD | spake2 | CH, SH | RFC XXXX | 268 +-------+----------------+---------+-----------+ 270 [[ RFC EDITOR: Please replace "TBD" in the above table with the value 271 assigned by IANA, and replace "XXXX" with the RFC number assigned to 272 this document. ]] 274 7. References 276 7.1. Normative References 278 [I-D.ietf-tls-dtls13] 279 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 280 Datagram Transport Layer Security (DTLS) Protocol Version 281 1.3", draft-ietf-tls-dtls13-26 (work in progress), March 282 2018. 284 [I-D.ietf-tls-tls13] 285 Rescorla, E., "The Transport Layer Security (TLS) Protocol 286 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 287 March 2018. 289 [I-D.irtf-cfrg-spake2] 290 Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", draft-irtf-cfrg- 291 spake2-05 (work in progress), February 2018. 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, 295 DOI 10.17487/RFC2119, March 1997, 296 . 298 7.2. Informative References 300 [I-D.irtf-cfrg-argon2] 301 Biryukov, A., Dinu, D., Khovratovich, D., and S. 302 Josefsson, "The memory-hard Argon2 password hash and 303 proof-of-work function", draft-irtf-cfrg-argon2-03 (work 304 in progress), August 2017. 306 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 307 "Using the Secure Remote Password (SRP) Protocol for TLS 308 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 309 2007, . 311 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 312 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 313 August 2016, . 315 Authors' Addresses 317 Richard Barnes 318 Cisco 320 Email: rlb@ipv.sx 322 Owen Friel 323 Cisco 325 Email: ofriel@cisco.com