< draft-ietf-tls-tls13-cert-with-extern-psk-03.txt   draft-ietf-tls-tls13-cert-with-extern-psk-04.txt >
Network Working Group R. Housley Network Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Intended status: Experimental November 17, 2019 Intended status: Experimental December 19, 2019
Expires: May 20, 2020 Expires: June 21, 2020
TLS 1.3 Extension for Certificate-based Authentication with an External TLS 1.3 Extension for Certificate-based Authentication with an External
Pre-Shared Key Pre-Shared Key
draft-ietf-tls-tls13-cert-with-extern-psk-03 draft-ietf-tls-tls13-cert-with-extern-psk-04
Abstract Abstract
This document specifies a TLS 1.3 extension that allows a server to This document specifies a TLS 1.3 extension that allows a server to
authenticate with a combination of a certificate and an external pre- authenticate with a combination of a certificate and an external pre-
shared key (PSK). shared key (PSK).
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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 May 20, 2020. This Internet-Draft will expire on June 21, 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 3, line 25 skipping to change at page 3, line 25
ClientHello message. The "tls_cert_with_extern_psk" extension MUST ClientHello message. The "tls_cert_with_extern_psk" extension MUST
be accompanied by the "key_share", "psk_key_exchange_modes", and be accompanied by the "key_share", "psk_key_exchange_modes", and
"pre_shared_key" extensions. The client MAY also find it useful to "pre_shared_key" extensions. The client MAY also find it useful to
include the "supported_groups" extension. Since the include the "supported_groups" extension. Since the
"tls_cert_with_extern_psk" extension is intended to be used only with "tls_cert_with_extern_psk" extension is intended to be used only with
initial handshakes, it MUST NOT be sent alongside the "early_data" initial handshakes, it MUST NOT be sent alongside the "early_data"
extension. These extensions are all described in Section 4.2 of extension. These extensions are all described in Section 4.2 of
[RFC8446], which also requires the "pre_shared_key" extension to be [RFC8446], which also requires the "pre_shared_key" extension to be
the last extension in the ClientHello message. the last extension in the ClientHello message.
If the client includes both the "tls_cert_with_extern_psk" extension
and the "early_data" extension, then the server MUST terminate the
connection with an "illegal_parameter" alert.
If the server is willing to use one of the external PSKs listed in If the server is willing to use one of the external PSKs listed in
the "pre_shared_key" extension and perform certificate-based the "pre_shared_key" extension and perform certificate-based
authentication, then the server includes the authentication, then the server includes the
"tls_cert_with_extern_psk" extension in the ServerHello message. The "tls_cert_with_extern_psk" extension in the ServerHello message. The
"tls_cert_with_extern_psk" extension MUST be accompanied by the "tls_cert_with_extern_psk" extension MUST be accompanied by the
"key_share" and "pre_shared_key" extensions. If none of the external "key_share" and "pre_shared_key" extensions. If none of the external
PSKs in the list provided by the client is acceptable to the server, PSKs in the list provided by the client is acceptable to the server,
then the "tls_cert_with_extern_psk" extension is omitted from the then the "tls_cert_with_extern_psk" extension is omitted from the
ServerHello message. ServerHello message.
skipping to change at page 4, line 24 skipping to change at page 4, line 28
in any other message, then the implementation MUST abort the in any other message, then the implementation MUST abort the
handshake with an "illegal_parameter" alert. handshake with an "illegal_parameter" alert.
The general extension mechanisms enable clients and servers to The general extension mechanisms enable clients and servers to
negotiate the use of specific extensions. Clients request extended negotiate the use of specific extensions. Clients request extended
functionality from servers with the extensions field in the functionality from servers with the extensions field in the
ClientHello message. If the server responds with a HelloRetryRequest ClientHello message. If the server responds with a HelloRetryRequest
message, then the client sends another ClientHello message as message, then the client sends another ClientHello message as
described in Section 4.1.2 of [RFC8446], including the same described in Section 4.1.2 of [RFC8446], including the same
"tls_cert_with_extern_psk" extension as the original ClientHello "tls_cert_with_extern_psk" extension as the original ClientHello
message or abort the handshake. message or aborts the handshake.
Many server extensions are carried in the EncryptedExtensions Many server extensions are carried in the EncryptedExtensions
message; however, the "tls_cert_with_extern_psk" extension is carried message; however, the "tls_cert_with_extern_psk" extension is carried
in the ServerHello message. Successful negotiation of the in the ServerHello message. Successful negotiation of the
"tls_cert_with_extern_psk" extension affects the key used for "tls_cert_with_extern_psk" extension affects the key used for
encryption, so it cannot be carried in the EncryptedExtensions encryption, so it cannot be carried in the EncryptedExtensions
message. Therefore, the "tls_cert_with_extern_psk" extension is only message. Therefore, the "tls_cert_with_extern_psk" extension is only
present in the ServerHello message if the server recognizes the present in the ServerHello message if the server recognizes the
"tls_cert_with_extern_psk" extension and the server possesses one of "tls_cert_with_extern_psk" extension and the server possesses one of
the external PSKs offered by the client in the "pre_shared_key" the external PSKs offered by the client in the "pre_shared_key"
skipping to change at page 5, line 26 skipping to change at page 5, line 29
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: Empty; case client_hello: Empty;
case server_hello: Empty; case server_hello: Empty;
}; };
} CertWithExternPSK; } CertWithExternPSK;
5.1. Companion Extensions 5.1. Companion Extensions
Section 4 lists the extensions that are required to accompany the Section 4 lists the extensions that are required to accompany the
"tls_cert_with_extern_psk" extension. Most of those extension are "tls_cert_with_extern_psk" extension. Most of those extension are
not impacted in any way. This section discusses the impacts on the used in the usual manner. This section discusses the impacts on the
other extensions. extensions that are affected the presence of the
"tls_cert_with_extern_psk" extension.
The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of
[RFC8446]. The "psk_key_exchange_modes" extension restricts both the [RFC8446]. The "psk_key_exchange_modes" extension restricts the use
use of PSKs offered in this ClientHello and those which the server of both the PSKs offered in this ClientHello and those that the
might supply via a subsequent NewSessionTicket. As a result, when server might supply via a subsequent NewSessionTicket. As a result,
the "psk_key_exchange_modes" extension is included in the ClientHello when the "psk_key_exchange_modes" extension is included in the
message, clients MUST include psk_dhe_ke mode. In addition, clients ClientHello message, clients MUST include psk_dhe_ke mode. In
MAY also include psk_ke mode to support a subsequent addition, clients MAY also include psk_ke mode to support a
NewSessionTicket. When the "psk_key_exchange_modes" extension is subsequent NewSessionTicket. When the "psk_key_exchange_modes"
included in the ServerHello message, servers MUST select the extension is included in the ServerHello message, servers MUST select
psk_dhe_ke mode for the initial handshake. Servers MUST select a key the psk_dhe_ke mode for the initial handshake. Servers MUST select a
exchange mode that is listed by the client for subsequent handshakes key exchange mode that is listed by the client for subsequent
that include the resumption PSK from the initial handshake. handshakes that include the resumption PSK from the initial
handshake.
The "pre_shared_key" extension is defined in Section 4.2.11 of The "pre_shared_key" extension is defined in Section 4.2.11 of
[RFC8446]. The syntax is repeated below for convenience. All of the [RFC8446]. The syntax is repeated below for convenience. All of the
listed PSKs MUST be external PSKs. If a resumption PSK is listed listed PSKs MUST be external PSKs. If a resumption PSK is listed
along with the "tls_cert_with_extern_psk" extension, the server MUST along with the "tls_cert_with_extern_psk" extension, the server MUST
abort the handshake with an "illegal_parameter" alert. abort the handshake with an "illegal_parameter" alert.
struct { struct {
opaque identity<1..2^16-1>; opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age; uint32 obfuscated_ticket_age;
skipping to change at page 6, line 39 skipping to change at page 6, line 42
is willing to negotiate with the server. Each external PSK has an is willing to negotiate with the server. Each external PSK has an
associated identity that is known to the client and the server; the associated identity that is known to the client and the server; the
associated identities may be know to other parties as well. In associated identities may be know to other parties as well. In
addition, the binder validation (see below) confirms that the client addition, the binder validation (see below) confirms that the client
and server have the same key associated with the identity. and server have the same key associated with the identity.
The obfuscated_ticket_age is not used for external PSKs. As stated The obfuscated_ticket_age is not used for external PSKs. As stated
in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0, in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0,
and servers MUST ignore the value. and servers MUST ignore the value.
The binders are a series of HMAC values, one for each external PSK The binders are a series of HMAC [RFC2104] values, one for each
offered by the client, in the same order as the identities list. The external PSK offered by the client, in the same order as the
HMAC value is computed using the binder_key, which is derived from identities list. The HMAC value is computed using the binder_key,
the external PSK, and a partial transcript of the current handshake. which is derived from the external PSK, and a partial transcript of
Generation of the binder_key from the external PSK is described in the current handshake. Generation of the binder_key from the
Section 7.1 of [RFC8446]. The partial transcript of the current external PSK is described in Section 7.1 of [RFC8446]. The partial
handshake includes a partial ClientHello up to and including the transcript of the current handshake includes a partial ClientHello up
PreSharedKeyExtension.identities field as described in to and including the PreSharedKeyExtension.identities field as
Section 4.2.11.2 of [RFC8446]. described in Section 4.2.11.2 of [RFC8446].
The selected_identity contains the index of the external PSK identity The selected_identity contains the index of the external PSK identity
that the server selected from the list offered by the client. As that the server selected from the list offered by the client. As
described in Section 4.2.11.2 of [RFC8446], the server MUST validate described in Section 4.2.11.2 of [RFC8446], the server MUST validate
the binder value that corresponds to the selected external PSK, and the binder value that corresponds to the selected external PSK, and
if the binder does not validate, the server MUST abort the handshake if the binder does not validate, the server MUST abort the handshake
with an "illegal_parameter" alert. with an "illegal_parameter" alert.
5.2. Authentication 5.2. Authentication
skipping to change at page 7, line 41 skipping to change at page 7, line 47
and the (EC)DHE shared secret value. and the (EC)DHE shared secret value.
If the client and the server have different values associated with If the client and the server have different values associated with
the selected external PSK identifier, then the client and the server the selected external PSK identifier, then the client and the server
will compute different values for every entry in the key schedule, will compute different values for every entry in the key schedule,
which will lead to the client aborting the handshake with a which will lead to the client aborting the handshake with a
"decrypt_error" alert. "decrypt_error" alert.
6. IANA Considerations 6. IANA Considerations
IANA is requested to update the TLS ExtensionType Registry to include IANA is requested to update the TLS ExtensionType Registry [IANA] to
"tls_cert_with_extern_psk" with a value of TBD and the list of include "tls_cert_with_extern_psk" with a value of TBD and the list
messages "CH, SH" in which the "tls_cert_with_extern_psk" extension of messages "CH, SH" in which the "tls_cert_with_extern_psk"
may appear. extension may appear.
7. Security Considerations 7. Security Considerations
The Security Considerations in [RFC8446] remain relevant. The Security Considerations in [RFC8446] remain relevant.
TLS 1.3 [RFC8446] does not permit the server to send a TLS 1.3 [RFC8446] does not permit the server to send a
CertificateRequest message when a PSK is being used. This CertificateRequest message when a PSK is being used. This
restriction is removed when the "tls_cert_with_extern_psk" extension restriction is removed when the "tls_cert_with_extern_psk" extension
is offered by the client and accepted by the server. However, TLS is offered by the client and accepted by the server. However, TLS
1.3 does not permit an external PSK to be used in the same fashion as 1.3 does not permit an external PSK to be used in the same fashion as
skipping to change at page 8, line 28 skipping to change at page 8, line 35
Doing so may allow an eavesdropper to correlate the connections, Doing so may allow an eavesdropper to correlate the connections,
making the content vulnerable to the future invention of a large- making the content vulnerable to the future invention of a large-
scale quantum computer. scale quantum computer.
Implementations must generate external PSKs with a secure key Implementations must generate external PSKs with a secure key
management technique, such as pseudo-random generation of the key or management technique, such as pseudo-random generation of the key or
derivation of the key from one or more other secure keys. The use of derivation of the key from one or more other secure keys. The use of
inadequate pseudo-random number generators (PRNGs) to generate inadequate pseudo-random number generators (PRNGs) to generate
external PSKs can result in little or no security. An attacker may external PSKs can result in little or no security. An attacker may
find it much easier to reproduce the PRNG environment that produced find it much easier to reproduce the PRNG environment that produced
the external PSKs and searching the resulting small set of the external PSKs and search the resulting small set of
possibilities, rather than brute force searching the whole key space. possibilities, rather than brute-force searching the whole key space.
The generation of quality random numbers is difficult. [RFC4086] The generation of quality random numbers is difficult. [RFC4086]
offers important guidance in this area. offers important guidance in this area.
If the external PSK is known to any party other than the client and If the external PSK is known to any party other than the client and
the server, then the external PSK MUST NOT be the sole basis for the server, then the external PSK MUST NOT be the sole basis for
authentication. The reasoning is explained in [K2016] (see authentication. The reasoning is explained in Section 4.2 of
Section 4.2). When this extension is used, authentication is based [K2016]. When this extension is used, authentication is based on
on certificates, not the external PSK. certificates, not the external PSK.
In this extension, the external PSK preserves secrecy if the (EC)DH In this extension, the external PSK preserves secrecy if the (EC)DH
key agreement is ever broken by cryptanalysis or the future invention key agreement is ever broken by cryptanalysis or the future invention
of a large-scale quantum computer. As long as the attacker does not of a large-scale quantum computer. As long as the attacker does not
know the PSK and the key derivation algorithm remains unbroken, the know the PSK and the key derivation algorithm remains unbroken, the
attacker cannot derive the session secrets even if they are able to attacker cannot derive the session secrets even if they are able to
compute the (EC)DH shared secret. compute the (EC)DH shared secret.
TLS 1.3 key derivation makes use of the HKDF algorithm, which depends TLS 1.3 key derivation makes use of the HKDF algorithm, which depends
upon the HMAC construction and a hash function. This extension upon the HMAC [RFC2104] construction and a hash function. This
provides the desired protection for the session secrets as long as extension provides the desired protection for the session secrets as
HMAC with the selected hash function is a pseudorandom function (PRF) long as HMAC with the selected hash function is a pseudorandom
[GGM1986]. function (PRF) [GGM1986].
In the future, if the (EC)DH key agreement is broken by cryptanalysis In the future, if the (EC)DH key agreement is broken by cryptanalysis
or the invention of a large-scale quantum computer, the forward or the invention of a large-scale quantum computer, the forward
secrecy advantages traditionally associated with ephemeral (EC)DH secrecy advantages traditionally associated with ephemeral (EC)DH
keys will no longer be relevant. Although the ephemeral private keys keys will no longer be relevant. Although the ephemeral private keys
used during a given TLS session would be destroyed at the end of a used during a given TLS session would be destroyed at the end of a
session, preventing the attacker from later accessing them, the session, preventing the attacker from later accessing them, the
private keys would nevertheless be recoverable due to the break in private keys would nevertheless be recoverable due to the break in
the algorithm. A more general notion of "secrecy after key material the algorithm. A more general notion of "secrecy after key material
is destroyed" would still be achievable using external PSKs, of is destroyed" would still be achievable using external PSKs, of
course, provided that they are managed in a way that ensures their course, provided that they are managed in a way that ensures their
destruction when they are no longer needed, and with the assumption destruction when they are no longer needed, and with the assumption
that the algorithms that use the external PSKs remain quantum-safe. that the algorithms that use the external PSKs remain quantum-safe.
This specification does not require that external PSK is known only This specification does not require that the external PSK is known
by the client and server. The external PSK may be known to a group. only by the client and server. The external PSK may be known to a
Since authentication depends on the public key in a certificate, group. Since authentication depends on the public key in a
knowledge of the external PSK by other parties does not enable certificate, knowledge of the external PSK by other parties does not
impersonation. Since confidentiality depends on the shared secret enable impersonation. Since confidentiality depends on the shared
from (EC)DH, knowledge of the external PSK by other parties does not secret from (EC)DH, knowledge of the external PSK by other parties
enable eavesdropping. However, group members can record the traffic does not enable eavesdropping. However, group members can record the
of other members, and then decrypt it if they ever gain access to a traffic of other members, and then decrypt it if they ever gain
large-scale quantum computer. Also, when many parties know the access to a large-scale quantum computer. Also, when many parties
external PSK, there are many opportunities for theft of the external know the external PSK, there are many opportunities for theft of the
PSK by an attacker. Once an attacker has the external PSK, they can external PSK by an attacker. Once an attacker has the external PSK,
decrypt stored traffic if they ever gain access to a large-scale they can decrypt stored traffic if they ever gain access to a large-
quantum computer in the same manner as a legitimate group member. scale quantum computer in the same manner as a legitimate group
member.
TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are
bound to a specific hash function and KDF. By contrast, TLS 1.2 bound to a specific hash function and KDF. By contrast, TLS 1.2
[RFC5246] allows PSKs to be used with any hash function and the TLS [RFC5246] allows PSKs to be used with any hash function and the TLS
1.2 PRF. Thus, the safest approach is to use a PSK exclusively with 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with
TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a
PSK for exclusive use with TLS 1.2 and derive another PSK for PSK for exclusive use with TLS 1.2 and derive another PSK for
exclusive use with TLS 1.3 using the mechanism specified in exclusive use with TLS 1.3 using the mechanism specified in
[I-D.ietf-tls-external-psk-importer]. [I-D.ietf-tls-external-psk-importer].
skipping to change at page 10, line 27 skipping to change at page 10, line 34
This extension makes use of external PSKs to improve resilience This extension makes use of external PSKs to improve resilience
against attackers that gain access to a large-scale quantum computer against attackers that gain access to a large-scale quantum computer
in the future. This extension is always accompanied by the in the future. This extension is always accompanied by the
"pre_shared_key" extension to provide the PSK identities in plaintext "pre_shared_key" extension to provide the PSK identities in plaintext
in the ClientHello message. Passive observation of the these PSK in the ClientHello message. Passive observation of the these PSK
identities will aid an attacker to track users of this extension. identities will aid an attacker to track users of this extension.
9. Acknowledgments 9. Acknowledgments
Many thanks to Liliya Akhmetzyanova, Christian Huitema, Ben Kaduk, Many thanks to Liliya Akhmetzyanova, Christian Huitema, Ben Kaduk,
Geoffrey Keating, Hugo Krawczyk, Nikos Mavrogiannopoulos, Nick Geoffrey Keating, Hugo Krawczyk, Mirja Kuehlewind, Nikos
Sullivan, Martin Thomson, and Peter Yee for their review and Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee for
comments; their efforts have improved this document. their review and comments; their efforts have improved this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 11, line 15 skipping to change at page 11, line 25
[FIPS186] National Institute of Standards and Technology, "Digital [FIPS186] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", Federal Information Processing Signature Standard (DSS)", Federal Information Processing
Standards Publication (FIPS PUB) 186-4, July 2013. Standards Publication (FIPS PUB) 186-4, July 2013.
[GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to [GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to
construct random functions", J. ACM 1986 (33), pp. construct random functions", J. ACM 1986 (33), pp.
792-807, 1986. 792-807, 1986.
[I-D.hoffman-c2pq] [I-D.hoffman-c2pq]
Hoffman, P., "The Transition from Classical to Post- Hoffman, P., "The Transition from Classical to Post-
Quantum Cryptography", draft-hoffman-c2pq-05 (work in Quantum Cryptography", draft-hoffman-c2pq-06 (work in
progress), May 2019. progress), November 2019.
[I-D.ietf-tls-external-psk-importer] [I-D.ietf-tls-external-psk-importer]
Benjamin, D. and C. Wood, "Importing External PSKs for Benjamin, D. and C. Wood, "Importing External PSKs for
TLS", draft-ietf-tls-external-psk-importer-01 (work in TLS", draft-ietf-tls-external-psk-importer-02 (work in
progress), October 2019. progress), November 2019.
[IANA] "IANA Registry for TLS ExtensionType Values", n.d.,
<https://www.iana.org/assignments/tls-extensiontype-
values/tls-extensiontype-values.xhtml>.
[IEEE1363] [IEEE1363]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard Specifications for Public-Key Cryptography", IEEE Standard Specifications for Public-Key Cryptography", IEEE
Std 1363-2000, 2000. Std 1363-2000, 2000.
[K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication [K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication
Compiler for Key Exchange (with Applications to Client Compiler for Key Exchange (with Applications to Client
Authentication in TLS 1.3)", IACR ePrint 2016/711, August Authentication in TLS 1.3)", IACR ePrint 2016/711, August
2016. 2016.
 End of changes. 16 change blocks. 
60 lines changed or deleted 71 lines changed or added

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