idnits 2.17.1 draft-ietf-tls-external-psk-importer-03.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 February 2020) is 1530 days in the past. Is this intentional? 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: 'RFC1035' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'CCB' is defined on line 420, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-25 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls D. Benjamin 3 Internet-Draft Google, LLC. 4 Intended status: Standards Track C.A. Wood 5 Expires: 18 August 2020 Apple, Inc. 6 15 February 2020 8 Importing External PSKs for TLS 9 draft-ietf-tls-external-psk-importer-03 11 Abstract 13 This document describes an interface for importing external PSK (Pre- 14 Shared Key) into TLS 1.3. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 18 August 2020. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 51 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Key Import . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.1. External PSK Diversification . . . . . . . . . . . . . . 4 55 4.2. Binder Key Derivation . . . . . . . . . . . . . . . . . . 5 56 5. Deprecating Hash Functions . . . . . . . . . . . . . . . . . 6 57 6. Incremental Deployment . . . . . . . . . . . . . . . . . . . 6 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 10.2. Informative References . . . . . . . . . . . . . . . . . 9 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 65 Appendix B. Addressing Selfie . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 TLS 1.3 [RFC8446] supports pre-shared key (PSK) authentication, 71 wherein PSKs can be established via session tickets from prior 72 connections or externally via some out-of-band mechanism. The 73 protocol mandates that each PSK only be used with a single hash 74 function. This was done to simplify protocol analysis. TLS 1.2 75 [RFC5246], in contrast, has no such requirement, as a PSK may be used 76 with any hash algorithm and the TLS 1.2 PRF. This means that 77 external PSKs could possibly be re-used in two different contexts 78 with the same hash functions during key derivation. Moreover, it 79 requires external PSKs to be provisioned for specific hash functions. 81 To mitigate these problems, external PSKs can be bound to a specific 82 KDF and hash function when used in TLS 1.3, even if they are 83 associated with a different hash function when provisioned. This 84 document specifies an interface by which external PSKs may be 85 imported for use in a TLS 1.3 connection to achieve this goal. In 86 particular, it describes how KDF-bound PSKs can be differentiated by 87 the target (D)TLS protocol version and KDF for which the PSK will be 88 used. This produces a set of candidate PSKs, each of which are bound 89 to a specific target protocol and KDF. This expands what would 90 normally have been a single PSK identity into a set of PSK 91 identities. 93 2. Conventions and Definitions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. Overview 103 Key importers mirror the concept of key exporters in TLS in that they 104 diversify a key based on some contextual information before use in a 105 connection. In contrast to key exporters, wherein differentiation is 106 done via an explicit label and context string, the key importer 107 defined herein diversifies external one PSK into one or more PSKs for 108 use via a target protocol, KDF identifier, and optional context 109 string. Additionally, the resulting PSK binder key is modified with 110 a new derivation label to prevent confusion with non-imported PSKs. 112 Imported keys do not require negotiation for use, as a client and 113 server will not agree upon identities if not imported correctly. 114 Endpoints may incrementally deploy PSK importer support by offering 115 non-imported keys for TLS versions prior to TLS 1.3. Non-imported 116 and imported PSKs are distinct since their identities are different 117 on the wire. See Section 6 for more details. 119 Clients which import external keys TLS MUST NOT use these keys for 120 any other purpose. Moreover, each external PSK MUST be associated 121 with at most one hash function. 123 3.1. Terminology 125 * External PSK (EPSK): A PSK established or provisioned out-of-band, 126 i.e., not from a TLS connection, which is a tuple of (Base Key, 127 External Identity, Hash). 129 * Base Key: The secret value of an EPSK. 131 * External Identity: The identity of an EPSK. 133 * Target protocol: The protocol for which a PSK is imported for use. 135 * Target KDF: The KDF for which a PSK is imported for use. 137 * Imported PSK (IPSK): A PSK derived from an EPSK, external 138 identity, optional context string, and target protocol and KDF. 140 * Imported Identity: The identity of an Imported PSK as sent on the 141 wire. 143 4. Key Import 145 A key importer diversifies an input EPSK into one or more PSKs 146 advertised on the wire via a target protocol, KDF identifier, and 147 optional context string. Additionally, the resulting PSK binder key 148 is modified with a new derivation label to prevent confusion with 149 non-imported PSKs. This section describes the diversification 150 mechanism and binder key computation change. 152 4.1. External PSK Diversification 154 A key importer takes as input an EPSK with external identity 155 "external_identity" and base key "epsk", as defined in Section 3.1, 156 along with an optional context, and transforms it into a set of PSKs 157 and imported identities for use in a connection based on supported 158 (target) protocols and KDFs. In particular, for each supported 159 target protocol "target_protocol" and KDF "target_kdf", the importer 160 constructs an ImportedIdentity structure as follows: 162 struct { 163 opaque external_identity<1...2^16-1>; 164 opaque context<0..2^16-1>; 165 uint16 target_protocol; 166 uint16 target_kdf; 167 } ImportedIdentity; 169 The list of "target_kdf" values is maintained by IANA as described in 170 Section 9. External PSKs MUST NOT be imported for (D)TLS 1.2 or 171 prior versions. See Section 6 for discussion on how imported PSKs 172 for TLS 1.3 and non-imported PSKs for earlier versions co-exist for 173 incremental deployment. 175 ImportedIdentity.context MUST include the context used to derive the 176 EPSK, if any exists. For example, ImportedIdentity.context may 177 include information about peer roles or identities to mitigate 178 Selfie-style reflection attacks. See Appendix B for more details. 179 If the EPSK is a key derived from some other protocol or sequence of 180 protocols, ImportedIdentity.context MUST include a channel binding 181 for the deriving protocols [RFC5056]. 183 ImportedIdentity.target_protocol MUST be the (D)TLS protocol version 184 for which the PSK is being imported. For example, TLS 1.3 [RFC8446] 185 and QUICv1 [QUIC] use 0x0304. Note that this means future versions 186 of TLS will increase the number of PSKs derived from an external PSK. 188 An Imported PSK derived from an EPSK with base key 'epsk' bound to 189 this identity is then computed as follows: 191 epskx = HKDF-Extract(0, epsk) 192 ipskx = HKDF-Expand-Label(epskx, "derived psk", 193 Hash(ImportedIdentity), L) 195 L is corresponds to the KDF output length of 196 ImportedIdentity.target_kdf as defined in Section 9. For hash-based 197 KDFs, such as HKDF_SHA256(0x0001), this is the length of the hash 198 function output, i.e., 32 octets. This is required for the IPSK to 199 be of length suitable for supported ciphersuites. 201 The identity of 'ipskx' as sent on the wire is ImportedIdentity, 202 i.e., the serialized content of ImportedIdentity is used as the 203 content of PskIdentity.identity in the PSK extension. 205 The hash function used for HKDF [RFC5869] is that which is associated 206 with the EPSK. It is not the hash function associated with 207 ImportedIdentity.target_kdf. If no hash function is specified, 208 SHA-256 MUST be used. Diversifying EPSK by 209 ImportedIdentity.target_kdf ensures that an IPSK is only used as 210 input keying material to at most one KDF, thus satisfying the 211 requirements in [RFC8446]. 213 Endpoints generate a compatible ipskx for each target ciphersuite 214 they offer. For example, importing a key for TLS_AES_128_GCM_SHA256 215 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 216 and another for HKDF-SHA384. In contrast, if TLS_AES_128_GCM_SHA256 217 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key 218 is necessary. 220 The resulting IPSK base key 'ipskx' is then used as the binder key in 221 TLS 1.3 with identity ImportedIdentity. With knowledge of the 222 supported KDFs, one may import PSKs before the start of a connection. 224 EPSKs may be imported for early data use if they are bound to 225 protocol settings and configurations that would otherwise be required 226 for early data with normal (ticket-based PSK) resumption. Minimally, 227 that means ALPN, QUIC transport settings, etc., must be provisioned 228 alongside these EPSKs. 230 4.2. Binder Key Derivation 232 To prevent PSK Importers from being confused with standard out-of- 233 band PSKs, imported PSKs change the PSK binder key derivation label. 234 In particular, the standard TLS 1.3 PSK binder key computation is 235 defined as follows: 237 0 238 | 239 v 240 PSK -> HKDF-Extract = Early Secret 241 | 242 +-----> Derive-Secret(., "ext binder" | "res binder", "") 243 | = binder_key 244 V 246 Imported PSKs replace the string "ext binder" with "imp binder" when 247 deriving "binder_key". This means the binder key is now computed as 248 follows: 250 0 251 | 252 v 253 PSK -> HKDF-Extract = Early Secret 254 | 255 +-----> Derive-Secret(., "ext binder" 256 | | "res binder" 257 | | "imp binder", "") 258 | = binder_key 259 V 261 This new label differentiates non-imported and imported external 262 PSKs. Specifically, a client and server will negotiate use of an 263 external PSK if and only if (a) both endpoints import the PSK or (b) 264 neither endpoint imports the PSK. As "binder_key" is a leaf key, 265 changing its computation does not affect any other key. 267 5. Deprecating Hash Functions 269 If a client or server wish to deprecate a hash function and no longer 270 use it for TLS 1.3, they remove the corresponding KDF from the set of 271 target KDFs used for importing keys. This does not affect the KDF 272 operation used to derive Imported PSKs. 274 6. Incremental Deployment 276 Recall that TLS 1.2 permits computing the TLS PRF with any hash 277 algorithm and PSK. Thus, an EPSK may be used with the same KDF (and 278 underlying HMAC hash algorithm) as TLS 1.3 with importers. However, 279 critically, the derived PSK will not be the same since the importer 280 differentiates the PSK via the identity, target protocol, and target 281 KDF. Thus, PSKs imported for TLS 1.3 are distinct from those used in 282 TLS 1.2, and thereby avoid cross-protocol collisions. Note that this 283 does not preclude endpoints from using non-imported PSKs for TLS 1.2. 284 Indeed, this is necessary for incremental deployment. 286 7. Security Considerations 288 The Key Importer security goals can be roughly stated as follows: 289 avoid PSK re-use across KDFs while properly authenticating endpoints. 290 When modeled as computational extractors, KDFs assume that input 291 keying material (IKM) is sampled from some "source" probability 292 distribution and that any two IKM values are chosen independently of 293 each other [Kraw10]. This source-independence requirement implies 294 that the same IKM value cannot be used for two different KDFs. 296 PSK-based authentication is functionally equivalent to session 297 resumption in that a connection uses existing key material to 298 authenticate both endpoints. Following the work of [BAA15], this is 299 a form of compound authentication. Loosely speaking, compound 300 authentication is the property that an execution of multiple 301 authentication protocols, wherein at least one is uncompromised, 302 jointly authenticates all protocols. Authenticating with an 303 externally provisioned PSK, therefore, should ideally authenticate 304 both the TLS connection and the external provision process. 305 Typically, the external provision process produces a PSK and 306 corresponding context from which the PSK was derived and in which it 307 should be used. We refer to an external PSK without such context as 308 "context free". 310 Thus, in considering the source-independence and compound 311 authentication requirements, the Key Import API described in this 312 document aims to achieve the following goals: 314 1. Externally provisioned PSKs imported into TLS achieve compound 315 authentication of the provision step(s) and connection. 317 2. Context-free PSKs only achieve authentication within the context 318 of a single connection. 320 3. Imported PSKs are used as IKM for two different KDFs. 322 4. Imported PSKs do not collide with existing PSKs used for TLS 1.2 323 and below. 325 5. Imported PSKs do not collide with future protocol versions and 326 KDFs. 328 8. Privacy Considerations 330 External PSK identities are typically static by design so that 331 endpoints may use them to lookup keying material. However, for some 332 systems and use cases, this identity may become a persistent tracking 333 identifier. 335 9. IANA Considerations 337 This specification introduces a new registry for TLS KDF identifiers 338 and defines the following target KDF values: 340 +-----------------+--------+ 341 | KDF Description | Value | 342 +=================+========+ 343 | Reserved | 0x0000 | 344 +-----------------+--------+ 345 | HKDF_SHA256 | 0x0001 | 346 +-----------------+--------+ 347 | HKDF_SHA384 | 0x0002 | 348 +-----------------+--------+ 350 Table 1: Target KDF Registry 352 New target KDF values are allocated according to the following 353 process: 355 * Values in the range 0x0000-0xfeff are assigned via Specification 356 Required [RFC8126]. 358 * Values in the range 0xff00-0xffff are reserved for Private Use 359 [RFC8126]. 361 10. References 363 10.1. Normative References 365 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 366 and Secure Transport", Work in Progress, Internet-Draft, 367 draft-ietf-quic-transport-25, 21 January 2020, 368 . 371 [RFC1035] Mockapetris, P.V., "Domain names - implementation and 372 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 373 November 1987, . 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, 377 DOI 10.17487/RFC2119, March 1997, 378 . 380 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 381 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 382 . 384 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 385 (TLS) Protocol Version 1.2", RFC 5246, 386 DOI 10.17487/RFC5246, August 2008, 387 . 389 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 390 Key Derivation Function (HKDF)", RFC 5869, 391 DOI 10.17487/RFC5869, May 2010, 392 . 394 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 395 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 396 DOI 10.17487/RFC6234, May 2011, 397 . 399 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 400 Writing an IANA Considerations Section in RFCs", BCP 26, 401 RFC 8126, DOI 10.17487/RFC8126, June 2017, 402 . 404 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 405 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 406 May 2017, . 408 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 409 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 410 . 412 10.2. Informative References 414 [BAA15] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, 415 "Verified Contributive Channel Bindings for Compound 416 Authentication", DOI 10.14722/ndss.2015.23277, Proceedings 417 2015 Network and Distributed System Security Symposium, 418 2015, . 420 [CCB] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, 421 "Verified Contributive Channel Bindings for Compound 422 Authentication", DOI 10.14722/ndss.2015.23277, Proceedings 423 2015 Network and Distributed System Security Symposium, 424 2015, . 426 [Kraw10] Krawczyk, H., "Cryptographic Extraction and Key 427 Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 , 428 2010, . 430 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 431 with PSK", 2019, . 433 Appendix A. Acknowledgements 435 The authors thank Eric Rescorla and Martin Thomson for discussions 436 that led to the production of this document, as well as Christian 437 Huitema for input regarding privacy considerations of external PSKs. 438 John Mattsson provided input regarding PSK importer deployment 439 considerations. Hugo Krawczyk provided guidance for the security 440 considerations. 442 Appendix B. Addressing Selfie 444 The Selfie attack [Selfie] relies on a misuse of the PSK interface. 445 The PSK interface makes the implicit assumption that each PSK is 446 known only to one client and one server. If multiple clients or 447 multiple servers with distinct roles share a PSK, TLS only 448 authenticates the entire group. A node successfully authenticates 449 its peer as being in the group whether the peer is another node or 450 itself. 452 Applications which require authenticating finer-grained roles while 453 still configuring a single shared PSK across all nodes can resolve 454 this mismatch either by exchanging roles over the TLS connection 455 after the handshake or by incorporating the roles of both the client 456 and server into the IPSK context string. For instance, if an 457 application identifies each node by MAC address, it could use the 458 following context string. 460 struct { 461 opaque client_mac<0..2^16-1>; 462 opaque server_mac<0..2^16-1>; 463 } Context; 465 If an attacker then redirects a ClientHello intended for one node to 466 a different node, the receiver will compute a different context 467 string and the handshake will not complete. 469 Note that, in this scenario, there is still a single shared PSK 470 across all nodes, so each node must be trusted not to impersonate 471 another node's role. 473 Authors' Addresses 475 David Benjamin 476 Google, LLC. 478 Email: davidben@google.com 479 Christopher A. Wood 480 Apple, Inc. 482 Email: cawood@apple.com