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