idnits 2.17.1 draft-ietf-tls-external-psk-importer-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 : ---------------------------------------------------------------------------- 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 (May 14, 2019) is 1807 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 310, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-20 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-31 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-03 Summary: 2 errors (**), 0 flaws (~~), 6 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: Experimental C. Wood 5 Expires: November 15, 2019 Apple, Inc. 6 May 14, 2019 8 Importing External PSKs for TLS 9 draft-ietf-tls-external-psk-importer-00 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 http://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 November 15, 2019. 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 (http://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 . . . . . . . . . . . . . . . . . 2 52 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Key Import . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Label Values . . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Deprecating Hash Functions . . . . . . . . . . . . . . . . . 5 57 7. Backwards Compatibility and Incremental Deployment . . . . . 5 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 11.2. Informative References . . . . . . . . . . . . . . . . . 8 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 hash function when used in TLS 1.3, even if they are associated with 82 a different KDF (and hash function) when provisioned. This document 83 specifies an interface by which external PSKs may be imported for use 84 in a TLS 1.3 connection to achieve this goal. In particular, it 85 describes how KDF-bound PSKs can be differentiated by different hash 86 algorithms to produce a set of candidate PSKs, each of which are 87 bound to a specific hash function. This expands what would normally 88 have been a single PSK identity into a set of PSK identities. 89 However, it requires no change to the TLS 1.3 key schedule. 91 2. Conventions and Definitions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 3. Overview 101 Intuitively, key importers mirror the concept of key exporters in TLS 102 in that they diversify a key based on some contextual information 103 before use in a connection. In contrast to key exporters, wherein 104 differentiation is done via an explicit label and context string, the 105 key importer defined herein uses a label and set of hash algorithms 106 to differentiate an external PSK into one or more PSKs for use. 108 Imported keys do not require negotiation for use, as a client and 109 server will not agree upon identities if not imported correctly. 110 Thus, importers induce no protocol changes with the exception of 111 expanding the set of PSK identities sent on the wire. Endpoints may 112 incrementally deploy PSK importer support by offering non-imported 113 keys for TLS versions prior to TLS 1.3. (Negotiation and use of 114 imported PSKs requires both endpoints support the importer API 115 described herein.) 117 3.1. Terminology 119 o External PSK (EPSK): A PSK established or provisioned out-of-band, 120 i.e., not from a TLS connection, which is a tuple of (Base Key, 121 External Identity, KDF). The associated KDF (and hash function) 122 may be undefined. 124 o Base Key: The secret value of an EPSK. 126 o External Identity: The identity of an EPSK. 128 o Imported Identity: The identity of a PSK as sent on the wire. 130 4. Key Import 132 A key importer takes as input an EPSK with external identity 133 'external_identity' and base key 'epsk', as defined in Section 3.1, 134 along with an optional label, and transforms it into a set of PSKs 135 and imported identities for use in a connection based on supported 136 HashAlgorithms. In particular, for each supported HashAlgorithm 137 'hash', the importer constructs an ImportedIdentity structure as 138 follows: 140 struct { 141 opaque external_identity<1...2^16-1>; 142 opaque label<0..2^8-1>; 143 HashAlgorithm hash; 144 } ImportedIdentity; 146 [[TODO: An alternative design might combine label and hash into the 147 same field so that future protocols which don't have a notion of 148 HashAlgorithm don't need this field.]] 150 ImportedIdentity.label MUST be bound to the protocol for which the 151 key is imported. Thus, TLS 1.3 and QUICv1 [I-D.ietf-quic-transport] 152 MUST use "tls13" as the label. Similarly, TLS 1.2 and all prior TLS 153 versions should use "tls12" as ImportedIdentity.label, as well as 154 SHA256 as ImportedIdentity.hash. Note that this means future 155 versions of TLS will increase the number of PSKs derived from an 156 external PSK. 158 A unique and imported PSK (IPSK) with base key 'ipskx' bound to this 159 identity is then computed as follows: 161 epskx = HKDF-Extract(0, epsk) 162 ipskx = HKDF-Expand-Label(epskx, "derived psk", 163 Hash(ImportedIdentity), Hash.length) 165 [[TODO: The length of ipskx MUST match that of the corresponding and 166 supported ciphersuites.]] 168 The hash function used for HKDF [RFC5869] is that which is associated 169 with the external PSK. It is not bound to ImportedIdentity.hash. If 170 no hash function is specified, SHA-256 MUST be used. Differentiating 171 epsk by ImportedIdentity.hash ensures that each imported PSK is only 172 used with at most one hash function, thus satisfying the requirements 173 in [RFC8446]. Endpoints MUST import and derive an ipsk for each hash 174 function used by each ciphersuite they support. For example, 175 importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 176 would yield two PSKs, one for SHA256 and another for SHA384. In 177 contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 178 are supported, only one derived key is necessary. 180 The resulting IPSK base key 'ipskx' is then used as the binder key in 181 TLS 1.3 with identity ImportedIdentity. With knowledge of the 182 supported hash functions, one may import PSKs before the start of a 183 connection. 185 EPSKs may be imported for early data use if they are bound to 186 protocol settings and configurations that would otherwise be required 187 for early data with normal (ticket-based PSK) resumption. Minimally, 188 that means ALPN, QUIC transport settings, etc., must be provisioned 189 alongside these EPSKs. 191 5. Label Values 193 For clarity, the following table specifies PSK importer labels for 194 varying instances of the TLS handshake. 196 +----------------------------------+----------+ 197 | Protocol | Label | 198 +----------------------------------+----------+ 199 | TLS 1.3 [RFC8446] | "tls13" | 200 | | | 201 | QUICv1 [I-D.ietf-quic-transport] | "tls13" | 202 | | | 203 | TLS 1.2 [RFC5246] | "tls12" | 204 | | | 205 | DTLS 1.2 [RFC6347] | "dtls12" | 206 | | | 207 | DTLS 1.3 [I-D.ietf-tls-dtls13] | "dtls13" | 208 +----------------------------------+----------+ 210 6. Deprecating Hash Functions 212 If a client or server wish to deprecate a hash function and no longer 213 use it for TLS 1.3, they may remove this hash function from the set 214 of hashes used during while importing keys. This does not affect the 215 KDF operation used to derive concrete PSKs. 217 7. Backwards Compatibility and Incremental Deployment 219 Recall that TLS 1.2 permits computing the TLS PRF with any hash 220 algorithm and PSK. Thus, an external PSK may be used with the same 221 KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers. 222 However, critically, the derived PSK will not be the same since the 223 importer differentiates the PSK via the identity and hash function. 224 Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 225 1.2, and thereby avoid cross-protocol collisions. Note that this 226 does not preclude endpoints from using non-imported PSKs for TLS 1.2. 227 Indeed, this is necessary for incremental deployment. 229 8. Security Considerations 231 This is a WIP draft and has not yet seen significant security 232 analysis. 234 9. Privacy Considerations 236 DISCLAIMER: This section contains a sketch of a design for protecting 237 external PSK identities. It is not meant to be implementable as 238 written. 240 External PSK identities are typically static by design so that 241 endpoints may use them to lookup keying material. For some systems 242 and use cases, this identity may become a persistent tracking 243 identifier. One mitigation to this problem is encryption. Future 244 drafts may specify a way for encrypting PSK identities using a 245 mechanism similar to that of the Encrypted SNI proposal 246 [I-D.ietf-tls-esni]. Another approach is to replace the identity 247 with an unpredictable or "obfuscated" value derived from the 248 corresponding PSK. One such proposal, derived from a design outlined 249 in [I-D.ietf-dnssd-privacy], is as follows. Let ipskx be the 250 imported PSK with identity ImportedIdentity, and N be a unique nonce 251 of length equal to that of ImportedIdentity.hash. With these values, 252 construct the following "obfuscated" identity: 254 struct { 255 opaque nonce[hash.length]; 256 opaque obfuscated_identity<1..2^16-1>; 257 HashAlgorithm hash; 258 } ObfuscatedIdentity; 260 ObfuscatedIdentity.nonce carries N, 261 ObfuscatedIdentity.obfuscated_identity carries HMAC(ipskx, N), where 262 HMAC is computed with ImportedIdentity.hash, and 263 ObfuscatedIdentity.hash is ImportedIdentity.hash. 265 Upon receipt of such an obfuscated identity, a peer must lookup the 266 corresponding PSK by exhaustively trying to compute 267 ObfuscatedIdentity.obfuscated_identity using ObfuscatedIdentity.nonce 268 and each of its known imported PSKs. If N is chosen in a predictable 269 fashion, e.g., as a timestamp, it may be possible for peers to 270 precompute these obfuscated identities to ease the burden of trial 271 decryption. 273 10. IANA Considerations 275 This document makes no IANA requests. 277 11. References 278 11.1. Normative References 280 [I-D.ietf-quic-transport] 281 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 282 and Secure Transport", draft-ietf-quic-transport-20 (work 283 in progress), April 2019. 285 [I-D.ietf-tls-dtls13] 286 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 287 Datagram Transport Layer Security (DTLS) Protocol Version 288 1.3", draft-ietf-tls-dtls13-31 (work in progress), March 289 2019. 291 [RFC1035] Mockapetris, P., "Domain names - implementation and 292 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 293 November 1987, . 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, 297 DOI 10.17487/RFC2119, March 1997, . 300 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 301 (TLS) Protocol Version 1.2", RFC 5246, 302 DOI 10.17487/RFC5246, August 2008, . 305 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 306 Key Derivation Function (HKDF)", RFC 5869, 307 DOI 10.17487/RFC5869, May 2010, . 310 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 311 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 312 DOI 10.17487/RFC6234, May 2011, . 315 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 316 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 317 January 2012, . 319 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 320 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 321 May 2017, . 323 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 324 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 325 . 327 11.2. Informative References 329 [I-D.ietf-dnssd-privacy] 330 Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- 331 SD", draft-ietf-dnssd-privacy-05 (work in progress), 332 October 2018. 334 [I-D.ietf-tls-esni] 335 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 336 "Encrypted Server Name Indication for TLS 1.3", draft- 337 ietf-tls-esni-03 (work in progress), March 2019. 339 Appendix A. Acknowledgements 341 The authors thank Eric Rescorla and Martin Thomson for discussions 342 that led to the production of this document, as well as Christian 343 Huitema for input regarding privacy considerations of external PSKs. 344 John Mattsson provided input regarding PSK importer deployment 345 considerations. 347 Authors' Addresses 349 David Benjamin 350 Google, LLC. 352 Email: davidben@google.com 354 Christopher A. Wood 355 Apple, Inc. 357 Email: cawood@apple.com