idnits 2.17.1 draft-wood-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 15 characters 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 (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 187, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 201, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls C. Wood 3 Internet-Draft Apple, Inc. 4 Intended status: Experimental October 22, 2018 5 Expires: April 25, 2019 7 Importing External PSKs for TLS 1.3 8 draft-wood-tls-external-psk-importer-00 10 Abstract 12 This document describes an interface for importing external PSK (Pre- 13 Shared Key) 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 http://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 April 25, 2019. 32 Copyright Notice 34 Copyright (c) 2018 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 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 51 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Key Import . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Deprecating Hash Functions . . . . . . . . . . . . . . . . . 4 55 6. TLS 1.2 Compatibility . . . . . . . . . . . . . . . . . . . . 4 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 59 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 TLS 1.3 [RFC8446] supports pre-shared key (PSK) resumption, wherein 65 PSKs can be established via session tickets from prior connections or 66 externally via some out-of-band mechanism. The protocol mandates 67 that each PSK only be used with a single hash function. This was 68 done to simplify protocol analysis. TLS 1.2, in contrast, has no 69 such requirement, as a PSK may be used with any hash algorithm and 70 the TLS 1.2 PRF. This means that external PSKs could possibly be re- 71 used in two different contexts with the same hash functions during 72 key derivation. Moreover, it requires external PSKs to be 73 provisioned for specific hash functions. 75 To mitigate these problems, external PSKs can be bound to a specific 76 hash function when used in TLS 1.3, even if they are associated with 77 a different KDF (and hash function) when provisioned. This document 78 specifies an interface by which external PSKs may be imported for use 79 in a TLS 1.3 connection to achieve this goal. In particular, it 80 describes how KDF-bound PSKs can be differentiated by different hash 81 algorithms to produce a set of candidate PSKs, each of which are 82 bound to a specific hash function. This expands what would normally 83 have been a single PSK identity into a set of PSK identities. 84 However, it requires no change to the TLS 1.3 key schedule. 86 2. Conventions and Definitions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in BCP 91 14 [RFC2119] [RFC8174] when, and only when, they appear in all 92 capitals, as shown here. 94 3. Overview 96 Intuitively, key importers mirror the concept of key exporters in TLS 97 in that they diversify a key based on some contextual information 98 before use in a connection. In contrast to key exporters, wherein 99 differentiation is done via an explicit label and context string, the 100 key importer defined herein uses a label and set of hash algorithms 101 to differentiate an external PSK into one or more PSKs for use. 103 Imported keys do not require negotiation for use, as a client and 104 server will not agree upon identities if not imported correctly. 105 Thus, importers induce no protocol changes with the exception of 106 expanding the set of PSK identities sent on the wire. 108 3.1. Terminology 110 o External PSK (EPSK): A PSK established or provisioned out-of-band, 111 i.e., not from a TLS connection, which is a tuple of (Base Key, 112 External Identity, KDF). The associated KDF (and hash function) 113 may be undefined. 115 o Base Key: The secret value of an EPSK. 117 o External Identity: The identity of an EPSK. 119 o Imported Identity: The identity of a PSK as sent on the wire. 121 4. Key Import 123 A key importer takes as input an EPSK with external identity 124 'external_identity' and base key 'epsk', as defined in Section 3.1, 125 along with an optional label, and transforms it into a set of PSKs 126 and imported identities for use in a connection based on supported 127 HashAlgorithms. In particular, for each supported HashAlgorithm 128 'hash', the importer constructs an ImportedIdentity structure as 129 follows: 131 struct { 132 opaque external_identity<1...2^16-1>; 133 opaque label<0..2^8-1>; 134 HashAlgorithm hash; 135 } ImportedIdentity; 137 A unique and imported PSK (IPSK) with base key 'ipskx' bound to this 138 identity is then computed as follows: 140 epskx = HKDF-Extract(0, epsk) 141 ipskx = HKDF-Expand-Label(epskx, "derived psk", Hash(ImportedIdentity), Hash.length) 142 The hash function used for HKDF [RFC5869] is that which is associated 143 with the external PSK. It is not bound to ImportedIdentity.hash. If 144 no hash function is specified, SHA-256 MUST be used. 146 The resulting IPSK base key 'ipskx' is then used as the binder key in 147 TLS 1.3 with identity ImportedIdentity. 149 With knowledge of the supported hash functions, one may import PSKs 150 before the start of a connection. 152 EPSKs may be imported for early data use if they are bound to 153 protocol settings and configurations that would otherwise be required 154 for early data with normal (ticket-based PSK) resumption. Minimally, 155 that means ALPN, QUIC transport settings, etc., must be provisioned 156 alongside these EPSKs. 158 5. Deprecating Hash Functions 160 If a client or server wish to deprecate a hash function and no longer 161 use it for TLS 1.3, they may remove this hash function from the set 162 of hashes used during while importing keys. This does not affect the 163 KDF operation used to derive concrete PSKs. 165 6. TLS 1.2 Compatibility 167 Key importers do not affect TLS 1.2 in any way. Recall that TLS 1.2 168 permits computing the TLS PRF with any hash algorithm and PSK. Thus, 169 a PSK may be used with the same KDF (and underlying HMAC hash 170 algorithm) as TLS 1.3 with importers. However, critically, the 171 derived PSK will not be the same since the importer differentiates 172 the PSK via the identity and hash function. Thus, TLS 1.3 imported 173 PSKs are distinct from those used in TLS 1.2 and avoid cross-protocol 174 collisions. 176 7. Security Considerations 178 This is a WIP draft and has not yet seen significant security 179 analysis. 181 8. IANA Considerations 183 This document has no IANA requirements. 185 9. Normative References 187 [RFC1035] Mockapetris, P., "Domain names - implementation and 188 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 189 November 1987, . 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, 193 DOI 10.17487/RFC2119, March 1997, . 196 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 197 Key Derivation Function (HKDF)", RFC 5869, 198 DOI 10.17487/RFC5869, May 2010, . 201 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 202 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 203 DOI 10.17487/RFC6234, May 2011, . 206 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 207 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 208 May 2017, . 210 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 211 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 212 . 214 Appendix A. Acknowledgements 216 The authors thank David Benjamin, Eric Rescorla, and Martin Thomson 217 for discussions that led to the production of this document. 219 Author's Address 221 Christopher A. Wood 222 Apple, Inc. 224 Email: cawood@apple.com