draft-ietf-tls-subcerts-10.txt   draft-ietf-tls-subcerts-11.txt 
Network Working Group R. Barnes Network Working Group R. Barnes
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track S. Iyengar Intended status: Standards Track S. Iyengar
Expires: 28 July 2021 Facebook Expires: 27 March 2022 Facebook
N. Sullivan N. Sullivan
Cloudflare Cloudflare
E. Rescorla E. Rescorla
Mozilla Mozilla
24 January 2021 23 September 2021
Delegated Credentials for TLS Delegated Credentials for TLS
draft-ietf-tls-subcerts-10 draft-ietf-tls-subcerts-11
Abstract Abstract
The organizational separation between the operator of a TLS endpoint The organizational separation between the operator of a TLS endpoint
and the certification authority can create limitations. For example, and the certification authority can create limitations. For example,
the lifetime of certificates, how they may be used, and the the lifetime of certificates, how they may be used, and the
algorithms they support are ultimately determined by the algorithms they support are ultimately determined by the
certification authority. This document describes a mechanism by certification authority. This document describes a mechanism by
which operators may delegate their own credentials for use in TLS, which operators may delegate their own credentials for use in TLS,
without breaking compatibility with peers that do not support this without breaking compatibility with peers that do not support this
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 28 July 2021. This Internet-Draft will expire on 27 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 7
4. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 8 4. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 8
4.1. Client and Server Behavior . . . . . . . . . . . . . . . 10 4.1. Client and Server Behavior . . . . . . . . . . . . . . . 10
4.1.1. Server Authentication . . . . . . . . . . . . . . . . 10 4.1.1. Server Authentication . . . . . . . . . . . . . . . . 10
4.1.2. Client Authentication . . . . . . . . . . . . . . . . 10 4.1.2. Client Authentication . . . . . . . . . . . . . . . . 11
4.1.3. Validating a Delegated Credential . . . . . . . . . . 11 4.1.3. Validating a Delegated Credential . . . . . . . . . . 11
4.2. Certificate Requirements . . . . . . . . . . . . . . . . 12 4.2. Certificate Requirements . . . . . . . . . . . . . . . . 12
5. Operational Considerations . . . . . . . . . . . . . . . . . 12 5. Operational Considerations . . . . . . . . . . . . . . . . . 12
5.1. Client Clock Skew . . . . . . . . . . . . . . . . . . . . 13 5.1. Client Clock Skew . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Security of Delegated Credential's Private Key . . . . . 13 7.1. Security of Delegated Credential's Private Key . . . . . 13
7.2. Re-use of Delegated Credentials in Multiple 7.2. Re-use of Delegated Credentials in Multiple
Contexts . . . . . . . . . . . . . . . . . . . . . . . . 14 Contexts . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Revocation of Delegated Credentials . . . . . . . . . . . 14 7.3. Revocation of Delegated Credentials . . . . . . . . . . . 14
7.4. Interactions with Session Resumption . . . . . . . . . . 14 7.4. Interactions with Session Resumption . . . . . . . . . . 14
7.5. Privacy Considerations . . . . . . . . . . . . . . . . . 14 7.5. Privacy Considerations . . . . . . . . . . . . . . . . . 14
7.6. The Impact of Signature Forgery Attacks . . . . . . . . . 14 7.6. The Impact of Signature Forgery Attacks . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
Appendix B. Example Certificate . . . . . . . . . . . . . . . . 18 Appendix B. Example Certificate . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Server operators often deploy TLS termination services in locations
such as remote data centers or Content Delivery Networks (CDNs) where
it may be difficult to detect key compromises. Short-lived
certificates may be used to limit the exposure of keys in these
cases.
However, short-lived certificates need to be renewed more frequently
than long-lived certificates. If an external CA is unable to issue a
certificate in time to replace a deployed certificate, the server
would no longer be able to present a valid certificate to clients.
With short-lived certificates, there is a smaller window of time to
renew a certificates and therefore a higher risk that an outage at a
CA will negatively affect the uptime of the service.
Typically, a TLS server uses a certificate provided by some entity Typically, a TLS server uses a certificate provided by some entity
other than the operator of the server (a "Certification Authority" or other than the operator of the server (a "Certification Authority" or
CA) [RFC8446] [RFC5280]. This organizational separation makes the CA) [RFC8446] [RFC5280]. This organizational separation makes the
TLS server operator dependent on the CA for some aspects of its TLS server operator dependent on the CA for some aspects of its
operations, for example: operations, for example:
* Whenever the server operator wants to deploy a new certificate, it * Whenever the server operator wants to deploy a new certificate, it
has to interact with the CA. has to interact with the CA.
* The server operator can only use TLS signature schemes for which * The server operator can only use TLS signature schemes for which
the CA will issue credentials. the CA will issue credentials.
These dependencies cause problems in practice. Server operators
often deploy TLS termination services in locations such as remote
data centers or Content Delivery Networks (CDNs) where it may be
difficult to detect key compromises. Short-lived certificates may be
used to limit the exposure of keys in these cases.
However, short-lived certificates need to be renewed more frequently
than long-lived certificates. If an external CA is unable to issue a
certificate in time to replace a deployed certificate, the server
would no longer be able to present a valid certificate to clients.
With short-lived certificates, there is a smaller window of time to
renew a certificates and therefore a higher risk that an outage at a
CA will negatively affect the uptime of the service.
To reduce the dependency on external CAs, this document proposes a To reduce the dependency on external CAs, this document proposes a
limited delegation mechanism that allows a TLS peer to issue its own limited delegation mechanism that allows a TLS peer to issue its own
credentials within the scope of a certificate issued by an external credentials within the scope of a certificate issued by an external
CA. These credentials only enable the recipient of the delegation to CA. These credentials only enable the recipient of the delegation to
speak for names that the CA has authorized. Furthermore, this speak for names that the CA has authorized. Furthermore, this
mechanism allows the server to use modern signature algorithms such mechanism allows the server to use modern signature algorithms such
as Ed25519 [RFC8032] even if their CA does not support them. as Ed25519 [RFC8032] even if their CA does not support them.
We will refer to the certificate issued by the CA as a "certificate", We will refer to the certificate issued by the CA as a "certificate",
or "delegation certificate", and the one issued by the operator as a or "delegation certificate", and the one issued by the operator as a
skipping to change at page 7, line 8 skipping to change at page 7, line 8
* Proxy certificates rely on the certificate path building process * Proxy certificates rely on the certificate path building process
to establish a binding between the proxy certificate and the to establish a binding between the proxy certificate and the
server certificate. Since the certificate path building process server certificate. Since the certificate path building process
is not cryptographically protected, it is possible that a proxy is not cryptographically protected, it is possible that a proxy
certificate could be bound to another certificate with the same certificate could be bound to another certificate with the same
public key, with different X.509 parameters. Delegated public key, with different X.509 parameters. Delegated
credentials, which rely on a cryptographic binding between the credentials, which rely on a cryptographic binding between the
entire certificate and the delegated credential, cannot. entire certificate and the delegated credential, cannot.
* Each delegated credential is bound to a specific signature * Each delegated credential is bound to a specific signature
algorithm for use use in the TLS handshake ([RFC8446] section algorithm for use in the TLS handshake ([RFC8446] section 4.2.3).
4.2.3). This prevents them from being used with other, perhaps This prevents them from being used with other, perhaps unintended
unintended signature algorithms. signature algorithms. The signature algorithm bound to the
delegated credential can be chosen independantly of the set of
signature algorithms supported by the end-entity certificate.
3.2. Related Work 3.2. Related Work
Many of the use cases for delegated credentials can also be addressed Many of the use cases for delegated credentials can also be addressed
using purely server-side mechanisms that do not require changes to using purely server-side mechanisms that do not require changes to
client behavior (e.g., a PKCS#11 interface or a remote signing client behavior (e.g., a PKCS#11 interface or a remote signing
mechanism [KEYLESS]). These mechanisms, however, incur per- mechanism [KEYLESS]). These mechanisms, however, incur per-
transaction latency, since the front-end server has to interact with transaction latency, since the front-end server has to interact with
a back-end server that holds a private key. The mechanism proposed a back-end server that holds a private key. The mechanism proposed
in this document allows the delegation to be done off-line, with no in this document allows the delegation to be done off-line, with no
skipping to change at page 8, line 33 skipping to change at page 8, line 35
structure: structure:
struct { struct {
uint32 valid_time; uint32 valid_time;
SignatureScheme expected_cert_verify_algorithm; SignatureScheme expected_cert_verify_algorithm;
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
} Credential; } Credential;
valid_time: Time in seconds relative to the beginning of the valid_time: Time in seconds relative to the beginning of the
delegation certificate's notBefore value after which the delegated delegation certificate's notBefore value after which the delegated
credential is no longer valid. Endpoints will reject delegate credential is no longer valid. Endpoints will reject delegated
credentials with valid_times exceeding 7 days (as described in credentials that expire more than 7 days from the current time (as
Section 4.1). described in Section 4.1).
expected_cert_verify_algorithm: The signature algorithm of the expected_cert_verify_algorithm: The signature algorithm of the
Credential key pair, where the type SignatureScheme is as defined Credential key pair, where the type SignatureScheme is as defined
in [RFC8446]. This is expected to be the same as the sender's in [RFC8446]. This is expected to be the same as the sender's
CertificateVerify.algorithm. Only signature algorithms allowed CertificateVerify.algorithm (as described in Section 4.1.3). Only
for use in CertificateVerify messages are allowed. When using signature algorithms allowed for use in CertificateVerify messages
RSA, the public key MUST NOT use the rsaEncryption OID. As a are allowed. When using RSA, the public key MUST NOT use the
result, the following algorithms are not allowed for use with rsaEncryption OID. As a result, the following algorithms are not
delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, allowed for use with delegated credentials: rsa_pss_rsae_sha256,
rsa_pss_rsae_sha512. rsa_pss_rsae_sha384, rsa_pss_rsae_sha512.
ASN1_subjectPublicKeyInfo: The Credential's public key, a DER- ASN1_subjectPublicKeyInfo: The Credential's public key, a DER-
encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280].
The DelegatedCredential has the following structure: The DelegatedCredential has the following structure:
struct { struct {
Credential cred; Credential cred;
SignatureScheme algorithm; SignatureScheme algorithm;
opaque signature<0..2^16-1>; opaque signature<0..2^16-1>;
skipping to change at page 10, line 32 skipping to change at page 10, line 32
SignatureScheme supported_signature_algorithm<2..2^16-2>; SignatureScheme supported_signature_algorithm<2..2^16-2>;
} SignatureSchemeList; } SignatureSchemeList;
If the client receives a delegated credential without indicating If the client receives a delegated credential without indicating
support, then the client MUST abort with an "unexpected_message" support, then the client MUST abort with an "unexpected_message"
alert. alert.
If the extension is present, the server MAY send a delegated If the extension is present, the server MAY send a delegated
credential; if the extension is not present, the server MUST NOT send credential; if the extension is not present, the server MUST NOT send
a delegated credential. The server MUST ignore the extension unless a delegated credential. The server MUST ignore the extension unless
TLS 1.3 or a later version is negotiated. TLS 1.3 or a later version is negotiated. An example of when a
server could choose not to send a delegated credential is when the
SignatureSchemes listed only contain signature schemes for which a
corresponding delegated credential does not exist or are otherwise
unsuitable for the connection.
The server MUST send the delegated credential as an extension in the The server MUST send the delegated credential as an extension in the
CertificateEntry of its end-entity certificate; the client SHOULD CertificateEntry of its end-entity certificate; the client SHOULD
ignore delegated credentials sent as extensions to any other ignore delegated credentials sent as extensions to any other
certificate. certificate.
The expected_cert_verify_algorithm field MUST be of a type advertised The expected_cert_verify_algorithm field MUST be of a type advertised
by the client in the SignatureSchemeList and is considered invalid by the client in the SignatureSchemeList and is considered invalid
otherwise. Clients that receive invalid delegated credentials MUST otherwise. Clients that receive invalid delegated credentials MUST
terminate the connection with an "illegal_parameter" alert. terminate the connection with an "illegal_parameter" alert.
skipping to change at page 11, line 27 skipping to change at page 11, line 37
and the expected_cert_verify_algorithm field MUST be of a type and the expected_cert_verify_algorithm field MUST be of a type
advertised by the server in the SignatureSchemeList and considered advertised by the server in the SignatureSchemeList and considered
invalid otherwise. Servers that receive invalid delegated invalid otherwise. Servers that receive invalid delegated
credentials MUST terminate the connection with an "illegal_parameter" credentials MUST terminate the connection with an "illegal_parameter"
alert. alert.
4.1.3. Validating a Delegated Credential 4.1.3. Validating a Delegated Credential
On receiving a delegated credential and a certificate chain, the peer On receiving a delegated credential and a certificate chain, the peer
validates the certificate chain and matches the end-entity validates the certificate chain and matches the end-entity
certificate to the peer's expected identity. It also takes the certificate to the peer's expected identity. It then performs the
following steps: following checks with expiry time set to the delegation certificate's
notBefore value plus DelegatedCredential.cred.valid_time:
1. Validate that DelegatedCredential.cred.valid_time is no more than
7 days.
2. Verify that the current time is within the validity interval of 1. Verify that the current time is within the validity interval of
the credential. This is done by asserting that the current time the credential. This is done by asserting that the current time
is no more than the delegation certificate's notBefore value plus does not exceed the expiry time.
DelegatedCredential.cred.valid_time.
3. Verify that the delegated credential's remaining validity time is 2. Verify that the delegated credential's remaining validity period
no more than the maximum validity period. This is done by is no more than the maximum validity period. This is done by
asserting that the current time is no more than the delegation asserting that the expiry time does not exceed the current time
certificate's notBefore value plus plus the maximum validity period (7 days).
DelegatedCredential.cred.valid_time plus the maximum validity
period.
4. Verify that expected_cert_verify_algorithm matches the scheme 3. Verify that expected_cert_verify_algorithm matches the scheme
indicated in the peer's CertificateVerify message and that the indicated in the peer's CertificateVerify message and that the
algorithm is allowed for use with delegated credentials. algorithm is allowed for use with delegated credentials.
5. Verify that the end-entity certificate satisfies the conditions 4. Verify that the end-entity certificate satisfies the conditions
in Section 4.2. in Section 4.2.
6. Use the public key in the peer's end-entity certificate to verify 5. Use the public key in the peer's end-entity certificate to verify
the signature of the credential using the algorithm indicated by the signature of the credential using the algorithm indicated by
DelegatedCredential.algorithm. DelegatedCredential.algorithm.
If one or more of these checks fail, then the delegated credential is If one or more of these checks fail, then the delegated credential is
deemed invalid. Clients and servers that receive invalid delegated deemed invalid. Clients and servers that receive invalid delegated
credentials MUST terminate the connection with an "illegal_parameter" credentials MUST terminate the connection with an "illegal_parameter"
alert. alert.
If successful, the participant receiving the Certificate message uses If successful, the participant receiving the Certificate message uses
the public key in DelegatedCredential.cred to verify the signature in the public key in DelegatedCredential.cred to verify the signature in
skipping to change at page 14, line 40 skipping to change at page 14, line 40
signed by a CA. A service could determine the client time and clock signed by a CA. A service could determine the client time and clock
skew by creating several delegated credentials with different expiry skew by creating several delegated credentials with different expiry
timestamps and observing whether the client would accept it. Client timestamps and observing whether the client would accept it. Client
time could be unique and thus privacy sensitive clients, such as time could be unique and thus privacy sensitive clients, such as
browsers in incognito mode, who do not trust the service might not browsers in incognito mode, who do not trust the service might not
want to advertise support for delegated credentials or limit the want to advertise support for delegated credentials or limit the
number of probes that a server can perform. number of probes that a server can perform.
7.6. The Impact of Signature Forgery Attacks 7.6. The Impact of Signature Forgery Attacks
Delegated credentials are only used in TLS 1.3 connections. However,
the certificate that signs a delegated credential may be used in
other contexts such as TLS 1.2. Using a certificate in multiple
contexts opens up a potential cross-protocol attack against delegated
credentials in TLS 1.3.
When TLS 1.2 servers support RSA key exchange, they may be vulnerable When TLS 1.2 servers support RSA key exchange, they may be vulnerable
to attacks that allow forging an RSA signature over an arbitrary to attacks that allow forging an RSA signature over an arbitrary
message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a
mitigation strategy requiring careful implementation of timing mitigation strategy requiring careful implementation of timing
resistant countermeasures for preventing these attacks. Experience resistant countermeasures for preventing these attacks. Experience
shows that in practice, server implementations may fail to fully stop shows that in practice, server implementations may fail to fully stop
these attacks due to the complexity of this mitigation [ROBOT]. For these attacks due to the complexity of this mitigation [ROBOT]. For
TLS 1.2 servers that support RSA key exchange using a DC-enabled end- TLS 1.2 servers that support RSA key exchange using a DC-enabled end-
entity certificate, a hypothetical signature forgery attack would entity certificate, a hypothetical signature forgery attack would
allow forging a signature over a delegated credential. The forged allow forging a signature over a delegated credential. The forged
 End of changes. 20 change blocks. 
50 lines changed or deleted 57 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/