| RFC 9345 | Delegated Credentials for TLS and DTLS | July 2023 |
| Barnes, et al. | Standards Track | [Page] |
The organizational separation between operators of TLS and DTLSendpoints and the certification authority can create limitations. Forexample, the lifetime of certificates, how they may be used, and thealgorithms they support are ultimately determined by theCertification Authority (CA). This document describes a mechanismto overcome some of these limitations by enabling operators todelegate their own credentials for use in TLS and DTLS without breakingcompatibility with peers that do not support this specification.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9345.¶
Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Server operators often deploy (D)TLS termination to act as the server forinbound TLS connections. These termination services can be in locations suchas remote data centers or Content Delivery Networks (CDNs) where it maybe difficult to detect compromises of private key material correspondingto TLS certificates. Short-lived certificates may beused to limit the exposure of keys in these cases.¶
However, short-lived certificates need to be renewed more frequently thanlong-lived certificates. If an external Certification Authority (CA) is unable to issue a certificate intime to replace a deployed certificate, the server would no longer be able topresent a valid certificate to clients. With short-lived certificates, there isa smaller window of time to renew a certificate and therefore a higher risk thatan outage at a CA will negatively affect the uptime of the TLS-fronted service.¶
Typically, a (D)TLS server uses a certificate provided by some entity other thanthe operator of the server (a CA)[RFC8446][RFC5280]. This organizational separation makes the (D)TLS server operatordependent on the CA for some aspects of its operations. For example:¶
To reduce the dependency on external CAs, this document specifies a limited delegationmechanism that allows a (D)TLS peer to issue its own credentials withinthe scope of a certificate issued by an external CA. These credentials only enable therecipient of the delegation to terminate connections for names that the CA has authorized. Furthermore,this mechanism allows the server to use modern signature algorithms such asEd25519[RFC8032] even if their CA does not support them.¶
This document refers to the certificate issued by the CA as a "certificate",or "delegation certificate", and the one issued by the operator as a "delegatedcredential" or "DC".¶
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 asdescribed in BCP 14[RFC2119][RFC8174] when, and only when, theyappear in all capitals, as shown here.¶
A delegated credential (DC) is a digitally signed data structure with two semanticfields: a validity interval and a public key (along with its associatedsignature algorithm). The signature on the delegated credential indicates a delegationfrom the certificate that is issued to the peer. The private keyused to sign a credential corresponds to the public key of the peer'sX.509 end-entity certificate[RFC5280].Figure 1 shows the intended deployment architecture.¶
Client Front-End Back-End | |<--DC distribution->| |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | |<---CertVerify-----| | | ... | |Legend:Client: (D)TLS clientFront-End: (D)TLS server (could be a TLS-termination service like a CDN)Back-End: Service with access to a private key
A (D)TLS handshake that uses delegated credentials differs from a standard handshakein a few important ways:¶
As detailed inSection 4, the delegated credential iscryptographically bound to the end-entity certificate with which thecredential may be used. This document specifies the use of delegatedcredentials in (D)TLS 1.3 or later; their use in prior versions of theprotocol is not allowed.¶
Delegated credentials allow a peer to terminate (D)TLS connections on behalf ofthe certificate owner. If a credential is stolen, there is no mechanism forrevoking it without revoking the certificate itself. To limit exposure in caseof the compromise of a delegated credential's private key, delegated credentialshave a maximum validity period. In the absence of an application profile standardspecifying otherwise, the maximum validity period is set to 7 days. PeersMUST NOT issue credentials with a validity period longer than the maximum validity period or that extends beyond the validity period of the delegation certificate.This mechanism is described in detail inSection 4.1.¶
It was noted in[XPROT] that certificates in use by servers thatsupport outdated protocols such as SSLv2 can be used to forgesignatures for certificates that contain the keyEncipherment KeyUsage([RFC5280],Section 4.2.1.3). In order to reduce the risk of cross-protocol attacks on certificates that are not intended to be usedwith DC-capable TLS stacks, we define a new DelegationUsageextension to X.509 that permits use of delegated credentials. (SeeSection 4.2.)¶
Delegated credentials present a better alternative than other delegationmechanisms like proxy certificates[RFC3820] for several reasons:¶
Many of the use cases for delegated credentials can also be addressed usingpurely server-side mechanisms that do not require changes to client behavior(e.g., a PKCS#11 interface or a remote signing mechanism,[KEYLESS] being oneexample). Thesemechanisms, however, incur per-transaction latency, since the front-endserver has to interact with a back-end server that holds a private key. Themechanism proposed in this document allows the delegation to be doneoffline, with no per-transaction latency. The figure below compares themessage flows for these two mechanismswith (D)TLS 1.3[RFC8446][RFC9147].¶
Remote key signing:Client Front-End Back-End |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | | |<---remote sign---->| |<---CertVerify-----| | | ... | |Delegated Credential:Client Front-End Back-End | |<--DC distribution->| |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | |<---CertVerify-----| | | ... | |Legend:Client: (D)TLS clientFront-End: (D)TLS server (could be a TLS-termination service like a CDN)Back-End: Service with access to a private key¶
These two mechanisms can be complementary. A server could usedelegated credentials for clients that support them, while using aserver-side mechanism to support legacy clients. Both mechanismsrequire a trusted relationship between the front-end and back-end --the delegated credential can be used in place of a certificateprivate key.¶
The use of short-lived certificates with automated certificate issuance,e.g., with the Automated Certificate Management Environment (ACME)[RFC8555],reduces the risk of key compromise but has several limitations.Specifically, it introduces an operationally critical dependency on anexternal party (the CA). It alsolimits the types of algorithms supported for (D)TLS authentication to thosethe CA is willing to issue a certificate for. Nonetheless, existingautomated issuance APIs like ACME may be useful for provisioning delegated credentials.¶
While X.509 forbids end-entity certificates from being used as issuers forother certificates, it is valid to use them to issue other signedobjects as long as the certificate contains the digitalSignature KeyUsage([RFC5280],Section 4.2.1.3). (All certificates compatible with TLS 1.3 arerequired to contain the digitalSignature KeyUsage.) This document defines a new signedobject format that encodes only the semantics that are needed for thisapplication. The Credential has the following structure:¶
struct { uint32 valid_time; SignatureScheme dc_cert_verify_algorithm; opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; } Credential;¶Time, in seconds relative to the delegation certificate'snotBefore value, after which the delegated credential is no longer valid.By default, unless set to an alternative value by an application profile (seeSection 3), endpoints will reject delegated credentials that expire more than 7days from the current time (as described inSection 4.1.3).¶
The signature algorithm of the Credential key pair, where the typeSignatureScheme is as defined in[RFC8446]. This is expected to bethe same as the sender's CertificateVerify.algorithm (as described inSection 4.1.3).
Whenusing RSA, the public keyMUST NOT use the rsaEncryption OID. As a result,the following algorithms are not allowed for use with delegated credentials:rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, and rsa_pss_rsae_sha512.¶
The Credential's public key, a DER-encoded[X.690] SubjectPublicKeyInfo as defined in[RFC5280].¶
The DelegatedCredential has the following structure:¶
struct { Credential cred; SignatureScheme algorithm; opaque signature<1..2^16-1>; } DelegatedCredential;¶The Credential structure as previously defined.¶
The signature algorithm used to create DelegatedCredential.signature.¶
The delegation, a signature that binds the credential to the end-entitycertificate's public key as specified below. The signature scheme is specifiedby DelegatedCredential.algorithm.¶
The signature of the DelegatedCredential is computed over the concatenation of:¶
The signature is computed by using the private key of the peer's end-entitycertificate, with the algorithm indicated by DelegatedCredential.algorithm.¶
The signature effectively binds the credential to the parameters of thehandshake in which it is used. In particular, it ensures that credentials areonly used with the certificate and signature algorithm chosen by thedelegator.¶
The code changes required in order to create and verify delegated credentials,and the implementation complexity this entails, are localized to the (D)TLSstack. This has the advantage of avoiding changes to the often-delicatesecurity-critical PKI code.¶
This document defines the following (D)TLS extension code point.¶
enum { ... delegated_credential(34), (65535) } ExtensionType;¶A client that is willing to use delegated credentials in a connectionSHALL send a"delegated_credential" extension in its ClientHello. The body of the extensionconsists of a SignatureSchemeList (defined in[RFC8446]):¶
struct { SignatureScheme supported_signature_algorithms<2..2^16-2>; } SignatureSchemeList;¶If the client receives a delegated credential without having indicated supportin its ClientHello,then the clientMUST abort the handshake with an "unexpected_message" alert.¶
If the extension is present, the serverMAY send a delegated credential; if theextension is not present, the serverMUST NOT send a delegated credential.When a (D)TLS version negotiated is less than 1.3, the serverMUST ignore this extension.An example of when a server could choose not to send a delegatedcredential is when the SignatureSchemes listed only contain signature schemesfor which a corresponding delegated credential does not exist or areotherwise unsuitable for the connection.¶
The serverMUST send the delegated credential as an extension in theCertificateEntry of its end-entity certificate; the clientMUST NOT usedelegated credentials sent as extensions to any other certificate, andSHOULD ignore them, butMAY abort the handshake withan "illegal_parameter" alert. If the server sends multiple delegatedcredentials extensions in a single CertificateEntry, the clientMUSTabort the handshake with an "illegal_parameter" alert.¶
The algorithm fieldMUST be of a type advertised by the client in the"signature_algorithms" extension of the ClientHello message, andthe dc_cert_verify_algorithm fieldMUST be of atype advertised by the client in the SignatureSchemeList; otherwise, the credential isconsidered not valid. Clients that receive non-valid delegatedcredentialsMUST terminate the connection with an "illegal_parameter"alert.¶
A server that supports this specificationSHALL send a"delegated_credential" extension in the CertificateRequest messagewhen requesting client authentication. The body of theextension consists of a SignatureSchemeList. If the server receives adelegated credential without having indicated support in itsCertificateRequest, then the serverMUST abort with an"unexpected_message" alert.¶
If the extension is present, the clientMAY send a delegated credential; if theextension is not present, the clientMUST NOT send a delegated credential.When a (D)TLS version negotiated is less than 1.3, the clientMUST ignore this extension.¶
The clientMUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the serverMUST NOT use delegated credentials sent as extensions to any other certificate, andSHOULD ignore them, butMAY abort the handshake with an "illegal_parameter" alert. If the client sends multiple delegated credentials extensions in a single CertificateEntry, the serverMUST abort the handshake with an "illegal_parameter" alert.¶
The algorithm fieldMUST be of a type advertised by the serverin the "signature_algorithms" extension of the CertificateRequest message,and the dc_cert_verify_algorithm fieldMUST be of a typeadvertised by the server in the SignatureSchemeList; otherwise, the credential isconsidered not valid. Servers that receive non-validdelegated credentialsMUST terminate the connection with an"illegal_parameter" alert.¶
On receiving a delegated credential and certificate chain, the peer validatesthe certificate chain and matches the end-entity certificate to the peer'sexpected identity in the same way that it is done when delegated credentials arenot in use. It then performs the following checks with expiry time set to thedelegation certificate's notBefore value plus DelegatedCredential.cred.valid_time:¶
If one or more of these checks fail, then the delegated credential is deemednot valid. Clients and servers that receive non-valid delegated credentialsMUST terminate theconnection with an "illegal_parameter" alert.¶
If successful, the participant receiving the Certificate message uses the publickey in DelegatedCredential.cred to verify the signature in the peer'sCertificateVerify message.¶
This document defines a new X.509 extension, DelegationUsage, to be used in the certificatewhen the certificate permits the usage of delegated credentials. What followsis the ASN.1[X.680] for the DelegationUsage certificate extension.¶
ext-delegationUsage EXTENSION ::= { SYNTAX DelegationUsage IDENTIFIED BY id-pe-delegationUsage } DelegationUsage ::= NULL id-pe-delegationUsage OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) id-cloudflare(44363) 44 }¶The extensionMUST be marked non-critical. (SeeSection 4.2 of [RFC5280].)An endpointMUST NOT accept a delegated credential unless the peer's end-entitycertificate satisfies the following criteria:¶
A new extension was chosen instead of adding a new Extended Key Usage(EKU) to be compatible with deployed (D)TLS and PKI software stackswithout requiring CAs to issue new intermediate certificates.¶
The operational considerations documented in this section should betaken into consideration when using delegated credentials.¶
One of the risks of deploying a short-lived credential system basedon absolute time is client clock skew. If a client's clock is sufficientlyahead of or behind the server's clock, then clients will reject delegated credentialsthat are valid from the server's perspective. Clockskew also affects the validity of the original certificates. The lifetimeof the delegated credential should be set taking clock skew into account.Clock skew may affect a delegated credential at the beginning and end ofits validity periods, which should also be taken into account.¶
This document registers the "delegated_credential" extension in the"TLS ExtensionType Values" registry. The "delegated_credential"extension has been assigned the ExtensionType value 34. The IANA registrylists this extension as "Recommended" (i.e., "Y") and indicates thatit may appear in the ClientHello (CH), CertificateRequest (CR),or Certificate (CT) messages in (D)TLS 1.3[RFC8446][RFC9147].Additionally, the "DTLS-Only" column is assigned the value "N".¶
This document also defines an ASN.1 module for the DelegationUsagecertificate extension inAppendix A. IANA has registered value 95 for"id-mod-delegated-credential-extn" in the "SMI Security for PKIX ModuleIdentifier" (1.3.6.1.5.5.7.0) registry. An OID for the DelegationUsage certificate extensionis not needed, as it is already assigned to the extension fromCloudflare's IANA Private Enterprise Number (PEN) arc.¶
The security considerations documented in this section should betaken into consideration when using delegated credentials.¶
Delegated credentials limit the exposure of the private key used ina (D)TLS connection by limiting its validity period. An attacker whocompromises the private key of a delegated credentialcannot create new delegated credentials, but they canimpersonate the compromised party in new TLS connections until thedelegated credential expires.¶
Thus, delegated credentials should not be used to send a delegation to an untrusted party. Rather, theyare meant to be used between parties that have some trust relationship with eachother. The secrecy of the delegated credential's private key is thus important, andaccess control mechanismsSHOULD be used to protect it, including file systemcontrols, physical security, or hardware security modules.¶
It is not possible to use the same delegated credential for both client and serverauthentication because issuing parties compute the corresponding signature using a context string unique to the intended role (client or server).¶
Delegated credentials do not provide any additional form of early revocation.Since it is short-lived, the expiry of the delegated credential revokesthe credential. Revocation of the long-term private key that signs thedelegated credential (from the end-entity certificate) also implicitly revokesthe delegated credential.¶
If a peer decides to cache the certificate chain and re-validate itwhen resuming a connection, theySHOULD also cache theassociated delegated credential and re-validate it. Failing to do somay result in resuming connections for which the delegated credential has expired.¶
Delegated credentials can be valid for 7 days (by default), and it is much easier for a service to create delegated credentials than a certificate signed by a CA. A service could determine the client time and clock skew by creating several delegated credentials with different expiry timestamps and observing which credentials the client accepts. Since client time can be unique to a particular client, privacy-sensitive clients who do not trust the service, such as browsers in incognito mode, might not want to advertise support for delegated credentials, or might limit the number of probes that a server can perform.¶
Delegated credentials are only used in (D)TLS 1.3 connections. However, the certificatethat signs a delegated credential may be used in other contexts such as (D)TLS 1.2.Using a certificate in multiple contexts opens up a potential cross-protocolattack against delegated credentials in (D)TLS 1.3.¶
When (D)TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacksthat allow forging an RSA signature over an arbitrary message[BLEI].The TLS 1.2 specification describes a strategy for preventing these attacks that requires careful implementation of timing-resistant countermeasures.(SeeSection 7.4.7.1 of [RFC5246].)¶
Experience shows that, in practice, server implementations may fail to fullystop these attacks due to the complexity of this mitigation[ROBOT].For (D)TLS 1.2 servers that support RSA key exchange using a DC-enabled end-entitycertificate, a hypothetical signature forgery attack would allow forging asignature over a delegated credential.The forged delegated credential could then be used by the attacker as the equivalent of anon-path attacker, valid for a maximum of 7 days (if the defaultvalid_time is used).¶
Server operators should therefore minimize the risk of using DC-enabledend-entity certificates where a signature forgery oracle may be present.If possible, server operators may choose to use DC-enabled certificates only for signingcredentials and not for serving non-DC (D)TLS traffic.Furthermore, server operators may use elliptic curve certificates for DC-enabledtraffic, while using RSA certificates without the DelegationUsage certificateextension for non-DC traffic; this completely prevents such attacks.¶
Note that if a signature can be forged over an arbitrary credential, theattacker can choose any value for the valid_time field. Repeated signatureforgeries therefore allow the attacker to create multiple delegatedcredentials that can cover the entire validity period of thecertificate. Temporary exposure of the key or a signing oracle mayallow the attacker to impersonate a server for the lifetime of the certificate.¶
The following ASN.1 module provides the complete definition of theDelegationUsage certificate extension. The ASN.1 module makes importsfrom[RFC5912].¶
DelegatedCredentialExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-delegated-credential-extn(95) }DEFINITIONS IMPLICIT TAGS ::=BEGIN-- EXPORT ALLIMPORTSEXTENSION FROM PKIX-CommonTypes-2009 -- From RFC 5912 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ;-- OIDid-cloudflare OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 44363 }-- EXTENSIONext-delegationUsage EXTENSION ::= { SYNTAX DelegationUsage IDENTIFIED BY id-pe-delegationUsage }id-pe-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 }DelegationUsage ::= NULLEND¶The following is an example of a delegation certificate that satisfies therequirements described inSection 4.2 (i.e., uses the DelegationUsage extensionand has the digitalSignature KeyUsage).¶
-----BEGIN CERTIFICATE-----MIIFRjCCBMugAwIBAgIQDGevB+lY0o/OecHFSJ6YnTAKBggqhkjOPQQDAzBMMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdpQ2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAzMjYwMDAwMDBaFw0yMTAzMzAxMjAwMDBaMGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMuMRMwEQYDVQQDEwprYzJrZG0uY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEd4azI83Bw0fcPgfoeiZpZZnwGuxjBjv++wzE0zAj8vNiUkKxOWSQiGNLn+xlWUpLlw9djRN1rLmVmn2gb9GgdKOCA28wggNrMB8GA1UdIwQYMBaAFKOd5h/52jlPwG7okcuVpdox4gqfMB0GA1UdDgQWBBSfcb7fS3fUFAyB91fRcwoDPtgtJjAjBgNVHREEHDAaggprYzJrZG0uY29tggwqLmtjMmtkbS5jb20wDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBpBgNVHR8EYjBgMC6gLKAqhihodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMC6gLKAqhihodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUFBwEBBG8wbTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUGCCsGAQUFBzAChjlodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRFQ0NTZWN1cmVTZXJ2ZXJDQS5jcnQwDAYDVR0TAQH/BAIwADAPBgkrBgEEAYLaSywEAgUAMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAAAWm5hYJ5AAAEAwBHMEUCICiGfq+hSThRL2m8H0awoDR8OpnEHNkF0nI6nL5yYL/jAiEAxwebGs/T6Es0YarPzoQJrVZqk+sHH/t+jrSrKd5TDjcAdgCHdb/nWXz4jEOZX73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWm5hYNgAAAEAwBHMEUCIQD9OWA8KGL6bxDKfgIleHJWB0iWieRs88VgJyfAg/aFDgIgQ/OsdSF9XOy1foqge0DTDM2FExuw0JR0AGZWXoNtJzMAdgBElGUusO7Or8RAB9io/ijA2uaCvtjLMbU/0zOWtbaBqAAAAWm5hYHgAAAEAwBHMEUCIQC4vua1n3BqthEqpA/VBTcsNwMtAwpCuac2IhJ9wx6X/AIgb+o00k28JQo9TMpP4vzJ3BD3HXWSNc2Zizbq7mkUQYMwCgYIKoZIzj0EAwMDaQAwZgIxAJsX7d0SuA8ddf/m7IWfNfs3MQfJyGkEezMJX1t6sRso5z50SS12LpXemuGa1FE2ZgIxAL+CDUF5pz7mhrAEIjQ1MqlpF9tH40dJGvYZZQ3W23cMzSkDfvlty5S4RfWHIIPjbw==-----END CERTIFICATE-----¶
Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh Ramachandran, BenjaminKaduk, 奥 一穂 (Kazuho Oku), Daniel Kahn Gillmor, Watson Ladd, Robert Merget, JurajSomorovsky, and Nimrod Aviram for their discussions, ideas,and bugs they have found.¶