Network Working Group D. Benjamin Internet-Draft Google Updates: draft-ietf-tls-tls13 (if June 14, 2018 approved) Intended status: Informational Expires: December 16, 2018 Universal PSKs for TLS draft-davidben-tls-universal-psk-00 Abstract This document describes universal PSKs (Pre-Shared Keys) for TLS. Universal PSKs abstract the TLS 1.3 requirement that each PSK can only be used with a single hash function. This allows PSKs to be provisioned without depending on details of the TLS negotiation, which may change as TLS evolves. Additionally, this document describes a compatibility profile for using TLS 1.3 with PSKs provisioned for the TLS 1.2 PSK mechanism. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 16, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Benjamin Expires December 16, 2018 [Page 1]
Internet-Draft Universal PSKs for TLS June 2018 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Universal PSKs . . . . . . . . . . . . . . . . . . . . . . . 3 3. Compatibility with TLS 1.2 PSKs . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction TLS 1.3 [I-D.ietf-tls-tls13] provides a PSK mechanism to authenticate connections with symmetric keys provisioned externally to TLS. However, unlike the analogous mechanism in earlier versions of TLS [RFC4279], TLS 1.3 PSKs must be constrained to a single hash function. While this constraint simplifies the analysis and does not hinder the resumption use case, it is cumbersome for external PSKs. It ties the PSK provisioning process to details of TLS. The application protocol configuring TLS is usually abstracted from TLS's details. In some cases, the underlying TLS implementation may even be updated without changes to the calling application. Additionally, applications using TLS with PSKs typically require some PSK be negotiated, so parameter selection must follow the hash constraint. In contrast, applications using resumption typically allow the session to be declined in favor of a full handshake, so parameter selection may complete independently of this constraint. Switching the order of the selections for external PSKs adds implementation complexity and complicates analysis of the server's configuration. This document resolves these issues by adding an extra key derivation step to reuse the same secret for all TLS 1.3 KDF hashes, including hashes to be defined in the future. Benjamin Expires December 16, 2018 [Page 2]
Internet-Draft Universal PSKs for TLS June 2018 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Universal PSKs A universal PSK consists of the following: o An identity. This is a public opaque byte string. o A secret. This is a secret opaque byte string. o A KDF hash function for use with HKDF [RFC5869]. Unless otherwise specified, this is SHA-256 [SHS]. In this section's diagrams, "0" refers to a string of zero bytes with length matching the KDF hash. Derive-Secret refers to the corresponding function defined in TLS 1.3, using the KDF hash. A universal PSK is advertised in TLS 1.3 by including the identity and index in the "pre_shared_key" extension of the ClientHello and ServerHello, respectively. The binder value is computed as in TLS 1.3, however, the binder key is derived with the universal PSK's secret and KDF hash as follows: extracted = HKDF-Extract(universal_psk, 0) binder_key = Derive-Secret(extracted, "univ binder", identity) Unlike other PSKs, a universal PSK may be negotiated with any cipher suite, including those using a different KDF hash than the PSK. When negotiated, the universal PSK's secret is used to derive a hash- specific TLS 1.3 PSK as follows: If the negotiated cipher suite uses a SHA-256 KDF hash, the PSK is derived as follows: extracted = HKDF-Extract(universal_psk, 0) psk = Derive-Secret(extracted, "sha256 psk", identity) If the negotiated cipher suite uses a SHA-384 KDF hash, the PSK is derived as follows: extracted = HKDF-Extract(universal_psk, 0) psk = Derive-Secret(extracted, "sha384 psk", identity) Benjamin Expires December 16, 2018 [Page 3]
Internet-Draft Universal PSKs for TLS June 2018 These PSKs are used in the key schedule as specified in TLS 1.3, except that they are not used to derive the "binder_key" value, already derived above. Future KDF hash algorithms added to TLS 1.3 MUST specify how to compute the derived PSK from a universal PSK. Future versions of TLS MUST specify how to negotiate a universal PSK and how to use it when negotiated. Note, however, all versions of TLS using the "pre_shared_key" extension to negotiate PSKs MUST use the same binder derivation, while the derived PSKs SHOULD be version-specific. Universal PSKs are not defined for use with 0-RTT. 0-RTT requires specifying many negotiated TLS parameters, which is not compatible with the goals of this specification. However, a client MAY choose to offer a universal PSK alongside a resumption-based or other 0-RTT- compatible PSK. The universal PSK is then analogous to the full handshake option when resumption is declined. Note that whether a PSK is a universal PSK is not explicitly negotiated in TLS. It is provisioned alongside the secret itself when the PSK is pre-shared. This would typically be specified in the application protocol. 3. Compatibility with TLS 1.2 PSKs Universal PSKs are only defined for use with TLS 1.3 and future versions of TLS. New protocols using TLS and PSKs SHOULD require TLS 1.3 or later. However, this may not be possible for existing protocols already using PSKs with TLS 1.2. This section describes a compatibility profile for upgrading to TLS 1.3. A PSK provisioned for TLS 1.2 and earlier MUST NOT be used either as a universal PSK secret or directly as a TLS 1.3 PSK. This would invalidate security analysis of the two protocols individually. Instead, these PSKs MAY be used to derive a universal PSK. The identity is the TLS 1.2 PSK's identity. The secret is derived using the TLS 1.2 PRF function described in Section 5 of [RFC5246] with SHA-256 as the hash function, as follows: universal_psk = PRF(pre_master_secret, "universal psk", "")[:32] "pre_master_secret" is specified with the structure below, setting "psk" to TLS 1.2 PSK and "other_secret" to a string of all zeroes of the same length as the TLS 1.2 PSK. Benjamin Expires December 16, 2018 [Page 4]
Internet-Draft Universal PSKs for TLS June 2018 struct { opaque other_secret<0..2^16-1> opaque psk<0..2^16-1> } Note this encoding and derivation aligns with the PSK's conversion to a premaster secret and then a master secret in [RFC5246]. Applications using this derivation are necessarily impacted by portions of TLS 1.2. New applications without a TLS 1.2 legacy SHOULD NOT use this derivation and instead SHOULD provision universal PSKs directly. Applications using it SHOULD migrate to this state after migrating to TLS 1.3. 4. Security Considerations The security analysis for TLS 1.3 relies on each PSK having a single use. Using a TLS 1.3 PSK with two different hashes or with TLS 1.2 means the same secret is used with different KDF functions, invalidating that analysis. Universal PSKs instead derive independent PSKs using different KDF labels, so each derived PSK continues to have only a single use. The PSK identity is additionally included in each derivation to give a stronger connection between the identity and PSK. TLS 1.3's analysis also depends on the KDF and MAC used to compute the PSK binder being collision-resistant. This document uses the same derivation as TLS 1.3, but with a different label and initial secret, so the collision-resistance properties carry over. In [RFC5246], TLS 1.2 PSKs are used in premaster secret to master secret derivation. Section 3 aligns with that derivation, using a different label so the secret is derived independently. Note, however, that TLS 1.2 PSKs are not always associated with a single hash function, so they depend on stronger assumptions about hash functions than TLS 1.3 PSKs. The compatibility derivation is unavoidably dependent on this as well. It uses SHA-256, but some TLS 1.2 cipher suites use SHA-384, and earlier versions of TLS use an MD5 and SHA-1 concatenation. Additionally, labels in the TLS 1.2 PRF function are not delimited from the seed parameter when concatenated. The labels in use thus must not only be distinct, but also prefix-free. This document registers its new TLS 1.2 label in the TLS Exporter Label registry. This registry is required by [RFC5705] to be prefix-free. Benjamin Expires December 16, 2018 [Page 5]
Internet-Draft Universal PSKs for TLS June 2018 5. IANA Considerations This document updates the note in the TLS Exporter Label registry <https://www.iana.org/assignments/tls-parameters> to read as follows: Note: (1) These entries are reserved and MUST NOT be used for the purpose described in RFC 5705, in order to avoid confusion with similar, but distinct, use in the referenced document. It additionally registers the label "universal psk". The "Note" column is marked with (1). 6. Acknowledgements The author would like to thank Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and Victor Vasiliev for discussions and feedback which led to this design. 7. Normative References [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-28 (work in progress), March 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <https://www.rfc-editor.org/info/rfc4279>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>. [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>. Benjamin Expires December 16, 2018 [Page 6]
Internet-Draft Universal PSKs for TLS June 2018 [SHS] Dang, Q., "Secure Hash Standard", National Institute of Standards and Technology report, DOI 10.6028/nist.fips.180-4, July 2015. Author's Address David Benjamin Google 355 Main St Cambridge, MA 02142 USA Email: davidben@google.com Benjamin Expires December 16, 2018 [Page 7]