idnits 2.17.00 (12 Aug 2021) /tmp/idnits27361/draft-wood-tls-external-psk-importer-01.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 (March 11, 2019) is 1160 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 274, but no explicit reference was found in the text == Outdated reference: draft-ietf-quic-transport has been published as RFC 9000 == Outdated reference: A later version (-14) exists of draft-ietf-tls-esni-03 Summary: 0 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: Experimental C. Wood 5 Expires: September 12, 2019 Apple, Inc. 6 March 11, 2019 8 Importing External PSKs for TLS 9 draft-wood-tls-external-psk-importer-01 11 Abstract 13 This document describes an interface for importing external PSK (Pre- 14 Shared Key) into TLS. 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 September 12, 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 (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 . . . . . . . . . . . . . . . . . 2 52 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Key Import . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Deprecating Hash Functions . . . . . . . . . . . . . . . . . 5 56 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 5 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 10.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 TLS 1.3 [RFC8446] supports pre-shared key (PSK) resumption, wherein 69 PSKs can be established via session tickets from prior connections or 70 externally via some out-of-band mechanism. The protocol mandates 71 that each PSK only be used with a single hash function. This was 72 done to simplify protocol analysis. TLS 1.2, in contrast, has no 73 such requirement, as a PSK may be used with any hash algorithm and 74 the TLS 1.2 PRF. This means that external PSKs could possibly be re- 75 used in two different contexts with the same hash functions during 76 key derivation. Moreover, it requires external PSKs to be 77 provisioned for specific hash functions. 79 To mitigate these problems, external PSKs can be bound to a specific 80 hash function when used in TLS 1.3, even if they are associated with 81 a different KDF (and hash function) when provisioned. This document 82 specifies an interface by which external PSKs may be imported for use 83 in a TLS 1.3 connection to achieve this goal. In particular, it 84 describes how KDF-bound PSKs can be differentiated by different hash 85 algorithms to produce a set of candidate PSKs, each of which are 86 bound to a specific hash function. This expands what would normally 87 have been a single PSK identity into a set of PSK identities. 88 However, it requires no change to the TLS 1.3 key schedule. 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 Intuitively, key importers mirror the concept of key exporters in TLS 101 in that they diversify a key based on some contextual information 102 before use in a connection. In contrast to key exporters, wherein 103 differentiation is done via an explicit label and context string, the 104 key importer defined herein uses a label and set of hash algorithms 105 to differentiate an external PSK into one or more PSKs for use. 107 Imported keys do not require negotiation for use, as a client and 108 server will not agree upon identities if not imported correctly. 109 Thus, importers induce no protocol changes with the exception of 110 expanding the set of PSK identities sent on the wire. 112 3.1. Terminology 114 o External PSK (EPSK): A PSK established or provisioned out-of-band, 115 i.e., not from a TLS connection, which is a tuple of (Base Key, 116 External Identity, KDF). The associated KDF (and hash function) 117 may be undefined. 119 o Base Key: The secret value of an EPSK. 121 o External Identity: The identity of an EPSK. 123 o Imported Identity: The identity of a PSK as sent on the wire. 125 4. Key Import 127 A key importer takes as input an EPSK with external identity 128 'external_identity' and base key 'epsk', as defined in Section 3.1, 129 along with an optional label, and transforms it into a set of PSKs 130 and imported identities for use in a connection based on supported 131 HashAlgorithms. In particular, for each supported HashAlgorithm 132 'hash', the importer constructs an ImportedIdentity structure as 133 follows: 135 struct { 136 opaque external_identity<1...2^16-1>; 137 opaque label<0..2^8-1>; 138 HashAlgorithm hash; 139 } ImportedIdentity; 141 [[TODO: An alternative design might combine label and hash into the 142 same field so that future protocols which don't have a notion of 143 HashAlgorithm don't need this field.]] 145 ImportedIdentity.label MUST be bound to the protocol for which the 146 key is imported. Thus, TLS 1.3 and QUICv1 [I-D.ietf-quic-transport] 147 MUST use "tls13" as the label. Similarly, TLS 1.2 and all prior TLS 148 versions should use "tls12" as ImportedIdentity.label, as well as 149 SHA256 as ImportedIdentity.hash. Note that this means future 150 versions of TLS will increase the number of PSKs derived from an 151 external PSK. 153 A unique and imported PSK (IPSK) with base key 'ipskx' bound to this 154 identity is then computed as follows: 156 epskx = HKDF-Extract(0, epsk) 157 ipskx = HKDF-Expand-Label(epskx, "derived psk", 158 Hash(ImportedIdentity), Hash.length) 160 [[TODO: The length of ipskx MUST match that of the corresponding and 161 supported ciphersuites.]] 163 The hash function used for HKDF [RFC5869] is that which is associated 164 with the external PSK. It is not bound to ImportedIdentity.hash. If 165 no hash function is specified, SHA-256 MUST be used. Differentiating 166 epsk by ImportedIdentity.hash ensures that each imported PSK is only 167 used with at most one hash function, thus satisfying the requirements 168 in [RFC8446]. Endpoints MUST import and derive an ipsk for each hash 169 function used by each ciphersuite they support. For example, 170 importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 171 would yield two PSKs, one for SHA256 and another for SHA384. In 172 contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 173 are supported, only one derived key is necessary. 175 The resulting IPSK base key 'ipskx' is then used as the binder key in 176 TLS 1.3 with identity ImportedIdentity. With knowledge of the 177 supported hash functions, one may import PSKs before the start of a 178 connection. 180 EPSKs may be imported for early data use if they are bound to 181 protocol settings and configurations that would otherwise be required 182 for early data with normal (ticket-based PSK) resumption. Minimally, 183 that means ALPN, QUIC transport settings, etc., must be provisioned 184 alongside these EPSKs. 186 5. Deprecating Hash Functions 188 If a client or server wish to deprecate a hash function and no longer 189 use it for TLS 1.3, they may remove this hash function from the set 190 of hashes used during while importing keys. This does not affect the 191 KDF operation used to derive concrete PSKs. 193 6. Backwards Compatibility 195 Recall that TLS 1.2 permits computing the TLS PRF with any hash 196 algorithm and PSK. Thus, an external PSK may be used with the same 197 KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers. 198 However, critically, the derived PSK will not be the same since the 199 importer differentiates the PSK via the identity and hash function. 200 Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 201 1.2, and thereby avoid cross-protocol collisions. 203 7. Security Considerations 205 This is a WIP draft and has not yet seen significant security 206 analysis. 208 8. Privacy Considerations 210 DISCLAIMER: This section contains a sketch of a design for protecting 211 external PSK identities. It is not meant to be implementable as 212 written. 214 External PSK identities are typically static by design so that 215 endpoints may use them to lookup keying material. For some systems 216 and use cases, this identity may become a persistent tracking 217 identifier. One mitigation to this problem is encryption. Future 218 drafts may specify a way for encrypting PSK identities using a 219 mechanism similar to that of the Encrypted SNI proposal 220 [I-D.ietf-tls-esni]. Another approach is to replace the identity 221 with an unpredictable or "obfuscated" value derived from the 222 corresponding PSK. One such proposal, derived from a design outlined 223 in [I-D.ietf-dnssd-privacy], is as follows. Let ipskx be the 224 imported PSK with identity ImportedIdentity, and N be a unique nonce 225 of length equal to that of ImportedIdentity.hash. With these values, 226 construct the following "obfuscated" identity: 228 struct { 229 opaque nonce[hash.length]; 230 opaque obfuscated_identity<1..2^16-1>; 231 HashAlgorithm hash; 232 } ObfuscatedIdentity; 234 ObfuscatedIdentity.nonce carries N, 235 ObfuscatedIdentity.obfuscated_identity carries HMAC(ipskx, N), where 236 HMAC is computed with ImportedIdentity.hash, and 237 ObfuscatedIdentity.hash is ImportedIdentity.hash. 239 Upon receipt of such an obfuscated identity, a peer must lookup the 240 corresponding PSK by exhaustively trying to compute 241 ObfuscatedIdentity.obfuscated_identity using ObfuscatedIdentity.nonce 242 and each of its known imported PSKs. If N is chosen in a predictable 243 fashion, e.g., as a timestamp, it may be possible for peers to 244 precompute these obfuscated identities to ease the burden of trial 245 decryption. 247 9. IANA Considerations 249 This document makes no IANA requests. 251 10. References 253 10.1. Normative References 255 [I-D.ietf-quic-transport] 256 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 257 and Secure Transport", draft-ietf-quic-transport-18 (work 258 in progress), January 2019. 260 [RFC1035] Mockapetris, P., "Domain names - implementation and 261 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 262 November 1987, . 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 270 Key Derivation Function (HKDF)", RFC 5869, 271 DOI 10.17487/RFC5869, May 2010, 272 . 274 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 275 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 276 DOI 10.17487/RFC6234, May 2011, 277 . 279 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 280 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 281 May 2017, . 283 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 284 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 285 . 287 10.2. Informative References 289 [I-D.ietf-dnssd-privacy] 290 Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- 291 SD", draft-ietf-dnssd-privacy-05 (work in progress), 292 October 2018. 294 [I-D.ietf-tls-esni] 295 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 296 "Encrypted Server Name Indication for TLS 1.3", draft- 297 ietf-tls-esni-03 (work in progress), March 2019. 299 Appendix A. Acknowledgements 301 The authors thank Eric Rescorla and Martin Thomson for discussions 302 that led to the production of this document, as well as Christian 303 Huitema for input regarding privacy considerations of external PSKs. 305 Authors' Addresses 307 David Benjamin 308 Google, LLC. 310 Email: davidben@google.com 312 Christopher A. Wood 313 Apple, Inc. 315 Email: cawood@apple.com