idnits 2.17.1 draft-putman-tls13-preshared-dh-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 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 == Line 221 has weird spacing: '...red_key v...' -- The document date (January 31, 2018) is 2277 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: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-23 == Outdated reference: A later version (-04) exists of draft-harkins-tls-dragonfly-02 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 7564 (Obsoleted by RFC 8264) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group T. Putman 3 Internet-Draft Dyson Technology 4 Intended status: Informational January 31, 2018 5 Expires: August 4, 2018 7 Authenticated Key Agreement using Pre-Shared Asymmetric Keypairs for 8 (Datagram) Transport Layer Security ((D)TLS) Protocol version 1.3 9 draft-putman-tls13-preshared-dh-00 11 Abstract 13 This document defines an authenticated key agreement method for the 14 Transport Layer Security (TLS) protocol version 1.3. The 15 authentication method requires that the server (and optionally 16 client) is pre-provisioned with a unique long-term static asymmetric 17 Finite Field Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman 18 (ECDH) keypair; the peer must be able to obtain the public key of the 19 endpoint via an out-of-band mechanism (e.g. pre-provisioning). The 20 handshake provides ephemeral (EC)DH keys, and a common key schedule 21 is agreed using Double- or Triple-(EC)DH. Confirmation of knowledge 22 of the key schedule provides server (and optionally client) 23 authentication. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 4, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Rationale for Using Authenticated Key Agreement . . . . . 3 61 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 62 1.3. Comparison of 2/3(EC)DH with Other Methods . . . . . . . 4 63 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. 2(EC)DH and 3(EC)DH Key Exchange . . . . . . . . . . . . . . 5 65 3. Format of 2/3(EC)DH Identity . . . . . . . . . . . . . . . . 8 66 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 10 67 4.1. PSK Identity Encoding . . . . . . . . . . . . . . . . . . 10 68 4.2. Requirements for TLS Implementations . . . . . . . . . . 11 69 4.3. Requirements for Management Interfaces . . . . . . . . . 11 70 4.4. Precomputation for Constrained Clients . . . . . . . . . 12 71 5. Cryptographic Operations . . . . . . . . . . . . . . . . . . 13 72 5.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 13 73 5.2. Client Id Key Calculation . . . . . . . . . . . . . . . . 16 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 8.1. Security of 1-RTT Traffic . . . . . . . . . . . . . . . . 17 78 8.2. Security of 0-RTT Traffic . . . . . . . . . . . . . . . . 18 79 8.3. Security of Client Identity . . . . . . . . . . . . . . . 18 80 8.4. Additional Security Observations . . . . . . . . . . . . 18 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 83 9.2. Informative References . . . . . . . . . . . . . . . . . 20 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 Often, constrained devices use pre-shared keys (PSK) for 89 authentication and key agreement. A drawback of this is that if the 90 server database of pre-shared keys is compromised, then this means 91 that not only can the server be impersonated to the clients, but also 92 the symmetric nature of the keys means that the clients can be 93 impersonated to the server. 95 In consequence, a large-scale database compromise can result in 96 large-scale client impersonation. This is very hard to recover from 97 because any remote update to the clients risks providing the updated 98 information to an adversary. 100 This document describes the use of asymmetric pre-shared keys to 101 address this data-loss scenario. It assumes that an out-of-band 102 method of pre-configuring the asymmetric keys into the endpoints 103 exists, and this method is outside the scope of this document. The 104 primary intended usage is for constrained devices, but the method may 105 be used in other circumstances where the peer's public key may be 106 securely obtained out-of-band (e.g. via DNSSEC). 108 Another advantage of asymmetric pre-shared keys over symmetric pre- 109 shared keys is that it is easier to protect a single server private 110 key using hardware-based security than it is to protect a database of 111 shared symmetric keys. 113 1.1. Rationale for Using Authenticated Key Agreement 115 In [I-D.ietf-tls-tls13], all key exchange methods except those based 116 on PSK require perfect forward secrecy (PFS), which in turn requires 117 (at present) either Diffie-Hellman or Elliptic Curve Diffie-Hellman. 118 The number of constrained devices which can be accommodated is 119 increased if the key agreement also provides authentication, so that 120 no other public key algorithms are required. 122 Even if the device contains code for other public key algorithms 123 (e.g. EdDSA for code update signature checking), these may be coded 124 to use a slow variant of the algorithm to conserve code and data 125 space. In addition, hardware support for ECDH is likely to be 126 introduced in many constrained devices, as it is required for 127 wireless communications (e.g. Bluetooth Mesh), whereas signing 128 algorithms are not. 130 Double-(EC)DH [Blake-Wilson] could be used for authenticated key 131 agreement, but this would not provide PFS. PFS can be provided by 132 using Triple-(EC)DH [Kudla] with no change to the protocol messages; 133 it only adds to the cost of computing the keying material by adding 134 one additional (EC)DH computation. 136 In order to break forward secrecy in Double-(EC)DH, the attacker must 137 obtain the static (EC)DH private keys of both client and server. 138 This is likely to be a difficult feat, so both Double- and 139 Triple-(EC)DH are specified in this document as this increases the 140 number of constrained devices which are able to use this method. 142 Perfect Forward Secrecy (PFS) is a strongly recommended feature in 143 security protocol design and is mandatory to implement in both HTTP/2 144 [RFC7540] and (for non-PSK deployments) CoAP [RFC7252]. Therefore, 145 Triple-(EC)DH SHOULD be used for those deployments where the client 146 devices are able to support the additional computation. 148 1.2. Applicability Statement 150 The authentication methods defined in this document are primarily 151 intended for a narrow set of applications, where there is a well- 152 established relationship between clients and servers and where, in 153 addition, there are severe constraints on the client capabilities. 154 Even in such deployments, other alternatives may be more appropriate. 156 If the loss of server data is not of concern, then the use of 157 symmetric pre-shared keys may be more appealing. If, on the other 158 hand, the main goal is to avoid Public-Key Infrastructures (PKIs), 159 then the use of raw public keys [RFC7250] may be preferrable. 161 A secondary use of this authentication method is to support 0-RTT 162 traffic in a situation where no (current) session tickets exist. The 163 server in this situation will typically not have knowledge of the 164 client, so a method which supports only server authentication is also 165 supported. 167 1.3. Comparison of 2/3(EC)DH with Other Methods 169 The 2/3(EC)DH authenticated key agreement modes offer advantages over 170 other schemes, but there are limitations as well. A summary of 171 advantages and disadvantages are given in the following table: 173 +----------------+----------------------------+---------------------+ 174 | Alternative | 2/3(EC)DH Advantage | 2/3(EC)DH | 175 | Authentication | | Disadvantage | 176 | Mode | | | 177 +----------------+----------------------------+---------------------+ 178 | External PSK | Server breach does not | Public-key | 179 | | permit client | computations needed | 180 | | impersonation; hardware | | 181 | | protection for server key | | 182 | | possible; client identity | | 183 | | is confidential | | 184 | | | | 185 | Raw Public | Supports 0-RTT messages; | Separate server | 186 | Keys | only one public-key | keypair needed if | 187 | | algorithm used; shorter | it also supports | 188 | | messages | PKI | 189 | | | | 190 | Certificate | Supports 0-RTT messages; | Out-of-band public | 191 | Authentication | only one public-key | key distribution | 192 | | algorithm used; no | needed (e.g. pre- | 193 | | certificate parsing; much | provisioning, | 194 | | shorter messages | DNSSEC) | 195 +----------------+----------------------------+---------------------+ 197 1.4. Terminology 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 201 "OPTIONAL" in this document are to be interpreted as described in BCP 202 14 [RFC2119][RFC8174] when, and only when, they appear in all 203 capitals, as shown here. 205 2. 2(EC)DH and 3(EC)DH Key Exchange 207 This section defines the key exchange mechanisms which are used for 208 2(EC)DH and 3(EC)DH. The message exchange is identical to that used 209 for PSK with (EC)DHE key establishment, and is reproduced below in 210 Figure 1. Although the message exchange is identical, the pre-shared 211 keys have extra semantics applied and the key schedule is different. 213 Client Server 215 Key ^ ClientHello 216 Exch | + key_share 217 | + psk_key_exchange_modes 218 v + pre_shared_key --------> 219 ServerHello ^ Key 220 + key_share | Exch 221 + pre_shared_key v 222 {EncryptedExtensions} 223 {Finished} : Auth 224 <-------- [Application Data*] 225 Auth : {Finished} --------> 226 [Application Data] <-------> [Application Data] 228 + Indicates noteworthy extensions sent in the 229 previously noted message. 231 * Indicates optional or situation-dependent 232 messages/extensions that are not always sent. 234 {} Indicates messages protected using keys 235 derived from a [sender]_handshake_traffic_secret. 237 [] Indicates messages protected using keys 238 derived from [sender]_application_traffic_secret_N 240 Figure 1: Message flow for 2/3(EC)DH TLS Handshake 242 Details of the PSK identity format which is used with 2/3{EC}DH is 243 given in section Section 3. To understand the key exchange explained 244 here, it only necessary to know that the PSK identity is the 245 concatenation of a server PSK identity with an optional encrypted 246 client PSK identity. The server PSK identity is uniquely associated 247 with an (EC)DH private/public keypair, and the client PSK identity is 248 present if and only if a key share on the named curve corresponding 249 to the server PSK identity is present in the ClientHello message. 251 The client indicates its willingness to use 2/3(EC)DH authenticated 252 key exchange by including at least one compatible identity in its 253 "pre_shared_key" extension. Support for 2(EC)DH versus 3(EC)DH is 254 indicated by including the values psk_ke or psk_dhe_ke respectively 255 in the "psk_key_exchange_modes" extension; as with other pre-shared 256 key methods, psk_ke does not support PFS, whereas psk_dhe_ke does. 257 The client MUST NOT include more than one identity which is 258 associated with the same server PSK identity: doing so would 259 compromise the security of the encrypted client PSK identity. The 260 client MUST also include in the "supported_groups" extension all 261 (EC)DH groups which are needed to establish a key exchange for any of 262 the provided PSK identities: 2/3(EC)DH key exchange requires that all 263 static and ephemeral (EC)DH keys are in the same named group. 265 If the TLS server accepts the use of 2(EC)DH or 3(EC)DH, then it 266 selects a PSK identity which corresponds to the chosen key exchange 267 mode from the list of offered identities in the "pre_shared_key" 268 extension of the ClientHello message. As with other PSK modes, the 269 server MUST ensure that the selected PSK and cipher suite are 270 compatible, and it may do this by selecting the cipher suite first 271 then excluding all incompatible PSKs. 273 Prior to accepting PSK key establishment, the server MUST validate 274 the corresponding binder value (see Section 4.2.11.2 of 275 [I-D.ietf-tls-tls13]). If this value is not present or does not 276 validate, the server MUST abort the handshake. Servers SHOULD NOT 277 attempt to validate multiple binders; rather they SHOULD select a 278 single PSK and validate solely the binder that corresponds to that 279 PSK. 281 The server MUST support 3(EC)DH on each of its server PSK identities, 282 and may support 2(EC)DH on any subset of identities (including all or 283 none). The client MAY be willing to establish key exchange either 284 with or without PFS, indicated by including both the psk_ke and 285 psk_dhe_ke values in the "psk_key_exchange_mode" extension. If, in 286 this situation, the server chooses to use a 2/3(EC)DH identity, then 287 it SHALL select the 3(EC)DH key exchange method. The client MUST 288 support this behavior by constructing the corresponding binder using 289 the 3(EC)DH binding key; if it does not, then the handshake will 290 fail. 292 The selected PSK identity identifies a server static (EC)DH private/ 293 public keypair and implicitly also a named group. If the ClientHello 294 message does not contain a key share for this group, then the server 295 SHALL request the key share by sending a HelloRetryRequest which 296 indicates the selected PSK identity in the "pre_shared_key" 297 extension. If the ClientHello message does contain a key share for 298 this group but the selected identity does not contain an encrypted 299 client identity, then the server SHALL abort the handshake with an 300 "illegal_parameter" alert. 302 A client SHOULD remember which server PSK identity a server preferred 303 in previous sessions and SHOULD include the corresponding key share 304 in the first ClientHello message when establishing future sessions. 305 This will reduce the number of HelloRetryRequest messages from the 306 server and will speed up session establishment. 308 If the ClientHello is sent in response to a HelloRetryRequest, then 309 it MUST only contain the PSK identity selected by the server. It 310 MUST also contain in the "key_share" extension an ephemeral (EC)DH 311 key which is on the named curve associated with the server PSK 312 identity. Consequently, the PSK identity will contain both the 313 server PSK identity and the encrypted client PSK identity. 315 If 2/3(EC)DH PSK key exchange mode is selected, then the server 316 decrypts the client identity and, if it is not an anonymous client, 317 obtains the corresponding client static public (EC)DH key. If it 318 accepts anonymous clients or if it accepts the identified client, 319 then the server responds with a ServerHello message; this message 320 MUST include a "pre_shared_key" extension which indicates the 321 selected PSK identity and an ephemeral key share in the same named 322 group as the selected static (EC)DH key. It SHALL NOT send 323 Certificate or CertificateRequest messages. 325 Both peers MUST use the selected ephemeral and static (EC)DH keys to 326 derive the key schedule using either 2(EC)DH or 3(EC)DH, depending on 327 the selected key exchange mode, as specified in section Section 5.1. 329 If the 2/3(EC)DH PSK key exchange mode is selected and the decrypted 330 client identity is not recognised, or if it indicates an anonymous 331 client and the server is configured to reject anonymous clients, then 332 the server SHALL select a valid unused public key to use for the 333 purposes of computing the key binding, and only reject the handshake 334 when the binding check fails. This is needed to prevent an oracle 335 attack on client identity confidentiality where the attacker replays 336 a ClientHello but modifies the encrypted client identity in a 337 controlled way. 339 3. Format of 2/3(EC)DH Identity 341 The format of a PSK identity defined in [I-D.ietf-tls-tls13] is 342 opaque<1..2^16-1>, but additional structure is needed to support 343 confidentiality of the client PSK identity; this structure remains 344 opaque to the protocol, but must be agreed between the end-points 345 using an out-of-band mechanism. 347 An identity which is associated with 2/3(EC)DH key exchange SHALL be 348 the concatenation of a server PSK identity with an optional encrypted 349 client PSK identity. 351 A server which supports 2(EC)DH and/or 3(EC)DH MUST have one or more 352 identities associated with it for the purposes of (EC)DH PSK key 353 exchange. Each identity is associated with a single static (EC)DH 354 private/public keypair and Hash algorithm; these identities are 355 provided to the clients via an out-of-band mechanism (e.g. pre- 356 provisioning) which is outside the scope of this specification. 358 To simplify processing, the server PSK identities SHOULD all be the 359 same size; if the server has a single PSK identity, then it MAY be 360 NULL (zero length), but this is NOT RECOMMENDED as this complicates 361 the addition of new identities. Also, the server SHOULD ensure that 362 PSK identities which are established by the session ticket mechanism 363 are always distinguishable from 2/3(EC)DH PSK identities; for 364 example, if the session ticket is constructed as described in section 365 4 of [RFC5077], then the opaque "key_name" should be chosen so that 366 it does not collide with any of the server PSK identities. 368 The encrypted client PSK identity MUST be present if the 369 corresponding key share is present in the "key_share" extension, and 370 MUST NOT be present otherwise. If the server has a NULL identity, 371 then the minimum length of the PSK identity requires that the client 372 PSK identity must be present; this in turn means that the 373 corresponding key share must be present in the "key_share" extension. 375 A single server MAY support multiple static (EC)DH keys across one or 376 more named curves by having multiple server PSK identities. This 377 allows rotation of static keys on a single curve, or migration from a 378 weaker named curve or hash algorithm to a stronger one. The policies 379 required to rotate keys or change curves/hash algorithms are outside 380 the scope of this specification, but if such a change is instigated 381 then the overlap period during which both keys are supported should 382 be sufficiently long to ensure that all clients have been updated. 384 As suggested earlier, the server SHOULD ensure that the different PSK 385 identities that it is prepared to process are readily 386 distinguishable. If it mis-classes an identity then the binding 387 check will fail and the session will not be established. The 388 contents of the server PSK identity field are opaque, so this may be 389 done by keeping all PSK identities of this server the same length or 390 by preceding the server PSK identity with a length field. Each 391 server PSK identity is associated with a single (EC)DH private/public 392 keypair and hash algorithm, so the identity may be formed from a root 393 name with the corresponding curve name (and optionally hash 394 algorithm) appended. 396 When present, the client PSK identity is encrypted. The encryption 397 key is derived as described in section Section 5.1 and depends on the 398 client key share (among other things). For this reason, the client 399 PSK identity cannot be present if the corresponding key share is not 400 present and this forces the server to send a HelloRetryRequest if 401 this server PSK identity is selected. 403 Any string of all zero bytes of any length is reserved for an 404 anonymous client and MUST NOT be used for an actual client PSK 405 identity. It is RECOMMENDED that all client PSK identities are the 406 same length, in which case this length SHOULD be publicised so that 407 an anonymous client can use an identity of the same length. 408 Alternatively, if different lengths are supported for client PSK 409 identities, then the client and server SHOULD support padding of the 410 identity with leading zero bytes to prevent client identification by 411 correlating the length of the encrypted PSK identity string in 412 different handshake sequences. 414 4. Conformance Requirements 416 It is expected that different types of client and server identities 417 are useful for different applications running over TLS. This 418 document does not therefore mandate the use of any particular type of 419 identity (such as IPv4 address or Fully Qualified Domain Name 420 (FQDN)). 422 However, the TLS client and server clearly have to agree on the 423 identities and keys to be used. To improve interoperability, this 424 document places requirements on how the identity is encoded in the 425 protocol, and what kinds of identities and keys implementations have 426 to be supported. 428 The requirements for implementations are divided into two categories, 429 requirements for TLS implementations and management interfaces. In 430 this context, "TLS implementation" refers to a TLS library or module 431 that is intended to be used for several different purposes, while 432 "management interface" would typically be implemented by a particular 433 application that uses TLS. 435 This document does not specify how the server stores the keys and 436 identities, or how exactly it finds the key corresponding to the 437 identity it receives. For instance, if the identity is a domain 438 name, it might be appropriate to do a case-insensitive lookup. It is 439 RECOMMENDED that before looking up the key, the server processes the 440 client PSK identity with a PRECIS framework (see [RFC7564]) 441 appropriate for the identity in question (such as [RFC5891] for 442 components of domain names or [RFC8265] for usernames). 444 4.1. PSK Identity Encoding 446 The server and client PSK identities MUST be first converted to a 447 character string, and then encoded to octets using UTF-8 [RFC3629]; 448 the server PSK identity MAY be preceded by a single-octet length 449 field and the client PSK identity MAY be preceded by a variable 450 number of zero octets. For instance, 451 o IPv4 addresses are encoded as dotted-decimal strings (e.g. 452 "192.0.2.1"), not as 32-bit integers in network byte order. 454 o Domain names are encoded in their usual text form [RFC1035] (e.g. 455 "www.example.com" or "embedded\.dot.example.net"), not in DNS 456 protocol format. 458 o X.500 Distinguished Names are encoded in their string 459 representation [RFC4514], not as BER-encoded ASN.1. 461 This encoding is clearly not optimal for many types of identities. 462 It was chosen to avoid identity-type-specific parsing and encoding 463 code in implementations where the identity is configured by a person 464 using some kind of management interface. Requiring such identity- 465 type-specific code would also increase the chances for 466 interoperability problems resulting from different implementations 467 supporting different identity types. 469 4.2. Requirements for TLS Implementations 471 TLS implementations supporting 2/3(EC)DH key agreement MUST support 472 arbitrary client PSK Identities up to 128 octets in length, and MUST 473 provide a server PSK identity which uses a static ECDH key on the 474 named curve P-256. Supporting longer identities and other ECDH 475 curves is RECOMMENDED. 477 The server MUST provide information out-of-band regarding what 478 format(s) of client PSK identity it supports for each server PSK 479 identity, together with the server (EC)DH public key and hash 480 function. This information includes the supported length(s) of the 481 client PSK identity, the padding method (if any) and whether it 482 accepts anonymous clients or not. 484 4.3. Requirements for Management Interfaces 486 In the absence of an application profile specification specifying 487 otherwise, a management interface for entering the pre-shared 488 private/public keys, and/or PSK Identity MUST support the following: 490 o Entering client and server PSK identities consisting of up to 128 491 printable Unicode characters. Supporting as wide a character 492 repertoire and as long identities as feasible is RECOMMENDED. 494 o Entering the named curve and hash function which is associated 495 with each server PSK identity, or selecting from a pre-set list of 496 named curves and hash functions which are supported by the TLS 497 implementation. 499 o Entering pre-shared private and public keys in the representation 500 specified for that named curve in [I-D.ietf-tls-tls13], where each 501 value/co-ordinate is in hexadecimal encoding up to the length 502 required by the named curve. Supporting compressed forms and 503 longer co-ordinates is RECOMMENDED. The interface SHOULD validate 504 the key which was entered, if possible; that is, check that a 505 private key is in the correct range and, for ECDH keys, that a 506 public key is a point on the curve in the correct subgroup. 508 4.4. Precomputation for Constrained Clients 510 A number of computations in this protocol require substantial 511 resources from a constrained client. Some of these may be 512 precomputed, which reduces the time taken during the actual session 513 establishment, and so may improve the success rate of the handshake. 515 If the client only communicates with a small number of servers, then 516 the static-static shared secret (C_s/S_s) may be computed once only 517 and stored for all future communications, or may be computed offline 518 and preprovisioned. If this is done, then the secret SHOULD be 519 protected with the same level of security as is used to protect the 520 client private key; exposure of this key would allow the 521 impersonation of 0-RTT traffic. If the client does not store this 522 shared secret, then it may compute it before starting the handshake. 524 Prior to starting each handshake, the client should accumulate 525 sufficient entropy to generate all the session-specific secrets. 526 These include the client ephemeral (EC)DH keypair and the 527 ClientHello.random value. Accumulating entropy in a constrained 528 device may take a great deal of time; if so, then this should be done 529 as a background task. 531 Prior to starting each handshake, the client will usually generate 532 the ephemeral keypair and use it to compute the ephemeral-static 533 (C_e/S_s) shared secret. These are necessary to encrypt the client 534 identity. If the client has no information about the server's 535 preferences, then it may send an initial ClientHello without any key 536 share values so that it can learn which curve and server PSK identity 537 to use when generating the client ephemeral key. 539 If the above precomputations are performed, then during the handshake 540 the client only needs to perform one (respectively, two) public key 541 operations for 2(EC)DH (respectively, 3(EC)DH) authenticated key 542 agreement. These values are reduced by one for anonymous clients, 543 but constrained devices are not expected to use this mode. 545 5. Cryptographic Operations 547 Some changes are made to the key schedule which is specified in 548 section 7.1 of [I-D.ietf-tls-tls13] when computing keys generated 549 using the 2/3(EC)DH mode of key exchange. These changes introduce a 550 new derived secret which is used as a basis for encrypting client PSK 551 identities as well two new labels which are used for generating 552 bindings for the new PSK identities. Also, the schedule inputs are 553 expanded to introduce multiple (EC)DH shared keys, which are the 554 basis for this mode's authenticated key agreement. 556 In addition, there is a new key calculation which is used to encrypt 557 the client PSK identity. 559 5.1. Key Schedule 561 The key schedule shown below uses the same formatting conventions and 562 functions as used in section 7.1 of [I-D.ietf-tls-tls13]. That is, 564 o HKDF-Extract is drawn as taking the Salt argument from the top and 565 the IKM argument from the left. 567 o Derive-Secret's Secret argument is indicated by the incoming 568 arrow. For instance, the Early Secret is the Secret for 569 generating the client_early_traffic_secret. 571 Authenticated key agreement using 2(EC)DH or 3(EC)DH makes use of 572 both static and ephemeral (EC)DH keys, and these keys may belong to 573 either the client or the server. This results in four possible ways 574 to combine a client key with a server key. These are shown in the 575 key schedule as follows: 577 o C_s/S_s: Shared key generated using the client static (EC)DH key 578 and the server static (EC)DH key; this is a block of zeroes if the 579 client is anonymous. 581 o C_e/S_s: Shared key generated using the client ephemeral (EC)DH 582 key and the server static (EC)DH key. 584 o C_s/S_e: Shared key generated using the client static (EC)DH key 585 and the server ephemeral (EC)DH key; this is a block of zeroes if 586 the client is anonymous. 588 o C_e/S_e: Shared key generated using the client ephemeral (EC)DH 589 key and the server ephemeral (EC)DH key. This is the same as 590 (EC)DHE used by other key agreement modes, but this terminology is 591 used here for consistency with the other shared keys. It is not 592 used by 2(EC)DH. 594 The concatenation of two octet strings is shown using || between the 595 strings. 597 Server PSK Identity || 598 Server Static (EC)DH Public Key 599 | 600 V 601 C_e/S_s -> HKDF-Extract = Client Id Secret 602 | 603 +-----> Derive-Secret(., "client id", 604 | Truncate(ClientHello)) 605 | = client_id_secret 606 | 607 Derive-Secret(., "derived", "") | /* 2/3(EC)DH */ 608 0 /* not 2/3(EC)DH */ 609 | 610 v 611 PSK | -> HKDF-Extract = Early Secret /* not 2/3(EC)DH */ 612 C_s/S_s | /* 2/3(EC)DH */ 613 +-----> Derive-Secret(., 614 | "ext binder" | 615 | "res binder" | 616 | "2dh binder" | /* 2(EC)DH */ 617 | "3dh binder", /* 3(EC)DH */ 618 | "") 619 | = binder_key 620 | 621 +-----> Derive-Secret(., "c e traffic", 622 | ClientHello) 623 | = client_early_traffic_secret 624 | 625 +-----> Derive-Secret(., "e exp master", 626 | ClientHello) 627 | = early_exporter_master_secret 628 v 629 Derive-Secret(., "derived", "") 630 | 631 (EC)DHE | v /* not 2/3(EC)DH */ 632 C_s/S_e | --> HKDF-Extract = Handshake Secret /* 2(EC)DH */ 633 (C_e/S_e || | /* 3(EC)DH */ 634 C_s/S_e) +-----> Derive-Secret(., "c hs traffic", 635 | ClientHello...ServerHello) 636 | = client_handshake_traffic_secret 637 | 638 +-----> Derive-Secret(., "s hs traffic", 639 | ClientHello...ServerHello) 640 | = server_handshake_traffic_secret 641 v 643 Derive-Secret(., "derived", "") 644 | 645 v 646 0 -> HKDF-Extract = Master Secret 647 | 648 +-----> Derive-Secret(., "c ap traffic", 649 | ClientHello...server Finished) 650 | = client_application_traffic_secret_0 651 | 652 +-----> Derive-Secret(., "s ap traffic", 653 | ClientHello...server Finished) 654 | = server_application_traffic_secret_0 655 | 656 +-----> Derive-Secret(., "exp master", 657 | ClientHello...server Finished) 658 | = exporter_master_secret 659 | 660 +-----> Derive-Secret(., "res master", 661 ClientHello...client Finished) 662 = resumption_master_secret 664 (EC)DH computations can leak information about the private key if the 665 peer public key is not valid. Therefore, all (EC)DH computations in 666 the key schedule MUST be preceded by a validity check on the peer 667 public key as described in section 4.2.8.1 or section 4.2.8.2 of 668 [I-D.ietf-tls-tls13]; additional validity checks may be added as new 669 attacks are discovered. The endpoint MUST terminate the handshake if 670 validation fails. Validation is required even for the static public 671 keys, as the security of these keys is likely to be lower than for 672 the static private key, and they may be manipulated by an attacker 673 even if validation takes place during provisioning. 675 The first change to the key schedule defined in [I-D.ietf-tls-tls13] 676 introduced to support 2/3(EC)DH is to prepend an HKDF-Extract 677 computation to generate the Client Id Secret. The salt for this 678 computation is the concatenation of the server PSK identity with the 679 corresponding static public key; the IKM is the secret generated by 680 the client ephemeral key and the server static key. For 2/3(EC)DH 681 modes of key agreement, the salt for the next step of the key 682 schedule is a secret derived from the Client Id Secret; for other 683 modes the salt is a zero block. This means that this specification 684 results in no change to the key schedule for all other modes. 686 Next, the IKM for the generation of the Early Secret for 2/3(EC)DH is 687 the secret which is generated by the client static key and the server 688 static key. This is a long-term secret which is equivalent to the 689 PSK which is the IKM for other PSK modes. The inclusion of keying 690 material based on the client static (EC)DH key provides data origin 691 authenication for 0-RTT traffic (if present). For anonymous clients, 692 this IKM is a zero block; data origin authentication has no meaning 693 in any case for anonymous clients. 695 Additional labels are defined for the generation of the binder_key 696 which is used to bind the identity and key to the current handshake. 697 The label "2dh binder" (respectively "3dh binder") is used if the 698 selected mode is 2(EC)DH (respectively 3(EC)DH). 700 The last change to the key schedule is to the IKM used to derive the 701 Handshake Secret. As defined in [I-D.ietf-tls-tls13], this is the 702 secret generated by the client ephemeral key and the server ephemeral 703 key (if available). For 2(EC)DH, this is the secret generated by the 704 client static key and the server ephemeral key. For 3(EC)DH, this is 705 the concatenation of the secrets generated by the client ephemeral 706 key and the server ephemeral key, and by the client static key and 707 the server ephemeral key in that order. 709 All (EC)DH computations are carried out as described in section 7.4 710 of [I-D.ietf-tls-tls13]. 712 5.2. Client Id Key Calculation 714 Each offered client PSK identity within a handshake is associated 715 with a different server PSK identity, which means that the key 716 schedule ensures that a different Client Id Secret is computed for 717 each identity. This means that each derived client_id_secret is 718 different within a handshake. 720 However, it is possible that a client may re-use an ephemeral key in 721 multiple handshakes (though this is bad practice). If the client 722 pads the identity differently or manages multiple identities then 723 this will leak identity information. Therefore, the truncated 724 handshake context is included in the computation of the 725 client_id_secret to mitigate possible ephemeral key reuse. 727 The Truncate() function which is used when computing client_id_secret 728 is similar to that used in computing the binding values (see section 729 4.2.11.2 of [I-D.ietf-tls-tls13]), except that it excludes the entire 730 "pre_shared_key" extension, instead of just removing the binders 731 list. If the ClientHello is sent in response to a HelloRetryRequest 732 then the Truncate() function only applies to the second ClientHello; 733 the full first ClientHello message is included in the Transcript-Hash 734 as defined in section 4.4.1. of [I-D.ietf-tls-tls13]. 736 The encrypted identity is integrity-protected by the corresponding 737 PSK binder, so only encryption is required. Therefore, the HKDF- 738 Expand-Label function is used to generate a keystream of the same 739 length as the padded client PSK identity and the two are XORed 740 together to produce the encrypted identity. The decryption procedure 741 is identical. 743 client_id_key = PKDF-Expand-Label(client_id_secret, 744 "client id", 745 length(padded client PSK identity)) 747 6. Acknowledgements 749 This document is based on [I-D.putman-tls-preshared-ecdh] and the 750 author would like carry over the acknowledgements to this document; 751 that is, to thank the authors of [RFC4279], namely Pasi Eronen, 752 Hannes Tschofenig, Mohamad Badra, Omar Cherkaoui, Ibrahim Hajjeh and 753 Ahmed Serhrouchni; and to thank the author of 754 [I-D.harkins-tls-dragonfly], Dan Harkins, for the idea of encrypting 755 the client identity. 757 7. IANA Considerations 759 This document does not define any new IANA considerations. 761 8. Security Considerations 763 The security considerations in [I-D.ietf-tls-tls13] apply to this 764 document as well. 766 8.1. Security of 1-RTT Traffic 768 The Double- and Triple-Diffie-Hellman authenticated key exchange is 769 not particularly new, but it has not seen wide usage. Triple-ECDH is 770 used in the Signal protocol [Marlinspike] and a security proof of 771 both, in a modified form of the Bellare-Rogaway model, is provided in 772 [Kudla]; this latter paper also proves strong partnering in the 773 random oracle model. 775 The TLS 1.3 protocol is more complex than the protocol used in the 776 above proof, but no additional constraints are made on the components 777 of the proof if the client is not anonymous. All the material which 778 is used to compose the key in the proof is also used in constructing 779 the Finished messages, with the exception of the pair of static keys: 780 instead of including both static keys in the key schedule, the 781 derived secret is included; this is equivalent and is done to give 782 extra protection against weak ephemeral keys. The security proof 783 therefore also holds for the protocol described in this document if 784 the client is not anonymous. 786 If the client is anonymous, then there is no static client (EC)DH 787 keypair. The security properties of this situation are similar to 788 those of DHIES/ECIES [ABR], which also derives a key from a 789 combination of an ephemeral and a static (EC)DH key. The inclusion 790 of handshake context in the generation of all session keys protects 791 against replay attacks, and the inclusion of the ephemeral-ephemeral 792 key in the 3(EC)DH anonymous client situation additionally provides 793 PFS in this exchange. However, none of this is rigorous, and a full 794 security analysis of this should be undertaken. 796 8.2. Security of 0-RTT Traffic 798 The security of the 0-RTT traffic has the same weakened conditions as 799 for 0-RTT traffic in other PSK situations, namely that there is no 800 PFS and there is no guarantee of traffic uniqueness. 802 8.3. Security of Client Identity 804 The confidentiality of the client identity in a genuine handshake is 805 protected by an ephemeral-static shared secret; this has similar 806 properties to DHIES/ECIES [ABR]. The integrity of the key is 807 protected by the binder. 809 The encrypted client PSK identity does not have any verified client 810 information in the keying material. Therefore an attacker who knows 811 the server public key may impersonate a client when sending a client 812 key exchange message; this is no different to the other PSK key 813 exchange modes and does not affect the security of the completed 814 handshake. 816 Because a PSK Identity can be forged, the server should ensure that 817 there are no PSK Identity retrievals which are more expensive than 818 other operations in this protocol; this is to mitigate DoS attacks. 819 Additionally, if there are differences in the lookup time of a PSK 820 Identity (e.g. if recent lookups are cached), then an attacker may be 821 able to obtain information about the PSK Identity of a recent 822 handshake from timing attacks. 824 8.4. Additional Security Observations 826 This key exchange mode allows for the inclusion of 0-RTT traffic from 827 a client which has no previous communications with the server, only 828 an out-of-band method of obtaining the server PSK information 829 (identity, public key, anonymous client support). This supports 830 rapid client authentication at the application level, for example by 831 using an authentication token. However, there is currently no way to 832 convey this information to the TLS server, which will continue to 833 consider the client to be anonymous. Further work would be needed 834 before this use case could be considered to be secure, and it is not 835 considered further in this document. 837 As with the other PSK key exchange modes, these modes make use of 838 hidden information in the construction of the keying material. This 839 means that the cipher suites are quantum-safe in the event that the 840 message exchange is stored for later attack, provided that the client 841 and/or server static public keys (the pre-provisioned keys) remain 842 unknown to the eavesdropper. In the anonymous client use case, the 843 server public keys is likely to be widely known, so this observation 844 does not apply. 846 The protocol description in this document only refers to finite field 847 and elliptic curve Diffie-Hellman keys, but will work for any key 848 exchange mechanism which uses public/private keypairs to establish a 849 shared secret. The only change that is needed to support new methods 850 (which may include quantum-safe key exchange algorithms) is to 851 include their definition in the "key_share" extension. Any new 852 mechanisms which are added to the "key_share" extension MUST include 853 a consideration of their effect on this document in their security 854 section. 856 9. References 858 9.1. Normative References 860 [I-D.ietf-tls-tls13] 861 Rescorla, E., "The Transport Layer Security (TLS) Protocol 862 Version 1.3", draft-ietf-tls-tls13-23 (work in progress), 863 January 2018. 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, 867 DOI 10.17487/RFC2119, March 1997, 868 . 870 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 871 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 872 2003, . 874 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 875 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 876 May 2017, . 878 9.2. Informative References 880 [ABR] Abdalla, M., Bellare, M., and P. Rogaway, "DHIES: An 881 Encryption Scheme based on the Diffie-Hellman Problem", 882 2001, 883 . 885 [Blake-Wilson] 886 Blake-Wilson, S., Johnson, D., and A. Menezes, "Key 887 Agreement Protocols and their Security Analysis", 888 Cryptography and Coding volume 1355 of LNCS, 1997. 890 [I-D.harkins-tls-dragonfly] 891 Harkins, D., "Secure Password Ciphersuites for Transport 892 Layer Security (TLS)", draft-harkins-tls-dragonfly-02 893 (work in progress), August 2017. 895 [I-D.putman-tls-preshared-ecdh] 896 Putman, T., "ECDH-based Authentication using Pre-Shared 897 Asymmetric Keypairs for (Datagram) Transport Layer 898 Security ((D)TLS) Protocol version 1.2", draft-putman-tls- 899 preshared-ecdh-00 (work in progress), November 2017. 901 [Kudla] Kudla, C. and K. Paterson, "Modular Security Proofs for 902 Key Agreement Protocols", Advances in Cryptology ASIACRYPT 903 2005: 11th International Conference on the Theory and 904 Application of Cryptology and Information Security, 2005, 905 . 907 [Marlinspike] 908 Marlinspike, M. and T. Perrin, "The X3DH Key Agreement 909 Protocol", November 2016, 910 . 913 [RFC1035] Mockapetris, P., "Domain names - implementation and 914 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 915 November 1987, . 917 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 918 Ciphersuites for Transport Layer Security (TLS)", 919 RFC 4279, DOI 10.17487/RFC4279, December 2005, 920 . 922 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 923 (LDAP): String Representation of Distinguished Names", 924 RFC 4514, DOI 10.17487/RFC4514, June 2006, 925 . 927 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 928 "Transport Layer Security (TLS) Session Resumption without 929 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 930 January 2008, . 932 [RFC5891] Klensin, J., "Internationalized Domain Names in 933 Applications (IDNA): Protocol", RFC 5891, 934 DOI 10.17487/RFC5891, August 2010, 935 . 937 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 938 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 939 Transport Layer Security (TLS) and Datagram Transport 940 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 941 June 2014, . 943 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 944 Application Protocol (CoAP)", RFC 7252, 945 DOI 10.17487/RFC7252, June 2014, 946 . 948 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 949 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 950 DOI 10.17487/RFC7540, May 2015, 951 . 953 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 954 Preparation, Enforcement, and Comparison of 955 Internationalized Strings in Application Protocols", 956 RFC 7564, DOI 10.17487/RFC7564, May 2015, 957 . 959 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, 960 Enforcement, and Comparison of Internationalized Strings 961 Representing Usernames and Passwords", RFC 8265, 962 DOI 10.17487/RFC8265, October 2017, 963 . 965 Author's Address 967 Tony Putman 968 Dyson Technology 969 Malmesbury SN16 0RP 970 UK 972 Email: tony.putman@dyson.com