idnits 2.17.00 (12 Aug 2021) /tmp/idnits24734/draft-ietf-tls-external-psk-importer-06.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 (3 December 2020) is 534 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) == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5869 Summary: 2 errors (**), 0 flaws (~~), 3 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: 6 June 2021 Cloudflare 6 3 December 2020 8 Importing External PSKs for TLS 9 draft-ietf-tls-external-psk-importer-06 11 Abstract 13 This document describes an interface for importing external Pre- 14 Shared Keys (PSKs) 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 6 June 2021. 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. PSK Import . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.1. External PSK Diversification . . . . . . . . . . . . . . 4 55 4.2. Binder Key Derivation . . . . . . . . . . . . . . . . . . 6 56 5. Deprecating Hash Functions . . . . . . . . . . . . . . . . . 6 57 6. Incremental Deployment . . . . . . . . . . . . . . . . . . . 7 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 63 10.2. Informative References . . . . . . . . . . . . . . . . . 10 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 65 Appendix B. Addressing Selfie . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 pseudorandom function (PRF). 77 While there is no known way in which the same external PSK might 78 produce related output in TLS 1.3 and prior versions, only limited 79 analysis has been done. Applications SHOULD provision separate PSKs 80 for TLS 1.3 and prior versions. 82 To mitigate against any interference, this document specifies a PSK 83 Importer interface by which external PSKs may be imported and 84 subsequently bound to a specific key derivation function (KDF) and 85 hash function for use in TLS 1.3 [RFC8446] and DTLS 1.3 [DTLS13]. In 86 particular, it describes a mechanism for differentiating external 87 PSKs by the target KDF, (D)TLS protocol version, and an optional 88 context string. This process yields a set of candidate PSKs, each of 89 which are bound to a target KDF and protocol, that are separate from 90 those used in (D)TLS 1.2 and prior versions. This expands what would 91 normally have been a single PSK and identity into a set of PSKs and 92 identities. 94 2. Conventions and Definitions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 3. Overview 104 The PSK Importer interface mirrors that of the TLS Exporters 105 interface in that it diversifies a key based on some contextual 106 information. In contrast to the Exporters interface, wherein 107 differentiation is done via an explicit label and context string, the 108 PSK Importer interface defined herein takes an external PSK and 109 identity and "imports" it into TLS, creating a set of "derived" PSKs 110 and identities. Each of these derived PSKs are bound a target 111 protocol, KDF identifier, and optional context string. Additionally, 112 the resulting PSK binder keys are modified with a new derivation 113 label to prevent confusion with non-imported PSKs. Through this 114 interface, importing external PSKs with different identities yields 115 distinct PSK binder keys. 117 Imported keys do not require negotiation for use since a client and 118 server will not agree upon identities if imported incorrectly. 119 Endpoints may incrementally deploy PSK Importer support by offering 120 non-imported keys for TLS versions prior to TLS 1.3. Non-imported 121 and imported PSKs are distinct since their identities are different 122 on the wire. See Section 6 for more details. 124 Endpoints which import external keys MUST NOT use either the external 125 keys or the derived keys for any other purpose. Moreover, each 126 external PSK MUST be associated with at most one hash function, as 127 per the rules in Section 4.2.11 from [RFC8446]. See Section 7 for 128 more discussion. 130 3.1. Terminology 132 * External PSK (EPSK): A PSK established or provisioned out-of-band, 133 i.e., not from a TLS connection, which is a tuple of (Base Key, 134 External Identity, Hash). 136 * Base Key: The secret value of an EPSK. 138 * External Identity: A sequence of bytes used to identify an EPSK. 140 * Target protocol: The protocol for which a PSK is imported for use. 142 * Target KDF: The KDF for which a PSK is imported for use. 144 * Imported PSK (IPSK): A PSK derived from an EPSK, External 145 Identity, optional context string, target protocol, and target 146 KDF. 148 * Imported Identity: A sequence of bytes used to identify an IPSK. 150 4. PSK Import 152 This section describes the PSK Importer interface and its underlying 153 diversification mechanism and binder key computation modification. 155 4.1. External PSK Diversification 157 The PSK Importer interface takes as input an EPSK with External 158 Identity "external_identity" and base key "epsk", as defined in 159 Section 3.1, along with an optional context, and transforms it into a 160 set of PSKs and imported identities for use in a connection based on 161 target protocols and KDFs. In particular, for each supported target 162 protocol "target_protocol" and KDF "target_kdf", the importer 163 constructs an ImportedIdentity structure as follows: 165 struct { 166 opaque external_identity<1...2^16-1>; 167 opaque context<0..2^16-1>; 168 uint16 target_protocol; 169 uint16 target_kdf; 170 } ImportedIdentity; 172 The list of ImportedIdentity.target_kdf values is maintained by IANA 173 as described in Section 9. External PSKs MUST NOT be imported for 174 (D)TLS 1.2 or prior versions. See Section 6 for discussion on how 175 imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions 176 co-exist for incremental deployment. 178 ImportedIdentity.context MUST include the context used to derive the 179 EPSK, if any exists. For example, ImportedIdentity.context may 180 include information about peer roles or identities to mitigate 181 Selfie-style reflection attacks [Selfie]. See Appendix B for more 182 details. If the EPSK is a key derived from some other protocol or 183 sequence of protocols, ImportedIdentity.context MUST include a 184 channel binding for the deriving protocols [RFC5056]. The details of 185 this binding are protocol specific and out of scope for this 186 document. 188 ImportedIdentity.target_protocol MUST be the (D)TLS protocol version 189 for which the PSK is being imported. For example, TLS 1.3 [RFC8446] 190 uses 0x0304, which will therefore also be used by QUICv1 [QUIC]. 191 Note that this means future versions of TLS will increase the number 192 of PSKs derived from an external PSK. 194 Given an ImportedIdentity and corresponding EPSK with base key 195 "epsk", an Imported PSK IPSK with base key "ipskx" is computed as 196 follows: 198 epskx = HKDF-Extract(0, epsk) 199 ipskx = HKDF-Expand-Label(epskx, "derived psk", 200 Hash(ImportedIdentity), L) 202 L corresponds to the KDF output length of ImportedIdentity.target_kdf 203 as defined in Section 9. For hash-based KDFs, such as 204 HKDF_SHA256(0x0001), this is the length of the hash function output, 205 i.e., 32 octets. This is required for the IPSK to be of length 206 suitable for supported ciphersuites. 208 The identity of "ipskx" as sent on the wire is ImportedIdentity, 209 i.e., the serialized content of ImportedIdentity is used as the 210 content of PskIdentity.identity in the PSK extension. The 211 corresponding TLS 1.3 binder key is "ipskx". 213 The hash function used for HKDF [RFC5869] is that which is associated 214 with the EPSK. It is not the hash function associated with 215 ImportedIdentity.target_kdf. If no hash function is specified, 216 SHA-256 [SHA2] MUST be used. Diversifying EPSK by 217 ImportedIdentity.target_kdf ensures that an IPSK is only used as 218 input keying material to at most one KDF, thus satisfying the 219 requirements in [RFC8446]. See Section 7 for more details. 221 Endpoints SHOULD generate a compatible "ipskx" for each target 222 ciphersuite they offer. For example, importing a key for 223 TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two 224 PSKs, one for HKDF-SHA256 and another for HKDF-SHA384. In contrast, 225 if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are 226 supported, only one derived key is necessary. 228 EPSKs MAY be imported before the start of a connection if the target 229 KDFs, protocols, and context string(s) are known a priori. EPSKs MAY 230 also be imported for early data use if they are bound to protocol 231 settings and configurations that would otherwise be required for 232 early data with normal (ticket-based PSK) resumption. Minimally, 233 that means Application-Layer Protocol Negotiation [RFC7301], QUIC 234 transport parameters (if used for QUIC), and any other relevant 235 parameters that are negotiated for early data MUST be provisioned 236 alongside these EPSKs. 238 4.2. Binder Key Derivation 240 To prevent confusion between imported and non-imported PSKs, imported 241 PSKs change the PSK binder key derivation label. In particular, the 242 standard TLS 1.3 PSK binder key computation is defined as follows: 244 0 245 | 246 v 247 PSK -> HKDF-Extract = Early Secret 248 | 249 +-----> Derive-Secret(., "ext binder" | "res binder", "") 250 | = binder_key 251 V 253 Imported PSKs replace the string "ext binder" with "imp binder" when 254 deriving "binder_key". This means the binder key is computed as 255 follows: 257 0 258 | 259 v 260 PSK -> HKDF-Extract = Early Secret 261 | 262 +-----> Derive-Secret(., "ext binder" 263 | | "res binder" 264 | | "imp binder", "") 265 | = binder_key 266 V 268 This new label ensures a client and server will negotiate use of an 269 external PSK if and only if (a) both endpoints import the PSK or (b) 270 neither endpoint imports the PSK. As "binder_key" is a leaf key, 271 changing its computation does not affect any other key. 273 5. Deprecating Hash Functions 275 If a client or server wish to deprecate a hash function and no longer 276 use it for TLS 1.3, they remove the corresponding KDF from the set of 277 target KDFs used for importing keys. This does not affect the KDF 278 operation used to derive Imported PSKs. 280 6. Incremental Deployment 282 Recall that TLS 1.2 permits computing the TLS PRF with any hash 283 algorithm and PSK. Thus, an EPSK may be used with the same KDF (and 284 underlying HMAC hash algorithm) as TLS 1.3 with importers. However, 285 critically, the derived PSK will not be the same since the importer 286 differentiates the PSK via the identity and target KDF and protocol. 287 Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 288 1.2, and thereby avoid cross-protocol collisions. Note that this 289 does not preclude endpoints from using non-imported PSKs for TLS 1.2. 290 Indeed, this is necessary for incremental deployment. Specifically, 291 existing applications using TLS 1.2 with non-imported PSKs can safely 292 enable TLS 1.3 with imported PSKs in clients and servers without 293 interoperability risk. 295 7. Security Considerations 297 The PSK Importer security goals can be roughly stated as follows: 298 avoid PSK re-use across KDFs while properly authenticating endpoints. 299 When modeled as computational extractors, KDFs assume that input 300 keying material (IKM) is sampled from some "source" probability 301 distribution and that any two IKM values are chosen independently of 302 each other [Kraw10]. This source-independence requirement implies 303 that the same IKM value cannot be used for two different KDFs. 305 PSK-based authentication is functionally equivalent to session 306 resumption in that a connection uses existing key material to 307 authenticate both endpoints. Following the work of [BAA15], this is 308 a form of compound authentication. Loosely speaking, compound 309 authentication is the property that an execution of multiple 310 authentication protocols, wherein at least one is uncompromised, 311 jointly authenticates all protocols. Authenticating with an 312 externally provisioned PSK, therefore, should ideally authenticate 313 both the TLS connection and the external provisioning process. 314 Typically, the external provision process produces a PSK and 315 corresponding context from which the PSK was derived and in which it 316 should be used. If available, this is used as the 317 ImportedIdentity.context value. We refer to an external PSK without 318 such context as "context-free". 320 Thus, in considering the source-independence and compound 321 authentication requirements, the PSK Import interface described in 322 this document aims to achieve the following goals: 324 1. Externally provisioned PSKs imported into a TLS connection 325 achieve compound authentication of the provisioning process and 326 connection. 328 2. Context-free PSKs only achieve authentication within the context 329 of a single connection. 331 3. Imported PSKs are not used as IKM for two different KDFs. 333 4. Imported PSKs do not collide with future protocol versions and 334 KDFs. 336 There is no known interference between the process for computing 337 Imported PSKs from an external PSK and the processing of existing 338 external PSKs used in (D)TLS 1.2 and below. However, only limited 339 analysis has been done, which is an additional reason why 340 applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior 341 versions, even when the importer interface is used in (D)TLS 1.3. 343 The PSK Importer does not prevent applications from constructing non- 344 importer PSK identities that collide with imported PSK identities. 346 8. Privacy Considerations 348 External PSK identities are typically static by design so that 349 endpoints may use them to lookup keying material. However, for some 350 systems and use cases, this identity may become a persistent tracking 351 identifier. 353 9. IANA Considerations 355 This specification introduces a new registry for TLS KDF identifiers, 356 titled "TLS KDF Identifiers", under the existing "Transport Layer 357 Security (TLS) Parameters" heading. 359 The entries in the registry are: 361 +-----------------+--------+-----------+ 362 | KDF Description | Value | Reference | 363 +=================+========+===========+ 364 | Reserved | 0x0000 | N/A | 365 +-----------------+--------+-----------+ 366 | HKDF_SHA256 | 0x0001 | [RFC5869] | 367 +-----------------+--------+-----------+ 368 | HKDF_SHA384 | 0x0002 | [RFC5869] | 369 +-----------------+--------+-----------+ 371 Table 1: Target KDF Registry 373 New target KDF values are allocated according to the following 374 process: 376 * Values in the range 0x0000-0xfeff are assigned via Specification 377 Required [RFC8126]. 379 * Values in the range 0xff00-0xffff are reserved for Private Use 380 [RFC8126]. 382 The procedures for requesting values in the Specification Required 383 space are specified in Section 17 of [RFC8447]. 385 10. References 387 10.1. Normative References 389 [DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 390 Datagram Transport Layer Security (DTLS) Protocol Version 391 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 392 dtls13-39, 2 November 2020, . 395 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 396 and Secure Transport", Work in Progress, Internet-Draft, 397 draft-ietf-quic-transport-32, 20 October 2020, 398 . 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, 403 DOI 10.17487/RFC2119, March 1997, 404 . 406 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 407 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 408 . 410 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 411 (TLS) Protocol Version 1.2", RFC 5246, 412 DOI 10.17487/RFC5246, August 2008, 413 . 415 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 416 Key Derivation Function (HKDF)", RFC 5869, 417 DOI 10.17487/RFC5869, May 2010, 418 . 420 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 421 Writing an IANA Considerations Section in RFCs", BCP 26, 422 RFC 8126, DOI 10.17487/RFC8126, June 2017, 423 . 425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 426 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 427 May 2017, . 429 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 430 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 431 . 433 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 434 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 435 . 437 10.2. Informative References 439 [BAA15] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, 440 "Verified Contributive Channel Bindings for Compound 441 Authentication", DOI 10.14722/ndss.2015.23277, Proceedings 442 2015 Network and Distributed System Security Symposium, 443 2015, . 445 [Kraw10] Krawczyk, H., "Cryptographic Extraction and Key 446 Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 , 447 2010, . 449 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 450 "Transport Layer Security (TLS) Application-Layer Protocol 451 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 452 July 2014, . 454 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 455 with PSK", 2019, . 457 [SHA2] National Institute of Standards and Technology, "Secure 458 Hash Standard", FIPS PUB 180-3 , October 2008. 460 Appendix A. Acknowledgements 462 The authors thank Eric Rescorla and Martin Thomson for discussions 463 that led to the production of this document, as well as Christian 464 Huitema for input regarding privacy considerations of external PSKs. 465 John Mattsson provided input regarding PSK importer deployment 466 considerations. Hugo Krawczyk provided guidance for the security 467 considerations. Martin Thomson, Jonathan Hoyland, Scott Hollenbeck 468 and others all provided reviews, feedback, and suggestions for 469 improving the document. 471 Appendix B. Addressing Selfie 473 The Selfie attack [Selfie] relies on a misuse of the PSK interface. 474 The PSK interface makes the implicit assumption that each PSK is 475 known only to one client and one server. If multiple clients or 476 multiple servers with distinct roles share a PSK, TLS only 477 authenticates the entire group. A node successfully authenticates 478 its peer as being in the group whether the peer is another node or 479 itself. 481 Applications which require authenticating finer-grained roles while 482 still configuring a single shared PSK across all nodes can resolve 483 this mismatch either by exchanging roles over the TLS connection 484 after the handshake or by incorporating the roles of both the client 485 and server into the IPSK context string. For instance, if an 486 application identifies each node by MAC address, it could use the 487 following context string. 489 struct { 490 opaque client_mac<0..2^16-1>; 491 opaque server_mac<0..2^16-1>; 492 } Context; 494 If an attacker then redirects a ClientHello intended for one node to 495 a different node, the receiver will compute a different context 496 string and the handshake will not complete. 498 Note that, in this scenario, there is still a single shared PSK 499 across all nodes, so each node must be trusted not to impersonate 500 another node's role. 502 Authors' Addresses 504 David Benjamin 505 Google, LLC. 507 Email: davidben@google.com 509 Christopher A. Wood 510 Cloudflare 512 Email: caw@heapingbits.net