idnits 2.17.1 draft-ietf-tls-external-psk-importer-02.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 (November 04, 2019) is 1635 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 317, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'CCB' is defined on line 366, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 ** 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: 3 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. Wood 5 Expires: May 7, 2020 Apple, Inc. 6 November 04, 2019 8 Importing External PSKs for TLS 9 draft-ietf-tls-external-psk-importer-02 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 May 7, 2020. 33 Copyright Notice 35 Copyright (c) 2019 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 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 52 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Key Import . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Deprecating Hash Functions . . . . . . . . . . . . . . . . . 5 56 6. Incremental Deployment . . . . . . . . . . . . . . . . . . . 5 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 10.2. Informative References . . . . . . . . . . . . . . . . . 8 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 64 Appendix B. Addressing Selfie . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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, external PSKs can be bound to a specific 81 KDF and hash function when used in TLS 1.3, even if they are 82 associated with a different hash function when provisioned. This 83 document specifies an interface by which external PSKs may be 84 imported for use in a TLS 1.3 connection to achieve this goal. In 85 particular, it describes how KDF-bound PSKs can be differentiated by 86 the target (D)TLS protocol version and KDF for which the PSK will be 87 used. This produces a set of candidate PSKs, each of which are bound 88 to a specific target protocol and KDF. This expands what would 89 normally have been a single PSK identity into a set of PSK 90 identities. However, importantly, it requires no change to the TLS 91 1.3 key schedule. 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 uses an optional context string along with a target 108 protocol and KDF identifier to differentiate an external PSK into one 109 or more PSKs for use. 111 Imported keys do not require negotiation for use, as a client and 112 server will not agree upon identities if not imported correctly. 113 Thus, importers induce no protocol changes with the exception of 114 expanding the set of PSK identities sent on the wire. Endpoints may 115 incrementally deploy PSK importer support by offering non-imported 116 keys for TLS versions prior to TLS 1.3. Non-imported and imported 117 PSKs are distinct since their identities are different on the wire. 118 See Section 6 for more details. 120 Clients which import external keys TLS MUST NOT use these keys for 121 any other purpose. Moreover, each external PSK MUST be associated 122 with at most one hash function. 124 3.1. Terminology 126 o 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 o Base Key: The secret value of an EPSK. 132 o External Identity: The identity of an EPSK. 134 o Target protocol: The protocol for which a PSK is imported for use. 136 o Target KDF: The KDF for which a PSK is imported for use. 138 o Imported PSK (IPSK): A PSK derived from an EPSK, external 139 identity, optional context string, and target protocol and KDF. 141 o Imported Identity: The identity of an Imported PSK as sent on the 142 wire. 144 4. Key Import 146 A key importer takes as input an EPSK with external identity 147 "external_identity" and base key "epsk", as defined in Section 3.1, 148 along with an optional context, and transforms it into a set of PSKs 149 and imported identities for use in a connection based on supported 150 (target) protocols and KDFs. In particular, for each supported 151 target protocol "target_protocol" and KDF "target_kdf", the importer 152 constructs an ImportedIdentity structure as follows: 154 struct { 155 opaque external_identity<1...2^16-1>; 156 opaque context<0..2^16-1>; 157 uint16 target_protocol; 158 uint16 target_kdf; 159 } ImportedIdentity; 161 The list of "target_kdf" values is maintained by IANA as described in 162 Section 9. External PSKs MUST NOT be imported for versions of (D)TLS 163 1.2 or prior versions. See Section 6 for discussion on how imported 164 PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist 165 for incremental deployment. 167 ImportedIdentity.context MUST include the context used to derive the 168 EPSK, if any exists. For example, ImportedIdentity.context may 169 include information about peer roles or identities to mitigate 170 Selfie-style reflection attacks. See Appendix B for more details. 171 If the EPSK is a key derived from some other protocol or sequence of 172 protocols, ImportedIdentity.context MUST include a channel binding 173 for the deriving protocols [RFC5056]. 175 ImportedIdentity.target_protocol MUST be the (D)TLS protocol version 176 for which the PSK is being imported. For example, TLS 1.3 [RFC8446] 177 and QUICv1 [QUIC] use 0x0304. Note that this means future versions 178 of TLS will increase the number of PSKs derived from an external PSK. 180 An Imported PSK derived from an EPSK with base key 'epsk' bound to 181 this identity is then computed as follows: 183 epskx = HKDF-Extract(0, epsk) 184 ipskx = HKDF-Expand-Label(epskx, "derived psk", 185 Hash(ImportedIdentity), L) 187 L is corresponds to the KDF output length of 188 ImportedIdentity.target_kdf as defined in Section 9. For hash-based 189 KDFs, such as HKDF_SHA256(0x0001), this is the length of the hash 190 function output, i.e., 32 octets. This is required for the IPSK to 191 be of length suitable for supported ciphersuites. 193 The identity of 'ipskx' as sent on the wire is ImportedIdentity. 195 The hash function used for HKDF [RFC5869] is that which is associated 196 with the EPSK. It is not the hash function associated with 197 ImportedIdentity.target_kdf. If no hash function is specified, 198 SHA-256 MUST be used. Diversifying EPSK by 199 ImportedIdentity.target_kdf ensures that an IPSK is only used as 200 input keying material to at most one KDF, thus satisfying the 201 requirements in [RFC8446]. 203 Endpoints generate a compatible ipskx for each target ciphersuite 204 they offer. For example, importing a key for TLS_AES_128_GCM_SHA256 205 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 206 and another for HKDF-SHA384. In contrast, if TLS_AES_128_GCM_SHA256 207 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key 208 is necessary. 210 The resulting IPSK base key 'ipskx' is then used as the binder key in 211 TLS 1.3 with identity ImportedIdentity. With knowledge of the 212 supported KDFs, one may import PSKs before the start of a connection. 214 EPSKs may be imported for early data use if they are bound to 215 protocol settings and configurations that would otherwise be required 216 for early data with normal (ticket-based PSK) resumption. Minimally, 217 that means ALPN, QUIC transport settings, etc., must be provisioned 218 alongside these EPSKs. 220 5. Deprecating Hash Functions 222 If a client or server wish to deprecate a hash function and no longer 223 use it for TLS 1.3, they remove the corresponding KDF from the set of 224 target KDFs used for importing keys. This does not affect the KDF 225 operation used to derive Imported PSKs. 227 6. Incremental Deployment 229 Recall that TLS 1.2 permits computing the TLS PRF with any hash 230 algorithm and PSK. Thus, an EPSK may be used with the same KDF (and 231 underlying HMAC hash algorithm) as TLS 1.3 with importers. However, 232 critically, the derived PSK will not be the same since the importer 233 differentiates the PSK via the identity, target protocol, and target 234 KDF. Thus, PSKs imported for TLS 1.3 are distinct from those used in 235 TLS 1.2, and thereby avoid cross-protocol collisions. Note that this 236 does not preclude endpoints from using non-imported PSKs for TLS 1.2. 237 Indeed, this is necessary for incremental deployment. 239 7. Security Considerations 241 The Key Importer security goals can be roughly stated as follows: 242 avoid PSK re-use across KDFs while properly authenticating endpoints. 243 When modeled as computational extractors, KDFs assume that input 244 keying material (IKM) is sampled from some "source" probability 245 distribution and that any two IKM values are chosen independently of 246 each other [Kraw10]. This source-independence requirement implies 247 that the same IKM value cannot be used for two different KDFs. 249 PSK-based authentication is functionally equivalent to session 250 resumption in that a connection uses existing key material to 251 authenticate both endpoints. Following the work of [BAA15], this is 252 a form of compound authentication. Loosely speaking, compound 253 authentication is the property that an execution of multiple 254 authentication protocols, wherein at least one is uncompromised, 255 jointly authenticates all protocols. Authenticating with an 256 externally provisioned PSK, therefore, should ideally authenticate 257 both the TLS connection and the external provision process. 258 Typically, the external provision process produces a PSK and 259 corresponding context from which the PSK was derived and in wihch it 260 should be used. We refer to an external PSK without such context as 261 "context free". 263 Thus, in considering the source-independence and compound 264 authentication requirements, the Key Import API described in this 265 document aims to achieve the following goals: 267 1. Externally provisioned PSKs imported into TLS achieve compound 268 authentication of the provision step(s) and connection. 270 2. Context-free PSKs only achieve authentication within the context 271 of a single connection. 273 3. Imported PSKs are used as IKM for two different KDFs. 275 4. Imported PSKs do not collide with existing PSKs used for TLS 1.2 276 and below. 278 5. Imported PSKs do not collide with future protocol versions and 279 KDFs. 281 [[ TODO: point to stable reference which describes the analysis of 282 these goals ]] 284 8. Privacy Considerations 286 External PSK identities are typically static by design so that 287 endpoints may use them to lookup keying material. However, for some 288 systems and use cases, this identity may become a persistent tracking 289 identifier. 291 9. IANA Considerations 293 This specification introduces a new registry for TLS KDF identifiers 294 and defines the following target KDF values: 296 +-------------+-----+ | Description | Value | +-------------+-----+ | 297 Reserved | 0x0000 | | | | | HKDF_SHA256 | 0x0001 | | | | | 298 HKDF_SHA384 | 0x0002 | +-------------+-----+ 300 New target KDF values are allocated according to the following 301 process: 303 o Values in the range 0x0000-0xfeff are assigned via Specification 304 Required [RFC8126]. 306 o Values in the range 0xff00-0xffff are reserved for Private Use 307 [RFC8126]. 309 10. References 311 10.1. Normative References 313 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 314 and Secure Transport", draft-ietf-quic-transport-23 (work 315 in progress), September 2019. 317 [RFC1035] Mockapetris, P., "Domain names - implementation and 318 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 319 November 1987, . 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, 323 DOI 10.17487/RFC2119, March 1997, 324 . 326 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 327 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 328 . 330 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 331 (TLS) Protocol Version 1.2", RFC 5246, 332 DOI 10.17487/RFC5246, August 2008, 333 . 335 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 336 Key Derivation Function (HKDF)", RFC 5869, 337 DOI 10.17487/RFC5869, May 2010, 338 . 340 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 341 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 342 DOI 10.17487/RFC6234, May 2011, 343 . 345 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 346 Writing an IANA Considerations Section in RFCs", BCP 26, 347 RFC 8126, DOI 10.17487/RFC8126, June 2017, 348 . 350 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 351 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 352 May 2017, . 354 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 355 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 356 . 358 10.2. Informative References 360 [BAA15] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, 361 "Verified Contributive Channel Bindings for Compound 362 Authentication", Proceedings 2015 Network and Distributed 363 System Security Symposium, DOI 10.14722/ndss.2015.23277, 364 2015. 366 [CCB] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, 367 "Verified Contributive Channel Bindings for Compound 368 Authentication", Proceedings 2015 Network and Distributed 369 System Security Symposium, DOI 10.14722/ndss.2015.23277, 370 2015. 372 [Kraw10] Krawczyk, H., "Cryptographic Extraction and Key 373 Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 , 374 2010, . 376 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 377 with PSK", 2019, . 379 Appendix A. Acknowledgements 381 The authors thank Eric Rescorla and Martin Thomson for discussions 382 that led to the production of this document, as well as Christian 383 Huitema for input regarding privacy considerations of external PSKs. 384 John Mattsson provided input regarding PSK importer deployment 385 considerations. Hugo Krawczyk provided guidance for the security 386 considerations. 388 Appendix B. Addressing Selfie 390 The Selfie attack [Selfie] relies on a misuse of the PSK interface. 391 The PSK interface makes the implicit assumption that each PSK is 392 known only to one client and one server. If multiple clients or 393 multiple servers with distinct roles share a PSK, TLS only 394 authenticates the entire group. A node successfully authenticates 395 its peer as being in the group whether the peer is another node or 396 itself. 398 Applications which require authenticating finer-grained roles while 399 still configuring a single shared PSK across all nodes can resolve 400 this mismatch either by exchanging roles over the TLS connection 401 after the handshake or by incorporating the roles of both the client 402 and server into the IPSK context string. For instance, if an 403 application identifies each node by MAC address, it could use the 404 following context string. 406 struct { 407 opaque client_mac<0..2^16-1>; 408 opaque server_mac<0..2^16-1>; 409 } Context; 411 If an attacker then redirects a ClientHello intended for one node to 412 a different node, the receiver will compute a different context 413 string and the handshake will not complete. 415 Note that, in this scenario, there is still a single shared PSK 416 across all nodes, so each node must be trusted not to impersonate 417 another node's role. 419 Authors' Addresses 421 David Benjamin 422 Google, LLC. 424 Email: davidben@google.com 425 Christopher A. Wood 426 Apple, Inc. 428 Email: cawood@apple.com