tls R. Housley
Internet-Draft Vigil Security
Intended status: Informational J. Hoyland
Expires: 10 September 2020 Cloudflare Ltd.
M. Sethi
Ericsson
C.A. Wood
9 March 2020
Guidance for External PSK Usage in TLS
draft-dt-tls-external-psk-guidance-00
Abstract
This document provides usage guidance for external Pre-Shared Keys
(PSKs) in TLS. It lists TLS security properties provided by PSKs
under certain assumptions and demonstrates how violations of these
assumptions lead to attacks. This document also discusses PSK use
cases, provisioning processes, and TLS stack implementation support
in the context of these assumptions. It provides advice for
applications in various use cases to help meet these assumptions.
Note to Readers
Source for this draft and an issue tracker can be found at
https://github.com/tlswg/external-psk-design-team
(https://github.com/tlswg/external-psk-design-team).
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 10 September 2020.
Housley, et al. Expires 10 September 2020 [Page 1]
Internet-Draft Guidance for External PSK Usage in TLS March 2020
Copyright Notice
Copyright (c) 2020 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 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
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. PSK Security Properties . . . . . . . . . . . . . . . . . . . 3
4. Recommendations for External PSK Usage . . . . . . . . . . . 4
5. Privacy Properties . . . . . . . . . . . . . . . . . . . . . 4
6. External PSK Use Cases and Provisioning Processes . . . . . . 5
6.1. Provisioning Examples . . . . . . . . . . . . . . . . . . 6
6.2. Provisioning Constraints . . . . . . . . . . . . . . . . 7
6.3. Stack Interfaces . . . . . . . . . . . . . . . . . . . . 7
6.3.1. PSK Identity encoding and comparison . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document provides usage guidance for external Pre-Shared Keys
(PSKs) in TLS. It lists TLS security properties provided by PSKs
under certain assumptions and demonstrates how violations of these
assumptions lead to attacks. This document also discusses PSK use
cases, provisioning processes, and TLS stack implementation support
in the context of these assumptions. It provides advice for
applications in various use cases to help meet these assumptions.
The guidance provided in this document is applicable across TLS
[RFC8446], DTLS [I-D.ietf-tls-dtls13], and Constrained TLS
[I-D.rescorla-tls-ctls].
Housley, et al. Expires 10 September 2020 [Page 2]
Internet-Draft Guidance for External PSK Usage in TLS March 2020
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. PSK Security Properties
The external PSK authentication mechanism in TLS implicitly assumes
one fundamental property: each PSK is known to exactly one client and
one server, and that these never switch roles. If this assumption is
violated, then the security properties of TLS are severely weakened.
As discussed in Section 6, there are use cases where it is desirable
for multiple clients or multiple servers share a PSK. If this is
done naively by having all members share a common key, then TLS only
authenticates the entire group, and the security of the overall
system is inherently rather brittle. There are a number of obvious
weaknesses here:
1. Any group member can impersonate any other group member.
2. If a group member is compromised, then the attacker can
impersonate any group member (this follows from property (1)).
3. If PSK without DH is used, then compromise of any group member
allows the attacker to passively read all traffic.
In addition to these, a malicious non-member can reroute handshakes
between honest group members to connect them in unintended ways, as
detailed below.
Let the group of peers who know the key be "A", "B", and "C". The
attack proceeds as follows:
1. "A" sends a "ClientHello" to "B".
2. The attacker intercepts the message and redirects it to "C".
3. "C" responds with a "ServerHello" to "A".
4. "A" sends a "Finished" message to "B". "A" has completed the
handshake, ostensibly with "B".
5. The attacker redirects the "Finished" message to "C". "C" has
completed the handshake, ostensibly with "A".
Housley, et al. Expires 10 September 2020 [Page 3]
Internet-Draft Guidance for External PSK Usage in TLS March 2020
This attack violates the peer authentication property, and if "C"
supports a weaker set of cipher suites than "B", this attack also
violates the downgrade protection property. This rerouting is a type
of identity misbinding attack [Krawczyk][Sethi]. Selfie attack
[Selfie] is a special case of the rerouting attack against a group
member that can act both as TLS server and client. In the Selfie
attack, a malicious non-member reroutes a connection from the client
to the server on the same endpoint.
4. Recommendations for External PSK Usage
Applications MUST use external PSKs that adhere to the following
requirements:
1. Each PSK MUST be derived from at least 128 of entropy and MUST be
at least 128-bits long unless the TLS handshake is being used
with a separate key establishment mechanism such as a Diffie-
Hellman exchange. This recommendation protects against passive
attacks using exhaustive search of the PSK.
2. Each PSK MUST NOT be shared between with more than two logical
nodes. As a result, an agent that acts as both a client and a
server MUST use distinct PSKs when acting as the client from when
it is acting as the server. This prevents redirection attacks.
3. Nodes SHOULD use external PSK importers
[I-D.ietf-tls-external-psk-importer] when configuring PSKs for
each pair of TLS client and server. If a distinct importer is
used for each pair, then this satisfies condition (2).
4. Where possible the master PSK (that which is fed into the
importer) SHOULD be deleted after the imported keys have been
generated. This protects an attacker from bootstrapping a
compromise of one node into the ability to attack connections
between any node; otherwise the attacker can recover the master
key and then re-run the importer itself.
5. Privacy Properties
PSK privacy properties are orthogonal to security properties
described in Section 3. Traditionally, TLS does little to keep PSK
identity information private. For example, an adversary learns
information about the external PSK or its identifier by virtue of it
appearing in cleartext in a ClientHello. As a result, a passive
adversary can link two or more connections together that use the same
external PSK on the wire. Applications should take precautions when
using external PSKs if these risks.
Housley, et al. Expires 10 September 2020 [Page 4]
Internet-Draft Guidance for External PSK Usage in TLS March 2020
In addition to linkability in the network, external PSKs are
intrinsically linkable by PSK receivers. Specifically, servers can
link successive connections that use the same external PSK together.
Preventing this type of linkability is out of scope, as PSKs are
explicitly designed to support mutual authentication.
6. External PSK Use Cases and Provisioning Processes
Pre-shared Key (PSK) ciphersuites were first specified for TLS in
2005. Now, PSK is an integral part of the TLS version 1.3
specification [RFC8446]. TLS 1.3 also uses PSKs for session
resumption. It distinguishes these resumption PSKs from external
PSKs which have been provisioned out-of-band (OOB). Below, we list
some example use-cases where pair-wise external PSKs with TLS have
been used for authentication.
* Device-to-device communication with out-of-band synchronized keys.
PSKs provisioned out-of-band for communicating with known
identities, wherein the identity to use is discovered via a
different online protocol.
* Intra-data-center communication. Machine-to-machine communication
within a single data center or PoP may use externally provisioned
PSKs, primarily for the purposes of supporting TLS connections
with fast open (0-RTT data).
* Certificateless server-to-server communication. Machine-to-
machine communication may use externally provisioned PSKs,
primarily for the purposes of establishing TLS connections without
requiring the overhead of provisioning and managing PKI
certificates.
* Internet of Things (IoT) and devices with limited computational
capabilities. [RFC7925] defines TLS and DTLS profiles for
resource-constrained devices and suggests the use of PSK
ciphersuites for compliant devices. The Open Mobile Alliance
Lightweight Machine to Machine Technical Specification [LwM2M]
states that LwM2M servers MUST support the PSK mode of DTLS.
* Use of PSK ciphersuites are optional when securing RADIUS
[RFC2865] with TLS as specified in [RFC6614].
* The Generic Authentication Architecture (GAA) defined by 3GGP
mentions that TLS-PSK can be used between a server and user
equipment for authentication [GAA].
* Smart Cards. The electronic German ID (eID) card supports
Housley, et al. Expires 10 September 2020 [Page 5]
Internet-Draft Guidance for External PSK Usage in TLS March 2020
authentication of a card holder to online services with TLS-PSK
[SmartCard].
There are also use cases where PSKs are shared between more than two
entities. Some examples below (as noted by Akhmetzyanova et
al.[Akhmetzyanova]):
* Group chats. In this use-case, the membership of a group is
confirmed by the possession of a PSK distributed out-of-band to
the group participants. Members can then establish peer-to-peer
connections with each other using the external PSK. It is
important to note that any node of the group can behave as a TLS
client or server.
* Internet of Things (IoT). In this use-case, resource-constrained
IoT devices act as TLS clients and share the same PSK. The
devices use this PSK for quickly establishing connections with a
central server. Such a scheme ensures that the client IoT devices
are legitimate members of the system. To perform rare system
specific operations that require a higher security level, the
central server can request resource-intensive client
authentication with the usage of a certificate after successfully
establishing the connection with a PSK.
6.1. Provisioning Examples
* Many industrial protocols assume that PSKs are distributed and
assigned manually via one of the following approaches: typing the
PSK into the devices, or via web server masks (using a Trust On
First Use (TOFU) approach with a device completely unprotected
before the first login did take place). Many devices have very
limited UI. For example, they may only have a numeric keypad or
even less number of buttons. When the TOFU approach is not
suitable, entering the key would require typing it on a
constrained UI. Moreover, PSK production lacks guidance unlike
user passwords.
* Some devices are provisioned PSKs via an out-of-band, cloud-based
syncing protocol.
* Some secrets may be baked into or hardware or software device
components. Moreover, when this is done at manufacturing time,
secrets may be printed on labels or included in a Bill of
Materials for ease of scanning or import.
Housley, et al. Expires 10 September 2020 [Page 6]
Internet-Draft Guidance for External PSK Usage in TLS March 2020
6.2. Provisioning Constraints
PSK provisioning systems are often constrained in application-
specific ways. For example, although one goal of provisioning is to
ensure that each pair of nodes has a unique key pair, some systems do
not want to distribute pair-wise shared keys to achieve this. As
another example, some systems require the provisioning process to
embed application-specific information in either PSKs or their
identities. Identities may sometimes need to be routable, as is
currently under discussion for EAP-TLS-PSK.
6.3. Stack Interfaces
Most major TLS implementations support external PSKs. And all have a
common interface that applications may use when supplying them for
individual connections. Details about existing stacks at the time of
writing are below.
* OpenSSL and BoringSSL: Applications specify support for external
PSKs via distinct ciphersuites. They also then configure
callbacks that are invoked for PSK selection during the handshake.
These callbacks must provide a PSK identity (as a character
string) and key (as a byte string). (If no identity is provided,
a default one is assumed.) They are typically invoked with a PSK
hint, i.e., the hint provided by the server as per [RFC4279]. The
PSK length is validated to be between [1, 256] bytes upon
selection.
* mbedTLS: Client applications configure PSKs before creating a
connection by providing the PSK identity and value inline.
Servers must implement callbacks similar to that of OpenSSL. PSK
lengths are validate to be between [1, 16] bytes.
* gnuTLS: Applications configure PSK values, either as raw byte
strings or hexadecimal strings. The PSK size is not validated.
* wolfSSL: Applications configure PSKs with callbacks similar to
OpenSSL.
6.3.1. PSK Identity encoding and comparison
Section 5.1 of [RFC4279] mandates that the PSK identity should be
first converted to a character string and then encoded to octets
using UTF-8. This was done to avoid interoperability problems
(especially when the identity is configured by human users). On the
other hand, [RFC7925] advises implementations against assuming any
structured format for PSK identities and recommends byte-by-byte
comparison for any operations. TLS version 1.3 [RFC8446] follows the
Housley, et al. Expires 10 September 2020 [Page 7]
Internet-Draft Guidance for External PSK Usage in TLS March 2020
same practice of specifying the psk identity as a sequence of opaque
bytes (shown as opaque identity<1..2^16-1>).
Other assumptions unique to different stacks are listed below.
* Implementations such as OpenSSL and mbedTLS nonetheless treat
psk_identities as character strings and use string operators such
as "strcmp" on the psk identity.
* Implementations also assign default identities to PSKs (for
example, the string 'Client_identity') if none are configured.
* gnuTLS treats psk identities as usernames.
* OpenSSL servers accept connections from clients that have a valid
PSK even if the identity provided by the client is incorrect.
7. IANA Considerations
This document makes no IANA requests.
8. References
8.1. Normative References
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-35, 7 March 2020, <http://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-35.txt>.
[I-D.ietf-tls-external-psk-importer]
Benjamin, D. and C. Wood, "Importing External PSKs for
TLS", Work in Progress, Internet-Draft, draft-ietf-tls-
external-psk-importer-03, 15 February 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-tls-
external-psk-importer-03.txt>.
[I-D.rescorla-tls-ctls]
Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
1.3", Work in Progress, Internet-Draft, draft-rescorla-
tls-ctls-03, 4 November 2019, <http://www.ietf.org/
internet-drafts/draft-rescorla-tls-ctls-03.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
Housley, et al. Expires 10 September 2020 [Page 8]
Internet-Draft Guidance for External PSK Usage in TLS March 2020
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References
[Akhmetzyanova]
Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A.
Sokolov, "Continuing to reflect on TLS 1.3 with external
PSK", 2019, <https://eprint.iacr.org/2019/421.pdf>.
[GAA] "TR33.919 version 12.0.0 Release 12", n.d.,
<https://www.etsi.org/deliver/
etsi_tr/133900_133999/133919/12.00.00_60/
tr_133919v120000p.pdf>.
[Krawczyk] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and Its Use in the IKE
Protocols", Annual International Cryptology Conference.
Springer, Berlin, Heidelberg , 2003,
<https://link.springer.com/content/
pdf/10.1007/978-3-540-45146-4_24.pdf>.
[LwM2M] "Lightweight Machine to Machine Technical Specification",
n.d.,
<http://www.openmobilealliance.org/release/LightweightM2M/
V1_0-20170208-A/OMA-TS-LightweightM2M-
V1_0-20170208-A.pdf>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[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>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
Housley, et al. Expires 10 September 2020 [Page 9]
Internet-Draft Guidance for External PSK Usage in TLS March 2020
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<https://www.rfc-editor.org/info/rfc6614>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>.
[Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3
with PSK", 2019, <https://eprint.iacr.org/2019/347.pdf>.
[Sethi] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks
on Secure Device Pairing and Bootstrapping", Proceedings
of the 2019 ACM Asia Conference on Computer and
Communications Security , 2019,
<https://arxiv.org/pdf/1902.07550>.
[SmartCard]
"Technical Guideline TR-03112-7 eCard-API-Framework -
Protocols", 2015, <https://www.bsi.bund.de/SharedDocs/Down
loads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03112/
TR-03112-api_teil7.pdf?__blob=publicationFile&v=1>.
Appendix A. Acknowledgements
This document is the output of the TLS External PSK Design Team,
comprised of the following members: Benjamin Beurdouche, Bjoern
Haase, Chris Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan
Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen
Friel, and Russ Housley.
Authors' Addresses
Russ Housley
Vigil Security
Email: housley@vigilsec.com
Jonathan Hoyland
Cloudflare Ltd.
Email: jonathan.hoyland@gmail.com
Mohit Sethi
Housley, et al. Expires 10 September 2020 [Page 10]
Internet-Draft Guidance for External PSK Usage in TLS March 2020
Ericsson
Email: mohit@piuha.net
Christopher A. Wood
Email: caw@heapingbits.net
Housley, et al. Expires 10 September 2020 [Page 11]