idnits 2.17.1 draft-ietf-tls-subcerts-02.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 349: '...this specification SHALL send an empty...' RFC 2119 keyword, line 352: '... client MUST abort with an "unexpect...' RFC 2119 keyword, line 354: '...esent, the server MAY send a delegated...' RFC 2119 keyword, line 355: '... not present, the server MUST NOT send...' RFC 2119 keyword, line 356: '...egated credential MUST NOT be provided...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 17, 2018) is 2077 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' == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-14 -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 Mozilla 4 Intended status: Standards Track S. Iyengar 5 Expires: February 18, 2019 Facebook 6 N. Sullivan 7 Cloudflare 8 E. Rescorla 9 RTFM, Inc. 10 August 17, 2018 12 Delegated Credentials for TLS 13 draft-ietf-tls-subcerts-02 15 Abstract 17 The organizational separation between the operator of a TLS server 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 clients 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 https://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 February 18, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 (https://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.2. Certificate Requirements . . . . . . . . . . . . . . . . 9 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 5.1. Security of delegated private key . . . . . . . . . . . . 10 71 5.2. Revocation of delegated credentials . . . . . . . . . . . 10 72 5.3. Privacy considerations . . . . . . . . . . . . . . . . . 10 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 7.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 Typically, a TLS server uses a certificate provided by some entity 82 other than the operator of the server (a "Certification Authority" or 83 CA) [RFC8446] [RFC5280]. This organizational separation makes the 84 TLS server operator dependent on the CA for some aspects of its 85 operations, for example: 87 o Whenever the server operator wants to deploy a new certificate, it 88 has to interact with the CA. 90 o The server operator can only use TLS authentication schemes for 91 which the CA will issue credentials. 93 These dependencies cause problems in practice. Server operators 94 often want to create short-lived certificates for servers in low- 95 trust zones such as CDNs or remote data centers. This allows server 96 operators to limit the exposure of keys in cases that they do not 97 realize a compromise has occurred. The risk inherent in cross- 98 organizational transactions makes it operationally infeasible to rely 99 on an external CA for such short-lived credentials. In OCSP stapling 100 (i.e., using the Certificate Status extension types ocsp [RFC6066] or 101 ocsp_multi [RFC6961]), if an operator chooses to talk frequently to 102 the CA to obtain stapled responses, then failure to fetch an OCSP 103 stapled response results only in degraded performance. On the other 104 hand, failure to fetch a potentially large number of short lived 105 certificates would result in the service not being available, which 106 creates greater operational risk. 108 To remove these dependencies, this document proposes a limited 109 delegation mechanism that allows a TLS server operator to issue its 110 own credentials within the scope of a certificate issued by an 111 external CA. Because the above problems do not relate to the CA's 112 inherent function of validating possession of names, it is safe to 113 make such delegations as long as they only enable the recipient of 114 the delegation to speak for names that the CA has authorized. For 115 clarity, we will refer to the certificate issued by the CA as a 116 "certificate", or "delegation certificate", and the one issued by the 117 operator as a "delegated credential". 119 1.1. Change Log 121 (*) indicates changes to the wire protocol. 123 draft-02 125 o Change public key type. (*) 127 o Change DelegationUsage extension to be NULL and define its object 128 identifier. 130 o Drop support for TLS 1.2. 132 o Add the protocol version and credential signature algorithm to the 133 Credential structure. (*) 135 o Specify undefined behavior in a few cases: when the client 136 receives a DC without indicated support; when the client indicates 137 the extension in an invalid protocol version; and when DCs are 138 sent as extensions to certificates other than the end-entity 139 certificate. 141 2. Solution Overview 143 A delegated credential is a digitally signed data structure with two 144 semantic fields: a validity interval and a public key (along with its 145 associated signature algorithm). The signature on the credential 146 indicates a delegation from the certificate that is issued to the TLS 147 server operator. The secret key used to sign a credential 148 corresponds to the public key of the TLS server's X.509 end-entity 149 certificate. 151 A TLS handshake that uses delegated credentials differs from a normal 152 handshake in a few important ways: 154 o The client provides an extension in its ClientHello that indicates 155 support for this mechanism. 157 o The server provides both the certificate chain terminating in its 158 certificate as well as the delegated credential. 160 o The client uses information in the server's certificate to verify 161 the delegated credential and that the server is asserting an 162 expected identity. 164 o The client uses the public key in the credential as the server's 165 working key for the TLS handshake. 167 As detailed in Section 3, the delegated credential is 168 cryptographically bound to the end-entity certificate and the 169 protocol in which the credential may be used. This document 170 specifies the use of delegated credentials in TLS 1.3 or later; their 171 use in prior versions of the protocol is explicitly disallowed. 173 Delegated credentials allow the server to terminate TLS connections 174 on behalf of the certificate owner. If a credential is stolen, there 175 is no mechanism for revoking it without revoking the certificate 176 itself. To limit exposure in case a delegated credential is 177 compromised, servers may not issue credentials with a validity period 178 longer than 7 days. This mechanism is described in detail in 179 Section 3.1. 181 It was noted in [XPROT] that certificates in use by servers that 182 support outdated protocols such as SSLv2 can be used to forge 183 signatures for certificates that contain the keyEncipherment KeyUsage 184 ([RFC5280] section 4.2.1.3). In order to prevent this type of cross- 185 protocol attack, we define a new DelegationUsage extension to X.509 186 that permits use of delegated credentials. (See Section 3.2.) 188 2.1. Rationale 190 Delegated credentials present a better alternative than other 191 delegation mechanisms like proxy certificates [RFC3820] for several 192 reasons: 194 o There is no change needed to certificate validation at the PKI 195 layer. 197 o X.509 semantics are very rich. This can cause unintended 198 consequences if a service owner creates a proxy certificate where 199 the properties differ from the leaf certificate. For this reason, 200 delegated credentials have very restricted semantics which should 201 not conflict with X.509 semantics. 203 o Proxy certificates rely on the certificate path building process 204 to establish a binding between the proxy certificate and the 205 server certificate. Since the certificate path building process 206 is not cryptographically protected, it is possible that a proxy 207 certificate could be bound to another certificate with the same 208 public key, with different X.509 parameters. Delegated 209 credentials, which rely on a cryptographic binding between the 210 entire certificate and the delegated credential, cannot. 212 o Each delegated credential is bound to a specific version of TLS 213 and signature algorithm. This prevents them from being used for 214 other protocols or with other signature algorithms than service 215 owner allows. 217 2.2. Related Work 219 Many of the use cases for delegated credentials can also be addressed 220 using purely server-side mechanisms that do not require changes to 221 client behavior (e.g., LURK [I-D.mglt-lurk-tls-requirements]). These 222 mechanisms, however, incur per-transaction latency, since the front- 223 end server has to interact with a back-end server that holds a 224 private key. The mechanism proposed in this document allows the 225 delegation to be done off-line, with no per-transaction latency. The 226 figure below compares the message flows for these two mechanisms with 227 TLS 1.3 [I-D.ietf-tls-tls13], where DC is delegated credentials. 229 LURK: 231 Client Front-End Back-End 232 |----ClientHello--->| | 233 |<---ServerHello----| | 234 |<---Certificate----| | 235 | |<-------LURK------->| 236 |<---CertVerify-----| | 237 | ... | | 239 Delegated credentials: 241 Client Front-End Back-End 242 | |<----DC minting---->| 243 |----ClientHello--->| | 244 |<---ServerHello----| | 245 |<---Certificate----| | 246 |<---CertVerify-----| | 247 | ... | | 249 These two mechanisms can be complementary. A server could use 250 credentials for clients that support them, while using LURK to 251 support legacy clients. 253 It is possible to address the short-lived certificate concerns above 254 by automating certificate issuance, e.g., with ACME 255 [I-D.ietf-acme-acme]. In addition to requiring frequent 256 operationally-critical interactions with an external party, this 257 makes the server operator dependent on the CA's willingness to issue 258 certificates with sufficiently short lifetimes. It also fails to 259 address the issues with algorithm support. Nonetheless, existing 260 automated issuance APIs like ACME may be useful for provisioning 261 credentials, within an operator network. 263 3. Delegated Credentials 265 While X.509 forbids end-entity certificates from being used as 266 issuers for other certificates, it is perfectly fine to use them to 267 issue other signed objects as long as the certificate contains the 268 digitalSignature KeyUsage (RFC5280 section 4.2.1.3). We define a new 269 signed object format that would encode only the semantics that are 270 needed for this application. The credential has the following 271 structure: 273 struct { 274 uint32 valid_time; 275 SignatureScheme expected_cert_verify_algorithm; 276 ProtocolVersion expected_version; 277 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 278 } Credential; 280 valid_time: Relative time in seconds from the beginning of the 281 delegation certificate's notBefore value after which the delegated 282 credential is no longer valid. 284 expected_cert_verify_algorithm: The signature algorithm of the 285 credential key pair, where the type SignatureScheme is as defined 286 in [RFC8446]. This is expected to be the same as 287 CertificateVerify.algorithm sent by the server. 289 expected_version: The version of TLS in which the credential will be 290 used, where the type ProtocolVersion is as defined in [RFC8446]. 291 This is expected to match the protocol version that is negotiated 292 by the client and server. 294 ASN1_subjectPublicKeyInfo: The credential's public key, a DER- 295 encoded [X690] SubjectPublicKeyInfo as defined in [RFC5280]. 297 The delegated credential has the following structure: 299 struct { 300 Credential cred; 301 SignatureScheme algorithm; 302 opaque signature<0..2^16-1>; 303 } DelegatedCredential; 305 algorithm: The signature algorithm used to verify 306 DelegatedCredential.signature. 308 signature: The signature over the credential with the end-entity 309 certificate's public key, using the scheme. 311 The signature of the DelegatedCredential is computed over the 312 concatenation of: 314 1. A string that consists of octet 32 (0x20) repeated 64 times. 316 2. The context string "TLS, server delegated credentials". 318 3. A single 0 byte, which serves as the separator. 320 4. The DER-encoded X.509 end-entity certificate used to sign the 321 DelegatedCredential. 323 5. DelegatedCredential.algorithm. 325 6. DelegatedCredential.scheme. 327 The signature effectively binds the credential to the parameters of 328 the handshake in which it is used. In particular, it ensures that 329 credentials are only used with the certificate, protocol, and 330 signature algorithm chosen by the delegator. Minimizing their 331 semantics in this way is intended to mitigate the risk of cross 332 protocol attacks involving delegated credentials. 334 The code changes to create and verify delegated credentials would be 335 localized to the TLS stack, which has the advantage of avoiding 336 changes to security-critical and often delicate PKI code (though of 337 course moves that complexity to the TLS stack). 339 3.1. Client and Server behavior 341 This document defines the following extension code point. 343 enum { 344 ... 345 delegated_credential(TBD), 346 (65535) 347 } ExtensionType; 349 A client which supports this specification SHALL send an empty 350 "delegated_credential" extension in its ClientHello. If the client 351 receives a delegated credential without indicating support, then the 352 client MUST abort with an "unexpected_message" alert. 354 If the extension is present, the server MAY send a delegated 355 credential; if the extension is not present, the server MUST NOT send 356 a delegated credential. A delegated credential MUST NOT be provided 357 unless a Certificate message is also sent. The server MUST ignore 358 the extension unless TLS 1.3 or a later version is negotiated. 360 The server MUST send the delegated credential as an extension in the 361 CertificateEntry of its end-entity certificate; the client SHOULD 362 ignore delegated credentials sent as extensions to any other 363 certificate. 365 The algorithm and expected_cert_verify_algorithm fields MUST be of a 366 type advertised by the client in the "signature_algorithms" 367 extension. A delegated credential MUST NOT be negotiated otherwise, 368 even if the client advertises support for delegated credentials. 370 On receiving a delegated credential and a certificate chain, the 371 client validates the certificate chain and matches the end-entity 372 certificate to the server's expected identity following its normal 373 procedures. It also takes the following steps: 375 1. Verify that the current time is within the validity interval of 376 the credential and that the credential's time to live is no more 377 than 7 days. 379 2. Verify that expected_cert_verify_algorithm matches the scheme 380 indicated in the server's CertificateVerify message. 382 3. Verify that expected_version matches the protocol version 383 indicated in the server's "supported_versions" extension. 385 4. Verify that the end-entity certificate satisfies the conditions 386 specified in Section 3.2. 388 5. Use the public key in the server's end-entity certificate to 389 verify the signature of the credential using the algorithm 390 indicated by DelegatedCredential.algorithm. 392 If one or more of these checks fail, then the delegated credential is 393 deemed invalid. Clients that receive invalid delegated credentials 394 MUST terminate the connection with an "illegal_parameter" alert. If 395 successful, the client uses the public key in the credential to 396 verify the signature in the server's CertificateVerify message. 398 3.2. Certificate Requirements 400 We define a new X.509 extension, DelegationUsage, to be used in the 401 certificate when the certificate permits the usage of delegated 402 credentials. 404 id-ce-delegationUsage OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.44363.44 } 405 DelegationUsage ::= NULL 407 The extension MUST be marked non-critical. (See Section 4.2 of 408 [RFC5280].) The client MUST NOT accept a delegated credential unless 409 the server's end-entity certificate satisfies the following criteria: 411 o It has the DelegationUsage extension. 413 o It has the digitalSignature KeyUsage (see the KeyUsage extension 414 defined in [RFC5280]). 416 4. IANA Considerations 418 TBD 420 5. Security Considerations 422 5.1. Security of delegated private key 424 Delegated credentials limit the exposure of the TLS private key by 425 limiting its validity. An attacker who compromises the private key 426 of a delegated credential can act as a man in the middle until the 427 delegate credential expires, however they cannot create new delegated 428 credentials. Thus delegated credentials should not be used to send a 429 delegation to an untrusted party, but is meant to be used between 430 parties that have some trust relationship with each other. The 431 secrecy of the delegated private key is thus important and several 432 access control mechanisms SHOULD be used to protect it such as file 433 system controls, physical security or hardware security modules. 435 5.2. Revocation of delegated credentials 437 Delegated credentials do not provide any additional form of early 438 revocation. Since it is short lived, the expiry of the delegated 439 credential would revoke the credential. Revocation of the long term 440 private key that signs the delegated credential also implicitly 441 revokes the delegated credential. 443 5.3. Privacy considerations 445 Delegated credentials can be valid for 7 days and it is much easier 446 for a service to create delegated credential than a certificate 447 signed by a CA. A service could determine the client time and clock 448 skew by creating several delegated credentials with different expiry 449 timestamps and observing whether the client would accept it. Client 450 time could be unique and thus privacy sensitive clients, such as 451 browsers in incognito mode, who do not trust the service might not 452 want to advertise support for delegated credentials or limit the 453 number of probes that a server can perform. 455 6. Acknowledgements 457 Thanks to Christopher Patton, Kyle Nekritz, Anirudh Ramachandran, 458 Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor for their 459 discussions, ideas, and bugs they have found. 461 7. References 463 7.1. Normative References 465 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 466 Housley, R., and W. Polk, "Internet X.509 Public Key 467 Infrastructure Certificate and Certificate Revocation List 468 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 469 . 471 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 472 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 473 . 475 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 476 Specification of Basic Encoding Rules (BER), Canonical 477 Encoding Rules (CER) and Distinguished Encoding Rules 478 (DER)", ISO/IEC 8825-1:2002, 2002. 480 7.2. Informative References 482 [I-D.ietf-acme-acme] 483 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 484 Kasten, "Automatic Certificate Management Environment 485 (ACME)", draft-ietf-acme-acme-14 (work in progress), 486 August 2018. 488 [I-D.ietf-tls-tls13] 489 Rescorla, E., "The Transport Layer Security (TLS) Protocol 490 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 491 March 2018. 493 [I-D.mglt-lurk-tls-requirements] 494 Migault, D. and K. Ma, "Authentication Model and Security 495 Requirements for the TLS/DTLS Content Provider Edge Server 496 Split Use Case", draft-mglt-lurk-tls-requirements-00 (work 497 in progress), January 2016. 499 [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. 500 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 501 Proxy Certificate Profile", RFC 3820, 502 DOI 10.17487/RFC3820, June 2004, 503 . 505 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 506 Extensions: Extension Definitions", RFC 6066, 507 DOI 10.17487/RFC6066, January 2011, 508 . 510 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 511 Multiple Certificate Status Request Extension", RFC 6961, 512 DOI 10.17487/RFC6961, June 2013, 513 . 515 [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the 516 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 517 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC 518 Conference on Computer and Communications Security , 2015. 520 Authors' Addresses 522 Richard Barnes 523 Mozilla 525 Email: rlb@ipv.sx 527 Subodh Iyengar 528 Facebook 530 Email: subodh@fb.com 532 Nick Sullivan 533 Cloudflare 535 Email: nick@cloudflare.com 537 Eric Rescorla 538 RTFM, Inc. 540 Email: ekr@rtfm.com