idnits 2.17.1 draft-ietf-tls-subcerts-01.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 156: '... credentials. Clients MUST NOT accept...' RFC 2119 keyword, line 164: '... MUST NOT issue credentials with a v...' RFC 2119 keyword, line 165: '... Clients MUST NOT accept credentials...' RFC 2119 keyword, line 251: '...orts this document SHALL send an empty...' RFC 2119 keyword, line 254: '...sion is present, the server MAY send a...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: We define a new X.509 extension, DelegationUsage to be used in the certificate when the certificate permits the usage of delegated credentials. When this extension is not present the client MUST not accept a delegated credential even if it is negotiated by the server. When it is present, the client MUST follow the validation procedure. -- The document date (July 02, 2018) is 2124 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 normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-12 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: January 3, 2019 Facebook 6 N. Sullivan 7 Cloudflare 8 E. Rescorla 9 RTFM, Inc. 10 July 02, 2018 12 Delegated Credentials for TLS 13 draft-ietf-tls-subcerts-01 15 Abstract 17 The organizational separation between the operator of a TLS server 18 and the certificate authority that provides it credentials can cause 19 problems, for example when it comes to reducing the lifetime of 20 certificates or supporting new cryptographic algorithms. This 21 document describes a mechanism to allow TLS server operators to 22 create their own credential delegations without breaking 23 compatibility with clients that do not support this specification. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 3, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Client and Server behavior . . . . . . . . . . . . . . . . . 6 64 4. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Certificate Requirements . . . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 6.1. Security of delegated private key . . . . . . . . . . . . 9 69 6.2. Revocation of delegated credentials . . . . . . . . . . . 9 70 6.3. Privacy considerations . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Typically, a TLS server uses a certificate provided by some entity 80 other than the operator of the server (a "Certification Authority" or 81 CA) [RFC5246] [RFC5280]. This organizational separation makes the 82 TLS server operator dependent on the CA for some aspects of its 83 operations, for example: 85 o Whenever the server operator wants to deploy a new certificate, it 86 has to interact with the CA. 88 o The server operator can only use TLS authentication schemes for 89 which the CA will issue credentials. 91 These dependencies cause problems in practice. Server operators 92 often want to create short-lived certificates for servers in low- 93 trust zones such as CDNs or remote data centers. This allows server 94 operators to limit the exposure of keys in cases that they do not 95 realize a compromise has occurred. The risk inherent in cross- 96 organizational transactions makes it operationally infeasible to rely 97 on an external CA for such short-lived credentials. In OCSP 98 stapling, if an operator chooses to talk frequently to the CA to 99 obtain stapled responses, then failure to fetch an OCSP stapled 100 response results only in degraded performance. On the other hand, 101 failure to fetch a potentially large number of short lived 102 certificates would result in the service not being available which 103 creates greater operational risk. 105 To remove these dependencies, this document proposes a limited 106 delegation mechanism that allows a TLS server operator to issue its 107 own credentials within the scope of a certificate issued by an 108 external CA. Because the above problems do not relate to the CAs 109 inherent function of validating possession of names, it is safe to 110 make such delegations as long as they only enable the recipient of 111 the delegation to speak for names that the CA has authorized. For 112 clarity, we will refer to the certificate issued by the CA as a 113 "certificate" and the one issued by the operator as a "delegated 114 credential". 116 2. Solution Overview 118 A delegated credential is a digitally signed data structure with the 119 following semantic fields: 121 o A validity interval 123 o A public key (with its associated algorithm) 125 The signature on the credential indicates a delegation from the 126 certificate that is issued to the TLS server operator. The secret 127 key used to sign a credential is presumed to be one whose 128 corresponding public key is contained in an X.509 certificate that 129 associates one or more names to the credential. 131 A TLS handshake that uses credentials differs from a normal handshake 132 in a few important ways: 134 o The client provides an extension in its ClientHello that indicates 135 support for this mechanism. 137 o The server provides both the certificate chain terminating in its 138 certificate as well as the credential. 140 o The client uses information in the server's certificate to verify 141 the signature on the credential and verify that the server is 142 asserting an expected identity. 144 o The client uses the public key in the credential as the server's 145 working key for the TLS handshake. 147 Delegated credentials can be used either in TLS 1.3 or TLS 1.2. 148 Differences between the use of delegated credentials in the protocols 149 are explicitly stated. 151 It was noted in [XPROT] that certificates in use by servers that 152 support outdated protocols such as SSLv2 can be used to forge 153 signatures for certificates that contain the keyEncipherment KeyUsage 154 ([RFC5280] section 4.2.1.3) In order to prevent this type of cross- 155 protocol attack, we define a new DelegationUsage extension to X.509 156 that permits use of delegated credentials. Clients MUST NOT accept 157 delegated credentials associated with certificates without this 158 extension. 160 Credentials allow the server to terminate TLS connections on behalf 161 of the certificate owner. If a credential is stolen, there is no 162 mechanism for revoking it without revoking the certificate itself. 163 To limit the exposure of a delegation credential compromise, servers 164 MUST NOT issue credentials with a validity period longer than 7 days. 165 Clients MUST NOT accept credentials with longer validity periods. 167 2.1. Rationale 169 Delegated credentials present a better alternative than other 170 delegation mechanisms like proxy certificates [RFC3820] for several 171 reasons: 173 o There is no change needed to certificate validation at the PKI 174 layer. 176 o X.509 semantics are very rich. This can cause unintended 177 consequences if a service owner creates a proxy cert where the 178 properties differ from the leaf certificate. 180 o Delegated credentials have very restricted semantics which should 181 not conflict with X.509 semantics. 183 o Proxy certificates rely on the certificate path building process 184 to establish a binding between the proxy certificate and the 185 server certificate. Since the cert path building process is not 186 cryptographically protected, it is possible that a proxy 187 certificate could be bound to another certificate with the same 188 public key, with different X.509 parameters. Delegated 189 credentials, which rely on a cryptographic binding between the 190 entire certificate and the delegated credential, cannot. 192 o Delegated credentials are bound to specific versions of TLS. This 193 prevents them from being used for other protocols if a service 194 owner allows multiple versions of TLS. 196 2.2. Related Work 198 Many of the use cases for delegated credentials can also be addressed 199 using purely server-side mechanisms that do not require changes to 200 client behavior (e.g., LURK [I-D.mglt-lurk-tls-requirements]). These 201 mechanisms, however, incur per-transaction latency, since the front- 202 end server has to interact with a back-end server that holds a 203 private key. The mechanism proposed in this document allows the 204 delegation to be done off-line, with no per-transaction latency. The 205 figure below compares the message flows for these two mechanisms with 206 TLS 1.3 [I-D.ietf-tls-tls13]. 208 LURK: 210 Client Front-End Back-End 211 |----ClientHello--->| | 212 |<---ServerHello----| | 213 |<---Certificate----| | 214 | |<-------LURK------->| 215 |<---CertVerify-----| | 216 | ... | | 218 Delegated credentials: 220 Client Front-End Back-End 221 | |<--Cred Provision-->| 222 |----ClientHello--->| | 223 |<---ServerHello----| | 224 |<---Certificate----| | 225 |<---CertVerify-----| | 227 These two mechanisms can be complementary. A server could use 228 credentials for clients that support them, while using LURK to 229 support legacy clients. 231 It is possible to address the short-lived certificate concerns above 232 by automating certificate issuance, e.g., with ACME 233 [I-D.ietf-acme-acme]. In addition to requiring frequent 234 operationally-critical interactions with an external party, this 235 makes the server operator dependent on the CA's willingness to issue 236 certificates with sufficiently short lifetimes. It also fails to 237 address the issues with algorithm support. Nonetheless, existing 238 automated issuance APIs like ACME may be useful for provisioning 239 credentials, within an operator network. 241 3. Client and Server behavior 243 This document defines the following extension code point. 245 enum { 246 ... 247 delegated_credential(TBD), 248 (65535) 249 } ExtensionType; 251 A client which supports this document SHALL send an empty 252 "delegated_credential" extension in its ClientHello. 254 If the extension is present, the server MAY send a 255 DelegatedCredential extension. If the extension is not present, the 256 server MUST NOT send a credential. A credential MUST NOT be provided 257 unless a Certificate message is also sent. 259 When negotiating TLS 1.3, and using Delegated credentials, the server 260 MUST send the DelegatedCredential as an extension in the 261 CertificateEntry of its end-entity certificate. When negotiating TLS 262 1.2, the DelegatedCredential MUST be sent as an extension in the 263 ServerHello. 265 The DelegatedCredential contains a signature from the public key in 266 the end-entity certificate using a signature algorithm advertised by 267 the client in the "signature_algorithms" extension. Additionally, 268 the credential's public key MUST be of a type that enables at least 269 one of the supported signature algorithms. A delegated credential 270 MUST NOT be negotiated by the server if its signature is not 271 compatible with any of the supported signature algorithms or the 272 credential's public key is not usable with the supported signature 273 algorithms of the client, even if the client advertises support for 274 delegated credentials. 276 On receiving a credential and a certificate chain, the client 277 validates the certificate chain and matches the end-entity 278 certificate to the server's expected identity following its normal 279 procedures. It then takes the following steps: 281 o Verify that the current time is within the validity interval of 282 the credential and that the credential's time to live is no more 283 than 7 days. 285 o Verify that the certificate has the DelegationUsage extension, 286 which permits the use of Delegated credentials. 288 o Use the public key in the server's end-entity certificate to 289 verify the signature on the credential. 291 If one or more of these checks fail, then the delegated credential is 292 deemed invalid. Clients that receive invalid delegated credentials 293 MUST terminate the connection with an "illegal_parameter" alert. If 294 successful, the client uses the public key in the credential to 295 verify a signature provided in the handshake: in particular, the 296 CertificateVerify message in TLS 1.3 and the ServerKeyExchange in 297 1.2. 299 4. Delegated Credentials 301 While X.509 forbids end-entity certificates from being used as 302 issuers for other certificates, it is perfectly fine to use them to 303 issue other signed objects as long as the certificate contains the 304 digitalSignature key usage (RFC5280 section 4.2.1.3). We define a 305 new signed object format that would encode only the semantics that 306 are needed for this application. 308 struct { 309 uint32 valid_time; 310 opaque public_key<0..2^16-1>; 311 } Credential; 313 struct { 314 Credential cred; 315 SignatureScheme scheme; 316 opaque signature<0..2^16-1>; 317 } DelegatedCredential; 319 valid_time: Relative time in seconds from the beginning of the 320 certificate's notBefore value after which the delegated credential 321 is no longer valid. 323 public_key: The delegated credential's public key, which is an 324 encoded SubjectPublicKeyInfo [RFC5280]. 326 scheme: The signature algorithm used to sign the delegated 327 credential. 329 signature: The signature over the credential with the end-entity 330 certificate's public key, using the scheme. 332 The DelegatedCredential structure is similar to the CertificateVerify 333 structure in TLS 1.3. Since the SignatureScheme is defined in TLS 334 1.3, TLS 1.2 clients should translate the scheme into an appropriate 335 group and signature algorithm to perform validation. 337 The signature of the DelegatedCredential is computed over the 338 concatenation of: 340 1. A string that consists of octet 32 (0x20) repeated 64 times. 342 2. The context string "TLS, server delegated credentials". 344 3. A single 0 byte which serves as the separator. 346 4. Big endian serialized 2 bytes ProtocolVersion of the negotiated 347 TLS version, defined by TLS. 349 5. DER encoded X.509 certificate used to sign the 350 DelegatedCredential. 352 6. Big endian serialized 2 byte SignatureScheme scheme. 354 7. The Credential structure. 356 This signature has a few desirable properties: 358 o It is bound to the certificate that signed it. 360 o It is bound to the protocol version that is negotiated. This is 361 intended to avoid cross-protocol attacks with signing oracles. 363 The code changes to create and verify delegated credentials would be 364 localized to the TLS stack, which has the advantage of avoiding 365 changes to security-critical and often delicate PKI code (though of 366 course moves that complexity to the TLS stack). 368 4.1. Certificate Requirements 370 We define a new X.509 extension, DelegationUsage to be used in the 371 certificate when the certificate permits the usage of delegated 372 credentials. When this extension is not present the client MUST not 373 accept a delegated credential even if it is negotiated by the server. 374 When it is present, the client MUST follow the validation procedure. 376 id-ce-delegationUsage OBJECT IDENTIFIER ::= { TBD } 378 DelegationUsage ::= BIT STRING { allowed (0) } 379 Conforming CAs MUST mark this extension as non-critical. This allows 380 the certificate to be used by service owners for clients that do not 381 support certificate delegation as well and not need to obtain two 382 certificates. 384 5. IANA Considerations 386 TBD 388 6. Security Considerations 390 6.1. Security of delegated private key 392 Delegated credentials limit the exposure of the TLS private key by 393 limiting its validity. An attacker who compromises the private key 394 of a delegated credential can act as a man in the middle until the 395 delegate credential expires, however they cannot create new delegated 396 credentials. Thus delegated credentials should not be used to send a 397 delegation to an untrusted party, but is meant to be used between 398 parties that have some trust relationship with each other. The 399 secrecy of the delegated private key is thus important and several 400 access control mechanisms SHOULD be used to protect it such as file 401 system controls, physical security or hardware security modules. 403 6.2. Revocation of delegated credentials 405 Delegated credentials do not provide any additional form of early 406 revocation. Since it is short lived, the expiry of the delegated 407 credential would revoke the credential. Revocation of the long term 408 private key that signs the delegated credential also implictly 409 revokes the delegated credential. 411 6.3. Privacy considerations 413 Delegated credentials can be valid for 7 days and it is much easier 414 for a service to create delegated credential than a certificate 415 signed by a CA. A service could determine the client time and clock 416 skew by creating several delegated credentials with different expiry 417 timestamps and observing whether the client would accept it. Client 418 time could be unique and thus privacy sensitive clients, such as 419 browsers in incognito mode, who do not trust the service might not 420 want to advertise support for delegated credentials or limit the 421 number of probes that a server can perform. 423 7. Acknowledgements 425 Thanks to Kyle Nekritz, Anirudh Ramachandran, Benjamin Kaduk, Kazuho 426 Oku, Daniel Kahn Gillmor for their discussions, ideas, and bugs 427 they've found. 429 8. References 431 8.1. Normative References 433 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 434 (TLS) Protocol Version 1.2", RFC 5246, 435 DOI 10.17487/RFC5246, August 2008, . 438 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 439 Housley, R., and W. Polk, "Internet X.509 Public Key 440 Infrastructure Certificate and Certificate Revocation List 441 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 442 . 444 8.2. Informative References 446 [I-D.ietf-acme-acme] 447 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 448 Kasten, "Automatic Certificate Management Environment 449 (ACME)", draft-ietf-acme-acme-12 (work in progress), April 450 2018. 452 [I-D.ietf-tls-tls13] 453 Rescorla, E., "The Transport Layer Security (TLS) Protocol 454 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 455 March 2018. 457 [I-D.mglt-lurk-tls-requirements] 458 Migault, D. and K. Ma, "Authentication Model and Security 459 Requirements for the TLS/DTLS Content Provider Edge Server 460 Split Use Case", draft-mglt-lurk-tls-requirements-00 (work 461 in progress), January 2016. 463 [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. 464 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 465 Proxy Certificate Profile", RFC 3820, 466 DOI 10.17487/RFC3820, June 2004, . 469 [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the 470 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 471 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC 472 Conference on Computer and Communications Security , 2015. 474 Authors' Addresses 476 Richard Barnes 477 Mozilla 479 Email: rlb@ipv.sx 481 Subodh Iyengar 482 Facebook 484 Email: subodh@fb.com 486 Nick Sullivan 487 Cloudflare 489 Email: nick@cloudflare.com 491 Eric Rescorla 492 RTFM, Inc. 494 Email: ekr@rtfm.com