< draft-ietf-tls-tls13-cert-with-extern-psk-00.txt   draft-ietf-tls-tls13-cert-with-extern-psk-01.txt >
Network Working Group R. Housley Network Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Intended status: Experimental February 28, 2019 Intended status: Experimental May 9, 2019
Expires: September 1, 2019 Expires: November 10, 2019
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-00 draft-ietf-tls-tls13-cert-with-extern-psk-01
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 September 1, 2019. This Internet-Draft will expire on November 10, 2019.
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 14 skipping to change at page 3, line 14
provided by the existing certificate and digital signature provided by the existing certificate and digital signature
mechanisms. mechanisms.
4. Extension Overview 4. Extension Overview
This section provides a brief overview of the This section provides a brief overview of the
"tls_cert_with_extern_psk" extension. "tls_cert_with_extern_psk" extension.
The client includes the "tls_cert_with_extern_psk" extension in the The client includes the "tls_cert_with_extern_psk" extension in the
ClientHello message. The "tls_cert_with_extern_psk" extension MUST ClientHello message. The "tls_cert_with_extern_psk" extension MUST
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 "pre_shared_key" extension MUST be "pre_shared_key" extensions. The "pre_shared_key" extension MUST be
the last extension in the ClientHello message, and it provides a list the last extension in the ClientHello message, and it provides a list
of external PSK identifiers that the client is willing to use with of external PSK identifiers that the client is willing to use with
this server. Since tls_cert_with_extern_psk" extension is intended this server. Since the "tls_cert_with_extern_psk" extension is
to be used only with initial handshakes, it MUST NOT be sent intended to be used only with initial handshakes, it MUST NOT be sent
alongside the "early_data" extension. These extension are all alongside the "early_data" extension. These extensions are all
described in Section 4.2 of [RFC8446]. described in Section 4.2 of [RFC8446].
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 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.
The successful negotiation of the "tls_cert_with_extern_psk" The successful negotiation of the "tls_cert_with_extern_psk"
extension requires the TLS 1.3 key schedule processing to include extension requires the TLS 1.3 key schedule processing to include
both the selected external PSK and the (EC)DHE shared secret value. both the selected external PSK and the (EC)DHE shared secret value.
As a result, the Early Secret, Handshake Secret, and Master Secret As a result, the Early Secret, Handshake Secret, and Master Secret
values all depend upon the value of the selected external PSK. values all depend upon the value of the selected external PSK.
The authentication of the server and optional authentication of the The authentication of the server and optional authentication of the
client depend upon the ability to generate a signature that can be client depend upon the ability to generate a signature that can be
validated with the public key in their certificates. The validated with the public key in their certificates. The
authentication processing is not changed in any way by the selected authentication processing is not changed in any way by the selected
external PSK. external PSK.
Each external PSK is associated with a single Hash algorithm. The Each external PSK is associated with a single hash algorithm, which
hash algorithm MUST be set when the PSK is established, with a is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST
default of SHA-256 if no hash algorithm is specified during be set when the PSK is established, with a default of SHA-256 if no
establishment. hash algorithm is specified during establishment.
5. Certificate with External PSK Extension 5. Certificate with External PSK Extension
This section specifies the "tls_cert_with_extern_psk" extension, This section specifies the "tls_cert_with_extern_psk" extension,
which MAY appear in the ClientHello message and ServerHello message. which MAY appear in the ClientHello message and ServerHello message.
It MUST NOT appear in any other messages. The It MUST NOT appear in any other messages. The
"tls_cert_with_extern_psk" extension MUST NOT appear in the "tls_cert_with_extern_psk" extension MUST NOT appear in the
ServerHello message unless "tls_cert_with_extern_psk" extension ServerHello message unless the "tls_cert_with_extern_psk" extension
appeared in the preceding ClientHello message. If an implementation appeared in the preceding ClientHello message. If an implementation
recognizes the "tls_cert_with_extern_psk" extension and receives it recognizes the "tls_cert_with_extern_psk" extension and receives it
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
skipping to change at page 5, line 28 skipping to change at page 5, line 28
case server_hello: Empty; case server_hello: Empty;
}; };
} CertWithExternPSK; } CertWithExternPSK;
To use an external PSK with certificates, clients MUST provide the To use an external PSK with certificates, clients MUST provide the
"tls_cert_with_extern_psk" extension, and it MUST be accompanied by "tls_cert_with_extern_psk" extension, and it MUST be accompanied by
the "key_share", "psk_key_exchange_modes", and "pre_shared_key" the "key_share", "psk_key_exchange_modes", and "pre_shared_key"
extensions in the ClientHello. If clients offer a extensions in the ClientHello. If clients offer a
"tls_cert_with_extern_psk" extension without all of these other "tls_cert_with_extern_psk" extension without all of these other
extensions, servers MUST abort the handshake. The client MAY also extensions, servers MUST abort the handshake. The client MAY also
find it useful to include the the "supported_groups" extension. Note find it useful to include the "supported_groups" extension. Note
that Section 4.2 of [RFC8446] allows extensions to appear in any that Section 4.2 of [RFC8446] allows extensions to appear in any
order, with the exception of the "pre_shared_key" extension, which order, with the exception of the "pre_shared_key" extension, which
MUST be the last extension in the ClientHello. Also, there MUST NOT MUST be the last extension in the ClientHello. Also, there MUST NOT
be more than one instance of each extension in the ClientHello be more than one instance of each extension in the ClientHello
message. message.
The "key_share" extension is defined in Section 4.2.8 of [RFC8446]. The "key_share" extension is defined in Section 4.2.8 of [RFC8446].
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 both the
skipping to change at page 6, line 6 skipping to change at page 6, line 6
psk_ke mode to support a subsequent NewSessionTicket. Servers MUST psk_ke mode to support a subsequent NewSessionTicket. Servers MUST
select the psk_dhe_ke mode for the initial handshake. Servers MUST select the psk_dhe_ke mode for the initial handshake. Servers MUST
select a key exchange mode that is listed by the client for select a key exchange mode that is listed by the client for
subsequent handshakes that include the resumption PSK from the subsequent handshakes that include the resumption PSK from the
initial handshake. initial handshake.
The "supported_groups" extension is defined in Section 4.2.7 of The "supported_groups" extension is defined in Section 4.2.7 of
[RFC8446]. [RFC8446].
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. listed PSKs MUST be external PSKs.
struct { struct {
opaque identity<1..2^16-1>; opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age; uint32 obfuscated_ticket_age;
} PskIdentity; } PskIdentity;
opaque PskBinderEntry<32..255>; opaque PskBinderEntry<32..255>;
struct { struct {
skipping to change at page 6, line 34 skipping to change at page 6, line 34
case server_hello: uint16 selected_identity; case server_hello: uint16 selected_identity;
}; };
} PreSharedKeyExtension; } PreSharedKeyExtension;
The OfferedPsks contains the list of PSK identities and associated The OfferedPsks contains the list of PSK identities and associated
binders for the external PSKs that the client is willing to use with binders for the external PSKs that the client is willing to use with
the server. the server.
The identities are a list of external PSK identities that the client The identities are a list of external PSK identities that the client
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. In
identity is also referred to as an identifier or a label.) addition, the binder validation (see below) confirms that the client
and server have the same key associated with the identity.
The obfuscated_ticket_age is not used for external PSKs; clients The obfuscated_ticket_age is not used for external PSKs; clients
SHOULD set this value to 0, and servers MUST ignore the value. SHOULD set this value to 0, 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 values, one for each external PSK
offered by the client, in the same order as the identities list. The offered by the client, in the same order as the identities list. The
HMAC value is computed using the binder_key, which is derived from HMAC value is computed using the binder_key, which is derived from
the external PSK, and a partial transcript of the current handshake. the external PSK, and a partial transcript of the current handshake.
Generation of the binder_key from the external PSK is described in Generation of the binder_key from the external PSK is described in
Section 7.1 of [RFC8446]. The partial transcript of the current Section 7.1 of [RFC8446]. The partial transcript of the current
skipping to change at page 7, line 27 skipping to change at page 7, line 27
When the "tls_cert_with_extern_psk" extension is successfully When the "tls_cert_with_extern_psk" extension is successfully
negotiated, authentication of the server depends upon the ability to negotiated, authentication of the server depends upon the ability to
generate a signature that can be validated with the public key in the generate a signature that can be validated with the public key in the
server's certificate. This is accomplished by the server sending the server's certificate. This is accomplished by the server sending the
Certificate and CertificateVerify messages as described in Sections Certificate and CertificateVerify messages as described in Sections
4.4.2 and 4.4.3 of [RFC8446]. 4.4.2 and 4.4.3 of [RFC8446].
TLS 1.3 does not permit the server to send a CertificateRequest TLS 1.3 does not permit the server to send a CertificateRequest
message when a PSK is being used. This restriction is removed when message when a PSK is being used. This restriction is removed when
the "tls_cert_with_extern_psk" extension is negotiated, allowing the the "tls_cert_with_extern_psk" extension is negotiated, allowing
certificate-based authentication for both the client and the server. certificate-based authentication for both the client and the server.
If certificate-based client authentication is desired, this is If certificate-based client authentication is desired, this is
accomplished by the client sending the Certificate and accomplished by the client sending the Certificate and
CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3
of [RFC8446]. of [RFC8446].
Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The
successful negotiation of the "tls_cert_with_extern_psk" extension successful negotiation of the "tls_cert_with_extern_psk" extension
requires the key schedule processing to include both the external PSK requires the key schedule processing to include both the external PSK
and the (EC)DHE shared secret value. and the (EC)DHE shared secret value.
skipping to change at page 8, line 29 skipping to change at page 8, line 29
Compromise of the external PSK will make the encrypted session Compromise of the external PSK will make the encrypted session
content vulnerable to the future invention of a large-scale quantum content vulnerable to the future invention of a large-scale quantum
computer. computer.
Implementers should not transmit the same content on a connection Implementers should not transmit the same content on a connection
that is protected with an external PSK and a connection that is not. that is protected with an external PSK and a connection that is not.
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 choose 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 searching 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.
 End of changes. 13 change blocks. 
20 lines changed or deleted 21 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/