draft-ietf-tls-external-psk-importer-01.txt   draft-ietf-tls-external-psk-importer-02.txt 
tls D. Benjamin tls D. Benjamin
Internet-Draft Google, LLC. Internet-Draft Google, LLC.
Intended status: Standards Track C. Wood Intended status: Standards Track C. Wood
Expires: April 4, 2020 Apple, Inc. Expires: May 7, 2020 Apple, Inc.
October 02, 2019 November 04, 2019
Importing External PSKs for TLS Importing External PSKs for TLS
draft-ietf-tls-external-psk-importer-01 draft-ietf-tls-external-psk-importer-02
Abstract Abstract
This document describes an interface for importing external PSK (Pre- This document describes an interface for importing external PSK (Pre-
Shared Key) into TLS 1.3. Shared Key) into TLS 1.3.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
4. Key Import . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Key Import . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Deprecating Hash Functions . . . . . . . . . . . . . . . . . 5 5. Deprecating Hash Functions . . . . . . . . . . . . . . . . . 5
6. Incremental Deployment . . . . . . . . . . . . . . . . . . . 5 6. Incremental Deployment . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
Appendix B. Addressing Selfie . . . . . . . . . . . . . . . . . 8 Appendix B. Addressing Selfie . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
TLS 1.3 [RFC8446] supports pre-shared key (PSK) authentication, TLS 1.3 [RFC8446] supports pre-shared key (PSK) authentication,
wherein PSKs can be established via session tickets from prior wherein PSKs can be established via session tickets from prior
connections or externally via some out-of-band mechanism. The connections or externally via some out-of-band mechanism. The
protocol mandates that each PSK only be used with a single hash protocol mandates that each PSK only be used with a single hash
function. This was done to simplify protocol analysis. TLS 1.2 function. This was done to simplify protocol analysis. TLS 1.2
[RFC5246], in contrast, has no such requirement, as a PSK may be used [RFC5246], in contrast, has no such requirement, as a PSK may be used
with any hash algorithm and the TLS 1.2 PRF. This means that with any hash algorithm and the TLS 1.2 PRF. This means that
skipping to change at page 6, line 9 skipping to change at page 6, line 9
underlying HMAC hash algorithm) as TLS 1.3 with importers. However, underlying HMAC hash algorithm) as TLS 1.3 with importers. However,
critically, the derived PSK will not be the same since the importer critically, the derived PSK will not be the same since the importer
differentiates the PSK via the identity, target protocol, and target differentiates the PSK via the identity, target protocol, and target
KDF. Thus, PSKs imported for TLS 1.3 are distinct from those used in KDF. Thus, PSKs imported for TLS 1.3 are distinct from those used in
TLS 1.2, and thereby avoid cross-protocol collisions. Note that this TLS 1.2, and thereby avoid cross-protocol collisions. Note that this
does not preclude endpoints from using non-imported PSKs for TLS 1.2. does not preclude endpoints from using non-imported PSKs for TLS 1.2.
Indeed, this is necessary for incremental deployment. Indeed, this is necessary for incremental deployment.
7. Security Considerations 7. Security Considerations
DISCLAIMER: This is a WIP draft and has not yet seen significant The Key Importer security goals can be roughly stated as follows:
security analysis. avoid PSK re-use across KDFs while properly authenticating endpoints.
When modeled as computational extractors, KDFs assume that input
keying material (IKM) is sampled from some "source" probability
distribution and that any two IKM values are chosen independently of
each other [Kraw10]. This source-independence requirement implies
that the same IKM value cannot be used for two different KDFs.
PSK-based authentication is functionally equivalent to session
resumption in that a connection uses existing key material to
authenticate both endpoints. Following the work of [BAA15], this is
a form of compound authentication. Loosely speaking, compound
authentication is the property that an execution of multiple
authentication protocols, wherein at least one is uncompromised,
jointly authenticates all protocols. Authenticating with an
externally provisioned PSK, therefore, should ideally authenticate
both the TLS connection and the external provision process.
Typically, the external provision process produces a PSK and
corresponding context from which the PSK was derived and in wihch it
should be used. We refer to an external PSK without such context as
"context free".
Thus, in considering the source-independence and compound
authentication requirements, the Key Import API described in this
document aims to achieve the following goals:
1. Externally provisioned PSKs imported into TLS achieve compound
authentication of the provision step(s) and connection.
2. Context-free PSKs only achieve authentication within the context
of a single connection.
3. Imported PSKs are used as IKM for two different KDFs.
4. Imported PSKs do not collide with existing PSKs used for TLS 1.2
and below.
5. Imported PSKs do not collide with future protocol versions and
KDFs.
[[ TODO: point to stable reference which describes the analysis of
these goals ]]
8. Privacy Considerations 8. Privacy Considerations
External PSK identities are typically static by design so that External PSK identities are typically static by design so that
endpoints may use them to lookup keying material. However, for some endpoints may use them to lookup keying material. However, for some
systems and use cases, this identity may become a persistent tracking systems and use cases, this identity may become a persistent tracking
identifier. identifier.
9. IANA Considerations 9. IANA Considerations
skipping to change at page 7, line 44 skipping to change at page 8, line 35
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
10.2. Informative References 10.2. Informative References
[BAA15] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti,
"Verified Contributive Channel Bindings for Compound
Authentication", Proceedings 2015 Network and Distributed
System Security Symposium, DOI 10.14722/ndss.2015.23277,
2015.
[CCB] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, [CCB] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti,
"Verified Contributive Channel Bindings for Compound "Verified Contributive Channel Bindings for Compound
Authentication", Proceedings 2015 Network and Distributed Authentication", Proceedings 2015 Network and Distributed
System Security Symposium, DOI 10.14722/ndss.2015.23277, System Security Symposium, DOI 10.14722/ndss.2015.23277,
2015. 2015.
[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 ,
2010, <https://eprint.iacr.org/2010/264>.
[Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3
with PSK", 2019, <https://eprint.iacr.org/2019/347.pdf>. with PSK", 2019, <https://eprint.iacr.org/2019/347.pdf>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors thank Eric Rescorla and Martin Thomson for discussions The authors thank Eric Rescorla and Martin Thomson for discussions
that led to the production of this document, as well as Christian that led to the production of this document, as well as Christian
Huitema for input regarding privacy considerations of external PSKs. Huitema for input regarding privacy considerations of external PSKs.
John Mattsson provided input regarding PSK importer deployment John Mattsson provided input regarding PSK importer deployment
considerations. Hugo Krawczyk provided guidance for the security
considerations. considerations.
Appendix B. Addressing Selfie Appendix B. Addressing Selfie
The Selfie attack [Selfie] relies on a misuse of the PSK interface. The Selfie attack [Selfie] relies on a misuse of the PSK interface.
The PSK interface makes the implicit assumption that each PSK is The PSK interface makes the implicit assumption that each PSK is
known only to one client and one server. If multiple clients or known only to one client and one server. If multiple clients or
multiple servers with distinct roles share a PSK, TLS only multiple servers with distinct roles share a PSK, TLS only
authenticates the entire group. A node successfully authenticates authenticates the entire group. A node successfully authenticates
its peer as being in the group whether the peer is another node or its peer as being in the group whether the peer is another node or
 End of changes. 8 change blocks. 
14 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/