idnits 2.17.1 draft-ietf-tls-subcerts-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 947 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 June 2022) is 674 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft Cisco 4 Intended status: Standards Track S. Iyengar 5 Expires: 17 December 2022 Facebook 6 N. Sullivan 7 Cloudflare 8 E. Rescorla 9 Mozilla 10 15 June 2022 12 Delegated Credentials for (D)TLS 13 draft-ietf-tls-subcerts-15 15 Abstract 17 The organizational separation between operators of TLS and DTLS 18 endpoints and the certification authority can create limitations. 19 For example, the lifetime of certificates, how they may be used, and 20 the algorithms they support are ultimately determined by the 21 certification authority. This document describes a mechanism to to 22 overcome some of these limitations by enabling operators to delegate 23 their own credentials for use in TLS and DTLS without breaking 24 compatibility with peers that do not support this specification. 26 Discussion Venues 28 This note is to be removed before publishing as an RFC. 30 Source for this draft and an issue tracker can be found at 31 https://github.com/tlswg/tls-subcerts (https://github.com/tlswg/tls- 32 subcerts). 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 17 December 2022. 51 Copyright Notice 53 Copyright (c) 2022 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 Table of Contents 67 1. Introduction 68 2. Conventions and Terminology 69 2.1. Change Log 70 3. Solution Overview 71 3.1. Rationale 72 3.2. Related Work 73 4. Delegated Credentials 74 4.1. Client and Server Behavior 75 4.1.1. Server Authentication 76 4.1.2. Client Authentication 77 4.1.3. Validating a Delegated Credential 78 4.2. Certificate Requirements 79 5. Operational Considerations 80 5.1. Client Clock Skew 81 6. IANA Considerations 82 7. Security Considerations 83 7.1. Security of Delegated Credential's Private Key 84 7.2. Re-use of Delegated Credentials in Multiple Contexts 85 7.3. Revocation of Delegated Credentials 86 7.4. Interactions with Session Resumption 87 7.5. Privacy Considerations 88 7.6. The Impact of Signature Forgery Attacks 89 8. Acknowledgements 90 9. References 91 9.1. Normative References 92 9.2. Informative References 93 Appendix A. ASN.1 Module 94 Appendix B. Example Certificate 95 Authors' Addresses 97 1. Introduction 99 Server operators often deploy (D)TLS termination to act as the server 100 for inbound TLS connections. These termination services can be in 101 locations such as remote data centers or Content Delivery Networks 102 (CDNs) where it may be difficult to detect compromises of private key 103 material corresponding to TLS certificates. Short-lived certificates 104 may be used to limit the exposure of keys in these cases. 106 However, short-lived certificates need to be renewed more frequently 107 than long-lived certificates. If an external Certification Authority 108 (CA) is unable to issue a certificate in time to replace a deployed 109 certificate, the server would no longer be able to present a valid 110 certificate to clients. With short-lived certificates, there is a 111 smaller window of time to renew a certificates and therefore a higher 112 risk that an outage at a CA will negatively affect the uptime of the 113 TLS-fronted service. 115 Typically, a (D)TLS server uses a certificate provided by some entity 116 other than the operator of the server (a CA) [RFC8446] [RFC5280]. 117 This organizational separation makes the (D)TLS server operator 118 dependent on the CA for some aspects of its operations, for example: 120 * Whenever the server operator wants to deploy a new certificate, it 121 has to interact with the CA. 123 * The CA might only issue credentials containing certain types of 124 public key, which can limit the set of (D)TLS signature schemes 125 usable by the server operator. 127 To reduce the dependency on external CAs, this document specifies a 128 limited delegation mechanism that allows a (D)TLS peer to issue its 129 own credentials within the scope of a certificate issued by an 130 external CA. These credentials only enable the recipient of the 131 delegation to terminate connections for names that the CA has 132 authorized. Furthermore, this mechanism allows the server to use 133 modern signature algorithms such as Ed25519 [RFC8032] even if their 134 CA does not support them. 136 This document refers to the certificate issued by the CA as a 137 "certificate", or "delegation certificate", and the one issued by the 138 operator as a "delegated credential" or "DC". 140 Client Front-End Back-End 141 | |<--DC distribution->| 142 |----ClientHello--->| | 143 |<---ServerHello----| | 144 |<---Certificate----| | 145 |<---CertVerify-----| | 146 | ... | | 148 Legend: 149 Client: (D)TLS client 150 Front-End: (D)TLS server (could be a TLS-termination service like a CDN) 151 Back-End: Service with access to private key 153 2. Conventions and Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 2.1. Change Log 163 RFC EDITOR PLEASE DELETE THIS SECTION. 165 (*) indicates changes to the wire protocol. 167 draft-11 169 * Editorial changes based on AD comments 171 * Add support for DTLS 173 * Address address ambiguity in cert expiry 175 draft-10 177 * Address superficial comments 179 * Add example certificate 181 draft-09 183 * Address case nits 185 * Fix section bullets in 4.1.3. 187 * Add operational considerations section for clock skew 189 * Add text around using an oracle to forge DCs in the future and 190 past 192 * Add text about certificate extension vs EKU 194 draft-08 196 * Include details about the impact of signature forgery attacks 198 * Copy edits 200 * Fix section about DC reuse 202 * Incorporate feedback from Jonathan Hammell and Kevin Jacobs on the 203 list 205 draft-07 207 * Minor text improvements 209 draft-06 211 * Modified IANA section, fixed nits 213 draft-05 215 * Removed support for PKCS 1.5 RSA signature algorithms. 217 * Additional security considerations. 219 draft-04 221 * Add support for client certificates. 223 draft-03 225 * Remove protocol version from the Credential structure. (*) 227 draft-02 229 * Change public key type. (*) 231 * Change DelegationUsage extension to be NULL and define its object 232 identifier. 234 * Drop support for TLS 1.2. 236 * Add the protocol version and credential signature algorithm to the 237 Credential structure. (*) 239 * Specify undefined behavior in a few cases: when the client 240 receives a DC without indicated support; when the client indicates 241 the extension in an non-valid protocol version; and when DCs are 242 sent as extensions to certificates other than the end-entity 243 certificate. 245 3. Solution Overview 247 A delegated credential (DC) is a digitally signed data structure with 248 two semantic fields: a validity interval and a public key (along with 249 its associated signature algorithm). The signature on the delegated 250 credential indicates a delegation from the certificate that is issued 251 to the peer. The private key used to sign a credential corresponds 252 to the public key of the peer's X.509 end-entity certificate 253 [RFC5280]. 255 A (D)TLS handshake that uses delegated credentials differs from a 256 standard handshake in a few important ways: 258 * The initiating peer provides an extension in its ClientHello or 259 CertificateRequest that indicates support for this mechanism. 261 * The peer sending the Certificate message provides both the 262 certificate chain terminating in its certificate as well as the 263 delegated credential. 265 * The initiator uses information from the peer's certificate to 266 verify the delegated credential and that the peer is asserting an 267 expected identity, determining an authentication result for the 268 peer. 270 * Peers accepting the delegated credential use it as the certificate 271 key for the (D)TLS handshake. 273 As detailed in Section 4, the delegated credential is 274 cryptographically bound to the end-entity certificate with which the 275 credential may be used. This document specifies the use of delegated 276 credentials in (D)TLS 1.3 or later; their use in prior versions of 277 the protocol is not allowed. 279 Delegated credentials allow a peer to terminate (D)TLS connections on 280 behalf of the certificate owner. If a credential is stolen, there is 281 no mechanism for revoking it without revoking the certificate itself. 282 To limit exposure in case of the compromise of a delegated 283 credential's private key, delegated credentials have a maximum 284 validity period. In the absence of an application profile standard 285 specifying otherwise, the maximum validity period is set to 7 days. 286 Peers MUST NOT issue credentials with a validity period longer than 287 the maximum validity period or that extends beyond the validity 288 period of the delegation certificate. This mechanism is described in 289 detail in Section 4.1. 291 It was noted in [XPROT] that certificates in use by servers that 292 support outdated protocols such as SSLv2 can be used to forge 293 signatures for certificates that contain the keyEncipherment KeyUsage 294 ([RFC5280] section 4.2.1.3). In order to reduce the risk of cross- 295 protocol attacks on certificates that are not intended to be used 296 with DC-capable TLS stacks, we define a new DelegationUsage extension 297 to X.509 that permits use of delegated credentials. (See 298 Section 4.2.) 300 3.1. Rationale 302 Delegated credentials present a better alternative than other 303 delegation mechanisms like proxy certificates [RFC3820] for several 304 reasons: 306 * There is no change needed to certificate validation at the PKI 307 layer. 309 * X.509 semantics are very rich. This can cause unintended 310 consequences if a service owner creates a proxy certificate where 311 the properties differ from the leaf certificate. Proxy 312 certificates can be useful in controlled environments, but remain 313 a risk in scenarios where the additional flexibility they provide 314 is not necessary. For this reason, delegated credentials have 315 very restricted semantics that should not conflict with X.509 316 semantics. 318 * Proxy certificates rely on the certificate path building process 319 to establish a binding between the proxy certificate and the end- 320 entity certificate. Since the certificate path building process 321 is not cryptographically protected, it is possible that a proxy 322 certificate could be bound to another certificate with the same 323 public key, with different X.509 parameters. Delegated 324 credentials, which rely on a cryptographic binding between the 325 entire certificate and the delegated credential, cannot. 327 * Each delegated credential is bound to a specific signature 328 algorithm for use in the (D)TLS handshake ([RFC8446] section 329 4.2.3). This prevents them from being used with other, perhaps 330 unintended, signature algorithms. The signature algorithm bound 331 to the delegated credential can be chosen independently of the set 332 of signature algorithms supported by the end-entity certificate. 334 3.2. Related Work 336 Many of the use cases for delegated credentials can also be addressed 337 using purely server-side mechanisms that do not require changes to 338 client behavior (e.g., a PKCS#11 interface or a remote signing 339 mechanism, [KEYLESS] being one example). These mechanisms, however, 340 incur per-transaction latency, since the front-end server has to 341 interact with a back-end server that holds a private key. The 342 mechanism proposed in this document allows the delegation to be done 343 off-line, with no per-transaction latency. The figure below compares 344 the message flows for these two mechanisms with (D)TLS 1.3 [RFC8446] 345 [I-D.ietf-tls-dtls13]. 347 Remote key signing: 349 Client Front-End Back-End 350 |----ClientHello--->| | 351 |<---ServerHello----| | 352 |<---Certificate----| | 353 | |<---remote sign---->| 354 |<---CertVerify-----| | 355 | ... | | 357 Delegated Credential: 359 Client Front-End Back-End 360 | |<--DC distribution->| 361 |----ClientHello--->| | 362 |<---ServerHello----| | 363 |<---Certificate----| | 364 |<---CertVerify-----| | 365 | ... | | 367 Legend: 368 Client: (D)TLS client 369 Front-End: (D)TLS server (could be a TLS-termination service like a CDN) 370 Back-End: Service with access to private key 372 These two mechanisms can be complementary. A server could use 373 delegated credentials for clients that support them, while using a 374 server-side mechanism to support legacy clients. Both mechanisms 375 require a trusted relationship between the Front-End and Back-End -- 376 the delegated credential can be used in place of a certificate 377 private key. 379 Use of short-lived certificates with automated certificate issuance, 380 e.g., with Automated Certificate Management Environment (ACME) 381 [RFC8555], reduces the risk of key compromise, but has several 382 limitations. Specifically, it introduces an operationally-critical 383 dependency on an external party (the CA). It also limits the types 384 of algorithms supported for (D)TLS authentication to those the CA is 385 willing to issue a certificate for. Nonetheless, existing automated 386 issuance APIs like ACME may be useful for provisioning delegated 387 credentials. 389 4. Delegated Credentials 391 While X.509 forbids end-entity certificates from being used as 392 issuers for other certificates, it is valid to use them to issue 393 other signed objects as long as the certificate contains the 394 digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). (All 395 certificates compatible with TLS 1.3 are required to contain the 396 digitalSignature KeyUsage.) This document defines a new signed 397 object format that would encode only the semantics that are needed 398 for this application. The Credential has the following structure: 400 struct { 401 uint32 valid_time; 402 SignatureScheme dc_cert_verify_algorithm; 403 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 404 } Credential; 406 valid_time: Time, in seconds relative to the delegation 407 certificate's notBefore value, after which the delegated 408 credential is no longer valid. By default, unless set to an 409 alternative value by an application profile (see 410 Section Section 3), endpoints will reject delegated credentials 411 that expire more than 7 days from the current time (as described 412 in Section 4.1.3). 414 dc_cert_verify_algorithm: The signature algorithm of the Credential 415 key pair, where the type SignatureScheme is as defined in 416 [RFC8446]. This is expected to be the same as the sender's 417 CertificateVerify.algorithm (as described in Section 4.1.3). Only 418 signature algorithms allowed for use in CertificateVerify messages 419 are allowed (as described in [RFC8446] Section 11). When using 420 RSA, the public key MUST NOT use the rsaEncryption OID. As a 421 result, the following algorithms are not allowed for use with 422 delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, 423 rsa_pss_rsae_sha512. 425 ASN1_subjectPublicKeyInfo: The Credential's public key, a DER- 426 encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. 428 The DelegatedCredential has the following structure: 430 struct { 431 Credential cred; 432 SignatureScheme algorithm; 433 opaque signature<0..2^16-1>; 434 } DelegatedCredential; 436 cred: The Credential structure as previously defined. 438 algorithm: The signature algorithm used to create 439 DelegatedCredential.signature. 441 signature: The delegation, a signature that binds the credential to 442 the end-entity certificate's public key as specified below. The 443 signature scheme is specified by DelegatedCredential.algorithm. 445 The signature of the DelegatedCredential is computed over the 446 concatenation of: 448 1. An octet stream that consists of octet 32 (0x20) repeated 64 449 times. 451 2. The non-null terminated context string "TLS, server delegated 452 credentials" for server authentication and "TLS, client delegated 453 credentials" for client authentication. 455 3. A single octet 0x00, which serves as the separator. 457 4. The DER-encoded X.509 end-entity certificate used to sign the 458 DelegatedCredential. 460 5. DelegatedCredential.cred. 462 6. DelegatedCredential.algorithm. 464 The signature is computed by using the private key of the peer's end- 465 entity certificate, with the algorithm indicated by 466 DelegatedCredential.algorithm. 468 The signature effectively binds the credential to the parameters of 469 the handshake in which it is used. In particular, it ensures that 470 credentials are only used with the certificate and signature 471 algorithm chosen by the delegator. 473 The code changes required in order to create and verify delegated 474 credentials, and the implementation complexity this entails, are 475 localized to the (D)TLS stack. This has the advantage of avoiding 476 changes to the often-delicate security-critical PKI code. 478 4.1. Client and Server Behavior 480 This document defines the following (D)TLS extension code point. 482 enum { 483 ... 484 delegated_credential(34), 485 (65535) 486 } ExtensionType; 488 4.1.1. Server Authentication 490 A client that is willing to use delegated credentials in a connection 491 SHALL send a "delegated_credential" extension in its ClientHello. 492 The body of the extension consists of a SignatureSchemeList (defined 493 in [RFC8446]): 495 struct { 496 SignatureScheme supported_signature_algorithm<2..2^16-2>; 497 } SignatureSchemeList; 499 If the client receives a delegated credential without having 500 indicated support in its ClientHello, then the client MUST abort the 501 handshake with an "unexpected_message" alert. 503 If the extension is present, the server MAY send a delegated 504 credential; if the extension is not present, the server MUST NOT send 505 a delegated credential. When a (D)TLS version negotiated is less 506 than 1.3, the server MUST ignore this extension. An example of when 507 a server could choose not to send a delegated credential is when the 508 SignatureSchemes listed only contain signature schemes for which a 509 corresponding delegated credential does not exist or are otherwise 510 unsuitable for the connection. 512 The server MUST send the delegated credential as an extension in the 513 CertificateEntry of its end-entity certificate; the client SHOULD 514 ignore delegated credentials sent as extensions to any other 515 certificate. 517 The algorithm field MUST be of a type advertised by the client in the 518 "signature_algorithms" extension of the ClientHello message and the 519 dc_cert_verify_algorithm field MUST be of a type advertised by the 520 client in the SignatureSchemeList and is considered not valid 521 otherwise. Clients that receive non-valid delegated credentials MUST 522 terminate the connection with an "illegal_parameter" alert. 524 4.1.2. Client Authentication 526 A server that supports this specification SHALL send a 527 "delegated_credential" extension in the CertificateRequest message 528 when requesting client authentication. The body of the extension 529 consists of a SignatureSchemeList. If the server receives a 530 delegated credential without having indicated support in its 531 CertificateRequest, then the server MUST abort with an 532 "unexpected_message" alert. 534 If the extension is present, the client MAY send a delegated 535 credential; if the extension is not present, the client MUST NOT send 536 a delegated credential. When a (D)TLS version negotiated is less 537 than 1.3, the client MUST ignore this extension. 539 The client MUST send the DC as an extension in the CertificateEntry 540 of its end-entity certificate; the server SHOULD ignore delegated 541 credentials sent as extensions to any other certificate. 543 The algorithm field MUST be of a type advertised by the server in the 544 "signature_algorithms" extension of the CertificateRequest message 545 and the dc_cert_verify_algorithm field MUST be of a type advertised 546 by the server in the SignatureSchemeList and is considered not valid 547 otherwise. Servers that receive non-valid delegated credentials MUST 548 terminate the connection with an "illegal_parameter" alert. 550 4.1.3. Validating a Delegated Credential 552 On receiving a delegated credential and certificate chain, the peer 553 validates the certificate chain and matches the end-entity 554 certificate to the peer's expected identity in the same way that it 555 is done when delegated credentials are not in use. It then performs 556 the following checks with expiry time set to the delegation 557 certificate's notBefore value plus 558 DelegatedCredential.cred.valid_time: 560 1. Verify that the current time is within the validity interval of 561 the credential. This is done by asserting that the current time 562 does not exceed the expiry time. (The start time of the 563 credential is implicitly validated as part of certificate 564 validation.) 566 2. Verify that the delegated credential's remaining validity period 567 is no more than the maximum validity period. This is done by 568 asserting that the expiry time does not exceed the current time 569 plus the maximum validity period (7 days by default). 571 3. Verify that dc_cert_verify_algorithm matches the scheme indicated 572 in the peer's CertificateVerify message and that the algorithm is 573 allowed for use with delegated credentials. 575 4. Verify that the end-entity certificate satisfies the conditions 576 in Section 4.2. 578 5. Use the public key in the peer's end-entity certificate to verify 579 the signature of the credential using the algorithm indicated by 580 DelegatedCredential.algorithm. 582 If one or more of these checks fail, then the delegated credential is 583 deemed not valid. Clients and servers that receive non-valid 584 delegated credentials MUST terminate the connection with an 585 "illegal_parameter" alert. 587 If successful, the participant receiving the Certificate message uses 588 the public key in DelegatedCredential.cred to verify the signature in 589 the peer's CertificateVerify message. 591 4.2. Certificate Requirements 593 This document defines a new X.509 extension, DelegationUsage, to be 594 used in the certificate when the certificate permits the usage of 595 delegated credentials. What follows is the ASN.1 [X.680] for the 596 DelegationUsage certificate extension. 598 ext-delegationUsage EXTENSION ::= { 599 SYNTAX DelegationUsage IDENTIFIED BY id-pe-delegationUsage 600 } 602 DelegationUsage ::= NULL 604 id-pe-delegationUsage OBJECT IDENTIFIER ::= 605 { iso(1) identified-organization(3) dod(6) internet(1) 606 private(4) enterprise(1) id-cloudflare(44363) 44 } 608 The extension MUST be marked non-critical. (See Section 4.2 of 609 [RFC5280].) An endpoint MUST NOT accept a delegated credential 610 unless the peer's end-entity certificate satisfies the following 611 criteria: 613 * It has the DelegationUsage extension. 615 * It has the digitalSignature KeyUsage (see the KeyUsage extension 616 defined in [RFC5280]). 618 A new extension was chosen instead of adding a new Extended Key Usage 619 (EKU) to be compatible with deployed (D)TLS and PKI software stacks 620 without requiring CAs to issue new intermediate certificates. 622 5. Operational Considerations 624 The operational consideration documented in this section should be 625 taken into consideration when using Delegated Certificates. 627 5.1. Client Clock Skew 629 One of the risks of deploying a short-lived credential system based 630 on absolute time is client clock skew. If a client's clock is 631 sufficiently ahead or behind of the server's clock, then clients will 632 reject delegated credentials that are valid from the server's 633 perspective. Clock skew also affects the validity of the original 634 certificates. The lifetime of the delegated credential should be set 635 taking clock skew into account. Clock skew may affect a delegated 636 credential at the beginning and end of its validity periods, which 637 should also be taken into account. 639 6. IANA Considerations 641 This document registers the "delegated_credential" extension in the 642 "TLS ExtensionType Values" registry. The "delegated_credential" 643 extension has been assigned a code point of 34. The IANA registry 644 lists this extension as "Recommended" (i.e., "Y") and indicates that 645 it may appear in the ClientHello (CH), CertificateRequest (CR), or 646 Certificate (CT) messages in (D)TLS 1.3 [RFC8446] 647 [I-D.ietf-tls-dtls13]. Additionally, the "DTLS-Only" column is 648 assigned the value "N". 650 This document also defines an ASN.1 module for the DelegationUsage 651 certificate extension in Appendix A. IANA has registered value 95 652 for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX 653 Module Identifier" (1.3.5.1.5.5.7.0) registry. An OID for the 654 DelegationUsage certificate extension is not needed as it is already 655 assigned to the extension from Cloudflare's IANA Private Enterprise 656 Number (PEN) arc. 658 7. Security Considerations 660 The security consideration documented in this section should be taken 661 into consideration when using Delegated Certificates. 663 7.1. Security of Delegated Credential's Private Key 665 Delegated credentials limit the exposure of the private key used in a 666 (D)TLS connection by limiting its validity period. An attacker who 667 compromises the private key of a delegated credential cannot create 668 new delegated credentials, but they can impersonate the compromised 669 party in new TLS connections until the delegated credential expires. 671 Thus, delegated credentials should not be used to send a delegation 672 to an untrusted party, but are meant to be used between parties that 673 have some trust relationship with each other. The secrecy of the 674 delegated credential's private key is thus important, and access 675 control mechanisms SHOULD be used to protect it, including file 676 system controls, physical security, or hardware security modules. 678 7.2. Re-use of Delegated Credentials in Multiple Contexts 680 It is not possible to use the same delegated credential for both 681 client and server authentication because issuing parties compute the 682 corresponding signature using a context string unique to the intended 683 role (client or server). 685 7.3. Revocation of Delegated Credentials 687 Delegated credentials do not provide any additional form of early 688 revocation. Since it is short-lived, the expiry of the delegated 689 credential revokes the credential. Revocation of the long term 690 private key that signs the delegated credential (from the end-entity 691 certificate) also implicitly revokes the delegated credential. 693 7.4. Interactions with Session Resumption 695 If a peer decides to cache the certificate chain and re-validate it 696 when resuming a connection, they SHOULD also cache the associated 697 delegated credential and re-validate it. Failing to do so may result 698 in resuming connections for which the DC has expired. 700 7.5. Privacy Considerations 702 Delegated credentials can be valid for 7 days (by default) and it is 703 much easier for a service to create delegated credentials than a 704 certificate signed by a CA. A service could determine the client 705 time and clock skew by creating several delegated credentials with 706 different expiry timestamps and observing whether the client would 707 accept it. Client time could be unique and thus privacy-sensitive 708 clients, such as browsers in incognito mode, who do not trust the 709 service might not want to advertise support for delegated credentials 710 or limit the number of probes that a server can perform. 712 7.6. The Impact of Signature Forgery Attacks 714 Delegated credentials are only used in (D)TLS 1.3 connections. 715 However, the certificate that signs a delegated credential may be 716 used in other contexts such as (D)TLS 1.2. Using a certificate in 717 multiple contexts opens up a potential cross-protocol attack against 718 delegated credentials in (D)TLS 1.3. 720 When (D)TLS 1.2 servers support RSA key exchange, they may be 721 vulnerable to attacks that allow forging an RSA signature over an 722 arbitrary message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) 723 describes a mitigation strategy requiring careful implementation of 724 timing resistant countermeasures for preventing these attacks. 725 Experience shows that in practice, server implementations may fail to 726 fully stop these attacks due to the complexity of this mitigation 727 [ROBOT]. For (D)TLS 1.2 servers that support RSA key exchange using 728 a DC-enabled end-entity certificate, a hypothetical signature forgery 729 attack would allow forging a signature over a delegated credential. 730 The forged delegated credential could then be used by the attacker as 731 the equivalent of a on-path-attacker, valid for a maximum of 7 days 732 (if the default valid_time is used). 734 Server operators should therefore minimize the risk of using DC- 735 enabled end-entity certificates where a signature forgery oracle may 736 be present. If possible, server operators may choose to use DC- 737 enabled certificates only for signing credentials, and not for 738 serving non-DC (D)TLS traffic. Furthermore, server operators may use 739 elliptic curve certificates for DC-enabled traffic, while using RSA 740 certificates without the DelegationUsage certificate extension for 741 non-DC traffic; this completely prevents such attacks. 743 Note that if a signature can be forged over an arbitrary credential, 744 the attacker can choose any value for the valid_time field. Repeated 745 signature forgeries therefore allow the attacker to create multiple 746 delegated credentials that can cover the entire validity period of 747 the certificate. Temporary exposure of the key or a signing oracle 748 may allow the attacker to impersonate a server for the lifetime of 749 the certificate. 751 8. Acknowledgements 753 Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh 754 Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson 755 Ladd, Robert Merget, Juraj Somorovsky, Nimrod Aviram for their 756 discussions, ideas, and bugs they have found. 758 9. References 760 9.1. Normative References 762 [I-D.ietf-tls-dtls13] 763 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 764 Datagram Transport Layer Security (DTLS) Protocol Version 765 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 766 dtls13-43, 30 April 2021, 767 . 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, 772 DOI 10.17487/RFC2119, March 1997, 773 . 775 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 776 Housley, R., and W. Polk, "Internet X.509 Public Key 777 Infrastructure Certificate and Certificate Revocation List 778 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 779 . 781 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 782 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 783 May 2017, . 785 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 786 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 787 . 789 [X.680] ITU-T, "Information technology - Abstract Syntax Notation 790 One (ASN.1): Specification of basic notation", ISO/ 791 IEC 8824-1:2015, November 2015. 793 [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: 794 Specification of Basic Encoding Rules (BER), Canonical 795 Encoding Rules (CER) and Distinguished Encoding Rules 796 (DER)", ISO/IEC 8825-1:2015, November 2015. 798 9.2. Informative References 800 [BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against 801 Protocols Based on RSA Encryption Standard PKCS #1", 802 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, 803 pages: 1-12 , 1998. 805 [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake 806 Proxying", IEEE Trustcom/BigDataSE/ISPA 2015 , 2015. 808 [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. 809 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 810 Proxy Certificate Profile", RFC 3820, 811 DOI 10.17487/RFC3820, June 2004, 812 . 814 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 815 (TLS) Protocol Version 1.2", RFC 5246, 816 DOI 10.17487/RFC5246, August 2008, 817 . 819 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 820 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 821 DOI 10.17487/RFC5912, June 2010, 822 . 824 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 825 Signature Algorithm (EdDSA)", RFC 8032, 826 DOI 10.17487/RFC8032, January 2017, 827 . 829 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 830 Kasten, "Automatic Certificate Management Environment 831 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 832 . 834 [ROBOT] Boeck, H., Somorovsky, J., and C. Young, "Return Of 835 Bleichenbacher's Oracle Threat (ROBOT)", 27th USENIX 836 Security Symposium , 2018. 838 [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the 839 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 840 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC 841 Conference on Computer and Communications Security , 2015. 843 Appendix A. ASN.1 Module 845 The following ASN.1 module provides the complete definition of the 846 DelegationUsage certificate extension. The ASN.1 module makes 847 imports from [RFC5912]. 849 DelegatedCredentialExtn 850 { iso(1) identified-organization(3) dod(6) internet(1) 851 security(5) mechanisms(5) pkix(7) id-mod(0) 852 id-mod-delegated-credential-extn(95) } 854 DEFINITIONS IMPLICIT TAGS ::= 855 BEGIN 857 -- EXPORT ALL 859 IMPORTS 861 EXTENSION 862 FROM PKIX-CommonTypes-2009 -- From RFC 5912 863 { iso(1) identified-organization(3) dod(6) internet(1) 864 security(5) mechanisms(5) pkix(7) id-mod(0) 865 id-mod-pkixCommon-02(57) } ; 867 -- OID 869 id-cloudflare OBJECT IDENTIFIER ::= 870 { iso(1) identified-organization(3) dod(6) internet(1) private(4) 871 enterprise(1) 44363 } 873 -- EXTENSION 875 ext-delegationUsage EXTENSION ::= 876 { SYNTAX DelegationUsage 877 IDENTIFIED BY id-pe-delegationUsage } 879 id-pe-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 } 881 DelegationUsage ::= NULL 883 END 885 Appendix B. Example Certificate 887 The following is an example of a delegation certificate which 888 satisfies the requirements described in Section 4.2 (i.e., uses the 889 DelegationUsage extension and has the digitalSignature KeyUsage). 891 -----BEGIN CERTIFICATE----- 892 MIIFRjCCBMugAwIBAgIQDGevB+lY0o/OecHFSJ6YnTAKBggqhkjOPQQDAzBMMQsw 893 CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp 894 Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAzMjYwMDAwMDBaFw0yMTAz 895 MzAxMjAwMDBaMGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw 896 FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMu 897 MRMwEQYDVQQDEwprYzJrZG0uY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE 898 d4azI83Bw0fcPgfoeiZpZZnwGuxjBjv++wzE0zAj8vNiUkKxOWSQiGNLn+xlWUpL 899 lw9djRN1rLmVmn2gb9GgdKOCA28wggNrMB8GA1UdIwQYMBaAFKOd5h/52jlPwG7o 900 kcuVpdox4gqfMB0GA1UdDgQWBBSfcb7fS3fUFAyB91fRcwoDPtgtJjAjBgNVHREE 901 HDAaggprYzJrZG0uY29tggwqLmtjMmtkbS5jb20wDgYDVR0PAQH/BAQDAgeAMB0G 902 A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBpBgNVHR8EYjBgMC6gLKAqhiho 903 dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMC6gLKAqhiho 904 dHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMEwGA1UdIARF 905 MEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2lj 906 ZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUFBwEBBG8wbTAkBggrBgEFBQcw 907 AYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUGCCsGAQUFBzAChjlodHRwOi8v 908 Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRFQ0NTZWN1cmVTZXJ2ZXJDQS5j 909 cnQwDAYDVR0TAQH/BAIwADAPBgkrBgEEAYLaSywEAgUAMIIBfgYKKwYBBAHWeQIE 910 AgSCAW4EggFqAWgAdgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAA 911 AWm5hYJ5AAAEAwBHMEUCICiGfq+hSThRL2m8H0awoDR8OpnEHNkF0nI6nL5yYL/j 912 AiEAxwebGs/T6Es0YarPzoQJrVZqk+sHH/t+jrSrKd5TDjcAdgCHdb/nWXz4jEOZ 913 X73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWm5hYNgAAAEAwBHMEUCIQD9OWA8KGL6 914 bxDKfgIleHJWB0iWieRs88VgJyfAg/aFDgIgQ/OsdSF9XOy1foqge0DTDM2FExuw 915 0JR0AGZWXoNtJzMAdgBElGUusO7Or8RAB9io/ijA2uaCvtjLMbU/0zOWtbaBqAAA 916 AWm5hYHgAAAEAwBHMEUCIQC4vua1n3BqthEqpA/VBTcsNwMtAwpCuac2IhJ9wx6X 917 /AIgb+o00k28JQo9TMpP4vzJ3BD3HXWSNc2Zizbq7mkUQYMwCgYIKoZIzj0EAwMD 918 aQAwZgIxAJsX7d0SuA8ddf/m7IWfNfs3MQfJyGkEezMJX1t6sRso5z50SS12LpXe 919 muGa1FE2ZgIxAL+CDUF5pz7mhrAEIjQ1MqlpF9tH40dJGvYZZQ3W23cMzSkDfvlt 920 y5S4RfWHIIPjbw== 921 -----END CERTIFICATE----- 923 Authors' Addresses 925 Richard Barnes 926 Cisco 927 Email: rlb@ipv.sx 929 Subodh Iyengar 930 Facebook 931 Email: subodh@fb.com 933 Nick Sullivan 934 Cloudflare 935 Email: nick@cloudflare.com 937 Eric Rescorla 938 Mozilla 939 Email: ekr@rtfm.com