idnits 2.17.1 draft-ietf-tls-subcerts-04.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 358: '...this specification SHALL send an empty...' RFC 2119 keyword, line 361: '... client MUST abort with an "unexpect...' RFC 2119 keyword, line 363: '...esent, the server MAY send a delegated...' RFC 2119 keyword, line 364: '... not present, the server MUST NOT send...' RFC 2119 keyword, line 365: '...ial. The server MUST ignore the exten...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 08, 2019) is 1748 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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: January 9, 2020 Facebook 6 N. Sullivan 7 Cloudflare 8 E. Rescorla 9 RTFM, Inc. 10 July 08, 2019 12 Delegated Credentials for TLS 13 draft-ietf-tls-subcerts-04 15 Abstract 17 The organizational separation between the operator of a TLS endpoint 18 and the certification authority can create limitations. For example, 19 the lifetime of certificates, how they may be used, and the 20 algorithms they support are ultimately determined by the 21 certification authority. This document describes a mechanism by 22 which operators may delegate their own credentials for use in TLS, 23 without breaking compatibility with peers that do not support this 24 specification. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 9, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Client and Server behavior . . . . . . . . . . . . . . . 8 67 3.1.1. Server authentication . . . . . . . . . . . . . . . . 8 68 3.1.2. Client authentication . . . . . . . . . . . . . . . . 9 69 3.1.3. Validating a Delegated Credential . . . . . . . . . . 9 70 3.2. Certificate Requirements . . . . . . . . . . . . . . . . 10 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 5.1. Security of delegated private key . . . . . . . . . . . . 10 74 5.2. Re-use of delegated credentials in multiple contexts . . 11 75 5.3. Revocation of delegated credentials . . . . . . . . . . . 11 76 5.4. Privacy considerations . . . . . . . . . . . . . . . . . 11 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 7.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 Typically, a TLS server uses a certificate provided by some entity 86 other than the operator of the server (a "Certification Authority" or 87 CA) [RFC8446] [RFC5280]. This organizational separation makes the 88 TLS server operator dependent on the CA for some aspects of its 89 operations, for example: 91 o Whenever the server operator wants to deploy a new certificate, it 92 has to interact with the CA. 94 o The server operator can only use TLS authentication schemes for 95 which the CA will issue credentials. 97 These dependencies cause problems in practice. Server operators 98 often want to create short-lived certificates for servers in low- 99 trust zones such as CDNs or remote data centers. This allows server 100 operators to limit the exposure of keys in cases that they do not 101 realize a compromise has occurred. The risk inherent in cross- 102 organizational transactions makes it operationally infeasible to rely 103 on an external CA for such short-lived credentials. In OCSP stapling 104 (i.e., using the Certificate Status extension types ocsp [RFC6066] or 105 ocsp_multi [RFC6961]), if an operator chooses to talk frequently to 106 the CA to obtain stapled responses, then failure to fetch an OCSP 107 stapled response results only in degraded performance. On the other 108 hand, failure to fetch a potentially large number of short lived 109 certificates would result in the service not being available, which 110 creates greater operational risk. 112 To remove these dependencies, this document proposes a limited 113 delegation mechanism that allows a TLS peer to issue its own 114 credentials within the scope of a certificate issued by an external 115 CA. Because the above problems do not relate to the CA's inherent 116 function of validating possession of names, it is safe to make such 117 delegations as long as they only enable the recipient of the 118 delegation to speak for names that the CA has authorized. For 119 clarity, we will refer to the certificate issued by the CA as a 120 "certificate", or "delegation certificate", and the one issued by the 121 operator as a "delegated credential" or "DC". 123 1.1. Change Log 125 (*) indicates changes to the wire protocol. 127 draft-04 129 o Add support for client certificates. 131 draft-03 133 o Remove protocol version from the Credential structure. (*) 135 draft-02 137 o Change public key type. (*) 139 o Change DelegationUsage extension to be NULL and define its object 140 identifier. 142 o Drop support for TLS 1.2. 144 o Add the protocol version and credential signature algorithm to the 145 Credential structure. (*) 147 o Specify undefined behavior in a few cases: when the client 148 receives a DC without indicated support; when the client indicates 149 the extension in an invalid protocol version; and when DCs are 150 sent as extensions to certificates other than the end-entity 151 certificate. 153 2. Solution Overview 155 A delegated credential is a digitally signed data structure with two 156 semantic fields: a validity interval and a public key (along with its 157 associated signature algorithm). The signature on the credential 158 indicates a delegation from the certificate that is issued to the 159 peer. The secret key used to sign a credential corresponds to the 160 public key of the peer's X.509 end-entity certificate. 162 A TLS handshake that uses delegated credentials differs from a normal 163 handshake in a few important ways: 165 o The initiating peer provides an extension in its ClientHello or 166 CertificateRequest that indicates support for this mechanism. 168 o The peer sending the Certificate message provides both the 169 certificate chain terminating in its certificate as well as the 170 delegated credential. 172 o The authenticating intitiator uses information from the peer's 173 certificate to verify the delegated credential and that the peer 174 is asserting an expected identity. 176 o Peers accepting the delegated credential use it as the 177 certificate's working key for the TLS hadshake 179 As detailed in Section 3, the delegated credential is 180 cryptographically bound to the end-entity certificate with which the 181 credential may be used. This document specifies the use of delegated 182 credentials in TLS 1.3 or later; their use in prior versions of the 183 protocol is not allowed. 185 Delegated credentials allow a peer to terminate TLS connections on 186 behalf of the certificate owner. If a credential is stolen, there is 187 no mechanism for revoking it without revoking the certificate itself. 188 To limit exposure in case a delegated credential is compromised, 189 peers may not issue credentials with a validity period longer than 7 190 days. This mechanism is described in detail in Section 3.1. 192 It was noted in [XPROT] that certificates in use by servers that 193 support outdated protocols such as SSLv2 can be used to forge 194 signatures for certificates that contain the keyEncipherment KeyUsage 195 ([RFC5280] section 4.2.1.3). In order to prevent this type of cross- 196 protocol attack, we define a new DelegationUsage extension to X.509 197 that permits use of delegated credentials. (See Section 3.2.) 199 2.1. Rationale 201 Delegated credentials present a better alternative than other 202 delegation mechanisms like proxy certificates [RFC3820] for several 203 reasons: 205 o There is no change needed to certificate validation at the PKI 206 layer. 208 o X.509 semantics are very rich. This can cause unintended 209 consequences if a service owner creates a proxy certificate where 210 the properties differ from the leaf certificate. For this reason, 211 delegated credentials have very restricted semantics that should 212 not conflict with X.509 semantics. 214 o Proxy certificates rely on the certificate path building process 215 to establish a binding between the proxy certificate and the 216 server certificate. Since the certificate path building process 217 is not cryptographically protected, it is possible that a proxy 218 certificate could be bound to another certificate with the same 219 public key, with different X.509 parameters. Delegated 220 credentials, which rely on a cryptographic binding between the 221 entire certificate and the delegated credential, cannot. 223 o Each delegated credential is bound to a specific signature 224 algorithm that may be used to sign the TLS handshake ([RFC8446] 225 section 4.2.3). This prevents them from being used with other, 226 perhaps unintended signature algorithms. 228 2.2. Related Work 230 Many of the use cases for delegated credentials can also be addressed 231 using purely server-side mechanisms that do not require changes to 232 client behavior (e.g., LURK [I-D.mglt-lurk-tls-requirements]). These 233 mechanisms, however, incur per-transaction latency, since the front- 234 end server has to interact with a back-end server that holds a 235 private key. The mechanism proposed in this document allows the 236 delegation to be done off-line, with no per-transaction latency. The 237 figure below compares the message flows for these two mechanisms with 238 TLS 1.3 [I-D.ietf-tls-tls13]. 240 LURK: 242 Client Front-End Back-End 243 |----ClientHello--->| | 244 |<---ServerHello----| | 245 |<---Certificate----| | 246 | |<-------LURK------->| 247 |<---CertVerify-----| | 248 | ... | | 250 Delegated credentials: 252 Client Front-End Back-End 253 | |<----DC minting---->| 254 |----ClientHello--->| | 255 |<---ServerHello----| | 256 |<---Certificate----| | 257 |<---CertVerify-----| | 258 | ... | | 260 These two mechanisms can be complementary. A server could use 261 credentials for clients that support them, while using LURK to 262 support legacy clients. 264 It is possible to address the short-lived certificate concerns above 265 by automating certificate issuance, e.g., with ACME 266 [I-D.ietf-acme-acme]. In addition to requiring frequent 267 operationally-critical interactions with an external party, this 268 makes the server operator dependent on the CA's willingness to issue 269 certificates with sufficiently short lifetimes. It also fails to 270 address the issues with algorithm support. Nonetheless, existing 271 automated issuance APIs like ACME may be useful for provisioning 272 credentials within an operator network. 274 3. Delegated Credentials 276 While X.509 forbids end-entity certificates from being used as 277 issuers for other certificates, it is perfectly fine to use them to 278 issue other signed objects as long as the certificate contains the 279 digitalSignature KeyUsage (RFC5280 section 4.2.1.3). We define a new 280 signed object format that would encode only the semantics that are 281 needed for this application. The credential has the following 282 structure: 284 struct { 285 uint32 valid_time; 286 SignatureScheme expected_cert_verify_algorithm; 287 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 288 } Credential; 290 valid_time: Relative time in seconds from the beginning of the 291 delegation certificate's notBefore value after which the delegated 292 credential is no longer valid. 294 expected_cert_verify_algorithm: The signature algorithm of the 295 credential key pair, where the type SignatureScheme is as defined 296 in [RFC8446]. This is expected to be the same as 297 CertificateVerify.algorithm sent by the server. 299 ASN1_subjectPublicKeyInfo: The credential's public key, a DER- 300 encoded [X690] SubjectPublicKeyInfo as defined in [RFC5280]. 302 The delegated credential has the following structure: 304 struct { 305 Credential cred; 306 SignatureScheme algorithm; 307 opaque signature<0..2^16-1>; 308 } DelegatedCredential; 310 algorithm: The signature algorithm used to verify 311 DelegatedCredential.signature. 313 signature: The delegation, a signature that binds the credential to 314 the end-entity certificate's public key as specified below. The 315 signature scheme is specified by DelegatedCredential.algorithm. 317 The signature of the DelegatedCredential is computed over the 318 concatenation of: 320 1. A string that consists of octet 32 (0x20) repeated 64 times. 322 2. The context string "TLS, server delegated credentials" for 323 servers and "TLS, client delegated credentials" for clients. 325 3. A single 0 byte, which serves as the separator. 327 4. The DER-encoded X.509 end-entity certificate used to sign the 328 DelegatedCredential. 330 5. DelegatedCredential.cred. 332 6. DelegatedCredential.algorithm. 334 The signature effectively binds the credential to the parameters of 335 the handshake in which it is used. In particular, it ensures that 336 credentials are only used with the certificate and signature 337 algorithm chosen by the delegator. Minimizing their semantics in 338 this way is intended to mitigate the risk of cross protocol attacks 339 involving delegated credentials. 341 The code changes required in order to create and verify delegated 342 credentials, and the implementation complexity this entails, are 343 localized to the TLS stack. This has the advantage of avoiding 344 changes to security-critical and often delicate PKI code. 346 3.1. Client and Server behavior 348 This document defines the following extension code point. 350 enum { 351 ... 352 delegated_credential(TBD), 353 (65535) 354 } ExtensionType; 356 3.1.1. Server authentication 358 A client which supports this specification SHALL send an empty 359 "delegated_credential" extension in its ClientHello. If the client 360 receives a delegated credential without indicating support, then the 361 client MUST abort with an "unexpected_message" alert. 363 If the extension is present, the server MAY send a delegated 364 credential; if the extension is not present, the server MUST NOT send 365 a delegated credential. The server MUST ignore the extension unless 366 TLS 1.3 or a later version is negotiated. 368 The server MUST send the delegated credential as an extension in the 369 CertificateEntry of its end-entity certificate; the client SHOULD 370 ignore delegated credentials sent as extensions to any other 371 certificate. 373 The algorithm and expected_cert_verify_algorithm fields MUST be of a 374 type advertised by the client in the "signature_algorithms" extension 375 and are considered invalid otherwise. Clients that receive invalid 376 delegated credentials MUST terminate the connection with an 377 "illegal_parameter" alert. 379 3.1.2. Client authentication 381 A server which supports this specification SHALL send an empty 382 "delegated_credential" extension in the CertificateRequest message 383 when requesting client authentication. If the server receives a 384 delegated credential without indicating support in its 385 CertificateRequest, then the server MUST abort with an 386 "unexpected_message" alert. 388 If the extension is present, the client MAY send a delegated 389 credential; if the extension is not present, the client MUST NOT send 390 a delegated credential. The client MUST ignore the extension unless 391 TLS 1.3 or a later version is negotiated. 393 The client MUST send the delegated credential as an extension in the 394 CertificateEntry of its end-entity certificate; the server SHOULD 395 ignore delegated credentials sent as extensions to any other 396 certificate. 398 The algorithm and expected_cert_verify_algorithm fields MUST be of a 399 type advertised by the server in the "signature_algorithms" extension 400 and are considered invalid otherwise. Servers that receive invalid 401 delegated credentials MUST terminate the connection with an 402 "illegal_parameter" alert. 404 3.1.3. Validating a Delegated Credential 406 On receiving a delegated credential and a certificate chain, the peer 407 validates the certificate chain and matches the end-entity 408 certificate to the peer's expected identity in the usual way. It 409 also takes the following steps: 411 1. Verify that the current time is within the validity interval of 412 the credential and that the credential's time to live is no more 413 than 7 days. This is done by asserting that the current time is 414 no more than the delegation certificate's notBefore value plus 415 DelegatedCredential.cred.valid_time. 417 2. Verify that expected_cert_verify_algorithm matches the scheme 418 indicated in the peer's CertificateVerify message. 420 3. Verify that the end-entity certificate satisfies the conditions 421 in Section 3.2. 423 4. Use the public key in the peer's end-entity certificate to verify 424 the signature of the credential using the algorithm indicated by 425 DelegatedCredential.algorithm. 427 If one or more of these checks fail, then the delegated credential is 428 deemed invalid. Clients and servers that receive invalid delegated 429 credentials MUST terminate the connection with an "illegal_parameter" 430 alert. If successful, the participant receiving the Certificate 431 message uses the public key in the credential to verify the signature 432 in the peer's CertificateVerify message. 434 3.2. Certificate Requirements 436 We define a new X.509 extension, DelegationUsage, to be used in the 437 certificate when the certificate permits the usage of delegated 438 credentials. 440 id-ce-delegationUsage OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.44363.44 } 441 DelegationUsage ::= NULL 443 The extension MUST be marked non-critical. (See Section 4.2 of 444 [RFC5280].) The client MUST NOT accept a delegated credential unless 445 the server's end-entity certificate satisfies the following criteria: 447 o It has the DelegationUsage extension. 449 o It has the digitalSignature KeyUsage (see the KeyUsage extension 450 defined in [RFC5280]). 452 4. IANA Considerations 454 This document registers the "delegated_credentials" extension in the 455 "TLS ExtensionType Values" registry. The "delegated_credentials" 456 extension has been assigned a code point of TBD. The IANA registry 457 lists this extension as "Recommended" (i.e., "Y") and indicates that 458 it may appear in the ClientHello (CH), CertificateRequest (CR), or 459 Certificate (CT) messages in TLS 1.3 [RFC8446]. 461 5. Security Considerations 463 5.1. Security of delegated private key 465 Delegated credentials limit the exposure of the TLS private key by 466 limiting its validity. An attacker who compromises the private key 467 of a delegated credential can act as a man-in-the-middle until the 468 delegate credential expires, however they cannot create new delegated 469 credentials. Thus, delegated credentials should not be used to send 470 a delegation to an untrusted party, but is meant to be used between 471 parties that have some trust relationship with each other. The 472 secrecy of the delegated private key is thus important and several 473 access control mechanisms SHOULD be used to protect it, including 474 file system controls, physical security, or hardware security 475 modules. 477 5.2. Re-use of delegated credentials in multiple contexts 479 It is possible to use the same delegated credential for both client 480 and server authentication if the Certificate allows it. This is safe 481 because the context string used for delegated credentials is distinct 482 in both contexts. 484 5.3. Revocation of delegated credentials 486 Delegated credentials do not provide any additional form of early 487 revocation. Since it is short lived, the expiry of the delegated 488 credential would revoke the credential. Revocation of the long term 489 private key that signs the delegated credential also implicitly 490 revokes the delegated credential. 492 5.4. Privacy considerations 494 Delegated credentials can be valid for 7 days and it is much easier 495 for a service to create delegated credential than a certificate 496 signed by a CA. A service could determine the client time and clock 497 skew by creating several delegated credentials with different expiry 498 timestamps and observing whether the client would accept it. Client 499 time could be unique and thus privacy sensitive clients, such as 500 browsers in incognito mode, who do not trust the service might not 501 want to advertise support for delegated credentials or limit the 502 number of probes that a server can perform. 504 6. Acknowledgements 506 Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh 507 Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson 508 Ladd for their discussions, ideas, and bugs they have found. 510 7. References 512 7.1. Normative References 514 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 515 Housley, R., and W. Polk, "Internet X.509 Public Key 516 Infrastructure Certificate and Certificate Revocation List 517 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 518 . 520 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 521 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 522 . 524 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 525 Specification of Basic Encoding Rules (BER), Canonical 526 Encoding Rules (CER) and Distinguished Encoding Rules 527 (DER)", ISO/IEC 8825-1:2002, 2002. 529 7.2. Informative References 531 [I-D.ietf-acme-acme] 532 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 533 Kasten, "Automatic Certificate Management Environment 534 (ACME)", draft-ietf-acme-acme-18 (work in progress), 535 December 2018. 537 [I-D.ietf-tls-tls13] 538 Rescorla, E., "The Transport Layer Security (TLS) Protocol 539 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 540 March 2018. 542 [I-D.mglt-lurk-tls-requirements] 543 Migault, D. and K. Ma, "Authentication Model and Security 544 Requirements for the TLS/DTLS Content Provider Edge Server 545 Split Use Case", draft-mglt-lurk-tls-requirements-00 (work 546 in progress), January 2016. 548 [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. 549 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 550 Proxy Certificate Profile", RFC 3820, 551 DOI 10.17487/RFC3820, June 2004, . 554 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 555 Extensions: Extension Definitions", RFC 6066, 556 DOI 10.17487/RFC6066, January 2011, . 559 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 560 Multiple Certificate Status Request Extension", RFC 6961, 561 DOI 10.17487/RFC6961, June 2013, . 564 [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the 565 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 566 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC 567 Conference on Computer and Communications Security , 2015. 569 Authors' Addresses 571 Richard Barnes 572 Mozilla 574 Email: rlb@ipv.sx 576 Subodh Iyengar 577 Facebook 579 Email: subodh@fb.com 581 Nick Sullivan 582 Cloudflare 584 Email: nick@cloudflare.com 586 Eric Rescorla 587 RTFM, Inc. 589 Email: ekr@rtfm.com