< draft-ietf-tls-subcerts-03.txt   draft-ietf-tls-subcerts-04.txt >
Network Working Group R. Barnes Network Working Group R. Barnes
Internet-Draft Mozilla Internet-Draft Cisco
Intended status: Standards Track S. Iyengar Intended status: Standards Track S. Iyengar
Expires: August 23, 2019 Facebook Expires: January 9, 2020 Facebook
N. Sullivan N. Sullivan
Cloudflare Cloudflare
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
February 19, 2019 July 08, 2019
Delegated Credentials for TLS Delegated Credentials for TLS
draft-ietf-tls-subcerts-03 draft-ietf-tls-subcerts-04
Abstract Abstract
The organizational separation between the operator of a TLS server The organizational separation between the operator of a TLS endpoint
and the certification authority can create limitations. For example, and the certification authority can create limitations. For example,
the lifetime of certificates, how they may be used, and the the lifetime of certificates, how they may be used, and the
algorithms they support are ultimately determined by the algorithms they support are ultimately determined by the
certification authority. This document describes a mechanism by certification authority. This document describes a mechanism by
which operators may delegate their own credentials for use in TLS, which operators may delegate their own credentials for use in TLS,
without breaking compatibility with clients that do not support this without breaking compatibility with peers that do not support this
specification. specification.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5
3. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 6 3. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 6
3.1. Client and Server behavior . . . . . . . . . . . . . . . 8 3.1. Client and Server behavior . . . . . . . . . . . . . . . 8
3.2. Certificate Requirements . . . . . . . . . . . . . . . . 9 3.1.1. Server authentication . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Client authentication . . . . . . . . . . . . . . . . 9
3.1.3. Validating a Delegated Credential . . . . . . . . . . 9
3.2. Certificate Requirements . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Security of delegated private key . . . . . . . . . . . . 10 5.1. Security of delegated private key . . . . . . . . . . . . 10
5.2. Revocation of delegated credentials . . . . . . . . . . . 10 5.2. Re-use of delegated credentials in multiple contexts . . 11
5.3. Privacy considerations . . . . . . . . . . . . . . . . . 10 5.3. Revocation of delegated credentials . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Privacy considerations . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Typically, a TLS server uses a certificate provided by some entity Typically, a TLS server uses a certificate provided by some entity
other than the operator of the server (a "Certification Authority" or other than the operator of the server (a "Certification Authority" or
CA) [RFC8446] [RFC5280]. This organizational separation makes the CA) [RFC8446] [RFC5280]. This organizational separation makes the
TLS server operator dependent on the CA for some aspects of its TLS server operator dependent on the CA for some aspects of its
operations, for example: operations, for example:
o Whenever the server operator wants to deploy a new certificate, it o Whenever the server operator wants to deploy a new certificate, it
skipping to change at page 3, line 17 skipping to change at page 3, line 21
on an external CA for such short-lived credentials. In OCSP stapling on an external CA for such short-lived credentials. In OCSP stapling
(i.e., using the Certificate Status extension types ocsp [RFC6066] or (i.e., using the Certificate Status extension types ocsp [RFC6066] or
ocsp_multi [RFC6961]), if an operator chooses to talk frequently to ocsp_multi [RFC6961]), if an operator chooses to talk frequently to
the CA to obtain stapled responses, then failure to fetch an OCSP the CA to obtain stapled responses, then failure to fetch an OCSP
stapled response results only in degraded performance. On the other stapled response results only in degraded performance. On the other
hand, failure to fetch a potentially large number of short lived hand, failure to fetch a potentially large number of short lived
certificates would result in the service not being available, which certificates would result in the service not being available, which
creates greater operational risk. creates greater operational risk.
To remove these dependencies, this document proposes a limited To remove these dependencies, this document proposes a limited
delegation mechanism that allows a TLS server operator to issue its delegation mechanism that allows a TLS peer to issue its own
own credentials within the scope of a certificate issued by an credentials within the scope of a certificate issued by an external
external CA. Because the above problems do not relate to the CA's CA. Because the above problems do not relate to the CA's inherent
inherent function of validating possession of names, it is safe to function of validating possession of names, it is safe to make such
make such delegations as long as they only enable the recipient of delegations as long as they only enable the recipient of the
the delegation to speak for names that the CA has authorized. For delegation to speak for names that the CA has authorized. For
clarity, we will refer to the certificate issued by the CA as a clarity, we will refer to the certificate issued by the CA as a
"certificate", or "delegation certificate", and the one issued by the "certificate", or "delegation certificate", and the one issued by the
operator as a "delegated credential" or "DC". operator as a "delegated credential" or "DC".
1.1. Change Log 1.1. Change Log
(*) indicates changes to the wire protocol. (*) indicates changes to the wire protocol.
draft-04
o Add support for client certificates.
draft-03 draft-03
o Remove protocol version from the Credential structure. (*) o Remove protocol version from the Credential structure. (*)
draft-02 draft-02
o Change public key type. (*) o Change public key type. (*)
o Change DelegationUsage extension to be NULL and define its object o Change DelegationUsage extension to be NULL and define its object
identifier. identifier.
skipping to change at page 4, line 10 skipping to change at page 4, line 19
receives a DC without indicated support; when the client indicates receives a DC without indicated support; when the client indicates
the extension in an invalid protocol version; and when DCs are the extension in an invalid protocol version; and when DCs are
sent as extensions to certificates other than the end-entity sent as extensions to certificates other than the end-entity
certificate. certificate.
2. Solution Overview 2. Solution Overview
A delegated credential is a digitally signed data structure with two A delegated credential is a digitally signed data structure with two
semantic fields: a validity interval and a public key (along with its semantic fields: a validity interval and a public key (along with its
associated signature algorithm). The signature on the credential associated signature algorithm). The signature on the credential
indicates a delegation from the certificate that is issued to the TLS indicates a delegation from the certificate that is issued to the
server operator. The secret key used to sign a credential peer. The secret key used to sign a credential corresponds to the
corresponds to the public key of the TLS server's X.509 end-entity public key of the peer's X.509 end-entity certificate.
certificate.
A TLS handshake that uses delegated credentials differs from a normal A TLS handshake that uses delegated credentials differs from a normal
handshake in a few important ways: handshake in a few important ways:
o The client provides an extension in its ClientHello that indicates o The initiating peer provides an extension in its ClientHello or
support for this mechanism. CertificateRequest that indicates support for this mechanism.
o The server provides both the certificate chain terminating in its o The peer sending the Certificate message provides both the
certificate as well as the delegated credential. certificate chain terminating in its certificate as well as the
delegated credential.
o The client uses information in the server's certificate to verify o The authenticating intitiator uses information from the peer's
the delegated credential and that the server is asserting an certificate to verify the delegated credential and that the peer
expected identity. is asserting an expected identity.
o The client uses the public key in the credential as the server's o Peers accepting the delegated credential use it as the
working key for the TLS handshake. certificate's working key for the TLS hadshake
As detailed in Section 3, the delegated credential is As detailed in Section 3, the delegated credential is
cryptographically bound to the end-entity certificate with which the cryptographically bound to the end-entity certificate with which the
credential may be used. This document specifies the use of delegated credential may be used. This document specifies the use of delegated
credentials in TLS 1.3 or later; their use in prior versions of the credentials in TLS 1.3 or later; their use in prior versions of the
protocol is not allowed. protocol is not allowed.
Delegated credentials allow the server to terminate TLS connections Delegated credentials allow a peer to terminate TLS connections on
on behalf of the certificate owner. If a credential is stolen, there behalf of the certificate owner. If a credential is stolen, there is
is no mechanism for revoking it without revoking the certificate no mechanism for revoking it without revoking the certificate itself.
itself. To limit exposure in case a delegated credential is To limit exposure in case a delegated credential is compromised,
compromised, servers may not issue credentials with a validity period peers may not issue credentials with a validity period longer than 7
longer than 7 days. This mechanism is described in detail in days. This mechanism is described in detail in Section 3.1.
Section 3.1.
It was noted in [XPROT] that certificates in use by servers that It was noted in [XPROT] that certificates in use by servers that
support outdated protocols such as SSLv2 can be used to forge support outdated protocols such as SSLv2 can be used to forge
signatures for certificates that contain the keyEncipherment KeyUsage signatures for certificates that contain the keyEncipherment KeyUsage
([RFC5280] section 4.2.1.3). In order to prevent this type of cross- ([RFC5280] section 4.2.1.3). In order to prevent this type of cross-
protocol attack, we define a new DelegationUsage extension to X.509 protocol attack, we define a new DelegationUsage extension to X.509
that permits use of delegated credentials. (See Section 3.2.) that permits use of delegated credentials. (See Section 3.2.)
2.1. Rationale 2.1. Rationale
skipping to change at page 7, line 43 skipping to change at page 7, line 43
signature: The delegation, a signature that binds the credential to signature: The delegation, a signature that binds the credential to
the end-entity certificate's public key as specified below. The the end-entity certificate's public key as specified below. The
signature scheme is specified by DelegatedCredential.algorithm. signature scheme is specified by DelegatedCredential.algorithm.
The signature of the DelegatedCredential is computed over the The signature of the DelegatedCredential is computed over the
concatenation of: concatenation of:
1. A string that consists of octet 32 (0x20) repeated 64 times. 1. A string that consists of octet 32 (0x20) repeated 64 times.
2. The context string "TLS, server delegated credentials". 2. The context string "TLS, server delegated credentials" for
servers and "TLS, client delegated credentials" for clients.
3. A single 0 byte, which serves as the separator. 3. A single 0 byte, which serves as the separator.
4. The DER-encoded X.509 end-entity certificate used to sign the 4. The DER-encoded X.509 end-entity certificate used to sign the
DelegatedCredential. DelegatedCredential.
5. DelegatedCredential.cred. 5. DelegatedCredential.cred.
6. DelegatedCredential.algorithm. 6. DelegatedCredential.algorithm.
skipping to change at page 8, line 27 skipping to change at page 8, line 29
3.1. Client and Server behavior 3.1. Client and Server behavior
This document defines the following extension code point. This document defines the following extension code point.
enum { enum {
... ...
delegated_credential(TBD), delegated_credential(TBD),
(65535) (65535)
} ExtensionType; } ExtensionType;
3.1.1. Server authentication
A client which supports this specification SHALL send an empty A client which supports this specification SHALL send an empty
"delegated_credential" extension in its ClientHello. If the client "delegated_credential" extension in its ClientHello. If the client
receives a delegated credential without indicating support, then the receives a delegated credential without indicating support, then the
client MUST abort with an "unexpected_message" alert. client MUST abort with an "unexpected_message" alert.
If the extension is present, the server MAY send a delegated If the extension is present, the server MAY send a delegated
credential; if the extension is not present, the server MUST NOT send credential; if the extension is not present, the server MUST NOT send
a delegated credential. A delegated credential MUST NOT be provided a delegated credential. The server MUST ignore the extension unless
unless a Certificate message is also sent. The server MUST ignore TLS 1.3 or a later version is negotiated.
the extension unless TLS 1.3 or a later version is negotiated.
The server MUST send the delegated credential as an extension in the The server MUST send the delegated credential as an extension in the
CertificateEntry of its end-entity certificate; the client SHOULD CertificateEntry of its end-entity certificate; the client SHOULD
ignore delegated credentials sent as extensions to any other ignore delegated credentials sent as extensions to any other
certificate. certificate.
The algorithm and expected_cert_verify_algorithm fields MUST be of a The algorithm and expected_cert_verify_algorithm fields MUST be of a
type advertised by the client in the "signature_algorithms" type advertised by the client in the "signature_algorithms" extension
extension. A delegated credential MUST NOT be negotiated otherwise, and are considered invalid otherwise. Clients that receive invalid
even if the client advertises support for delegated credentials. delegated credentials MUST terminate the connection with an
"illegal_parameter" alert.
On receiving a delegated credential and a certificate chain, the 3.1.2. Client authentication
client validates the certificate chain and matches the end-entity
certificate to the server's expected identity in the usual way. It A server which supports this specification SHALL send an empty
"delegated_credential" extension in the CertificateRequest message
when requesting client authentication. If the server receives a
delegated credential without indicating support in its
CertificateRequest, then the server MUST abort with an
"unexpected_message" alert.
If the extension is present, the client MAY send a delegated
credential; if the extension is not present, the client MUST NOT send
a delegated credential. The client MUST ignore the extension unless
TLS 1.3 or a later version is negotiated.
The client MUST send the delegated credential as an extension in the
CertificateEntry of its end-entity certificate; the server SHOULD
ignore delegated credentials sent as extensions to any other
certificate.
The algorithm and expected_cert_verify_algorithm fields MUST be of a
type advertised by the server in the "signature_algorithms" extension
and are considered invalid otherwise. Servers that receive invalid
delegated credentials MUST terminate the connection with an
"illegal_parameter" alert.
3.1.3. Validating a Delegated Credential
On receiving a delegated credential and a certificate chain, the peer
validates the certificate chain and matches the end-entity
certificate to the peer's expected identity in the usual way. It
also takes the following steps: also takes the following steps:
1. Verify that the current time is within the validity interval of 1. Verify that the current time is within the validity interval of
the credential and that the credential's time to live is no more the credential and that the credential's time to live is no more
than 7 days. This is done by asserting that the current time is than 7 days. This is done by asserting that the current time is
no more than the delegation certificate's notBefore value plus no more than the delegation certificate's notBefore value plus
DelegatedCredential.cred.valid_time. DelegatedCredential.cred.valid_time.
2. Verify that expected_cert_verify_algorithm matches the scheme 2. Verify that expected_cert_verify_algorithm matches the scheme
indicated in the server's CertificateVerify message. indicated in the peer's CertificateVerify message.
3. Verify that the end-entity certificate satisfies the conditions 3. Verify that the end-entity certificate satisfies the conditions
in Section 3.2. in Section 3.2.
4. Use the public key in the server's end-entity certificate to 4. Use the public key in the peer's end-entity certificate to verify
verify the signature of the credential using the algorithm the signature of the credential using the algorithm indicated by
indicated by DelegatedCredential.algorithm. DelegatedCredential.algorithm.
If one or more of these checks fail, then the delegated credential is If one or more of these checks fail, then the delegated credential is
deemed invalid. Clients that receive invalid delegated credentials deemed invalid. Clients and servers that receive invalid delegated
MUST terminate the connection with an "illegal_parameter" alert. If credentials MUST terminate the connection with an "illegal_parameter"
successful, the client uses the public key in the credential to alert. If successful, the participant receiving the Certificate
verify the signature in the server's CertificateVerify message. message uses the public key in the credential to verify the signature
in the peer's CertificateVerify message.
3.2. Certificate Requirements 3.2. Certificate Requirements
We define a new X.509 extension, DelegationUsage, to be used in the We define a new X.509 extension, DelegationUsage, to be used in the
certificate when the certificate permits the usage of delegated certificate when the certificate permits the usage of delegated
credentials. credentials.
id-ce-delegationUsage OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.44363.44 } id-ce-delegationUsage OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.44363.44 }
DelegationUsage ::= NULL DelegationUsage ::= NULL
skipping to change at page 9, line 47 skipping to change at page 10, line 32
[RFC5280].) The client MUST NOT accept a delegated credential unless [RFC5280].) The client MUST NOT accept a delegated credential unless
the server's end-entity certificate satisfies the following criteria: the server's end-entity certificate satisfies the following criteria:
o It has the DelegationUsage extension. o It has the DelegationUsage extension.
o It has the digitalSignature KeyUsage (see the KeyUsage extension o It has the digitalSignature KeyUsage (see the KeyUsage extension
defined in [RFC5280]). defined in [RFC5280]).
4. IANA Considerations 4. IANA Considerations
TBD This document registers the "delegated_credentials" extension in the
"TLS ExtensionType Values" registry. The "delegated_credentials"
extension has been assigned a code point of TBD. The IANA registry
lists this extension as "Recommended" (i.e., "Y") and indicates that
it may appear in the ClientHello (CH), CertificateRequest (CR), or
Certificate (CT) messages in TLS 1.3 [RFC8446].
5. Security Considerations 5. Security Considerations
5.1. Security of delegated private key 5.1. Security of delegated private key
Delegated credentials limit the exposure of the TLS private key by Delegated credentials limit the exposure of the TLS private key by
limiting its validity. An attacker who compromises the private key limiting its validity. An attacker who compromises the private key
of a delegated credential can act as a man in the middle until the of a delegated credential can act as a man-in-the-middle until the
delegate credential expires, however they cannot create new delegated delegate credential expires, however they cannot create new delegated
credentials. Thus, delegated credentials should not be used to send credentials. Thus, delegated credentials should not be used to send
a delegation to an untrusted party, but is meant to be used between a delegation to an untrusted party, but is meant to be used between
parties that have some trust relationship with each other. The parties that have some trust relationship with each other. The
secrecy of the delegated private key is thus important and several secrecy of the delegated private key is thus important and several
access control mechanisms SHOULD be used to protect it, including access control mechanisms SHOULD be used to protect it, including
file system controls, physical security, or hardware security file system controls, physical security, or hardware security
modules. modules.
5.2. Revocation of delegated credentials 5.2. Re-use of delegated credentials in multiple contexts
It is possible to use the same delegated credential for both client
and server authentication if the Certificate allows it. This is safe
because the context string used for delegated credentials is distinct
in both contexts.
5.3. Revocation of delegated credentials
Delegated credentials do not provide any additional form of early Delegated credentials do not provide any additional form of early
revocation. Since it is short lived, the expiry of the delegated revocation. Since it is short lived, the expiry of the delegated
credential would revoke the credential. Revocation of the long term credential would revoke the credential. Revocation of the long term
private key that signs the delegated credential also implicitly private key that signs the delegated credential also implicitly
revokes the delegated credential. revokes the delegated credential.
5.3. Privacy considerations 5.4. Privacy considerations
Delegated credentials can be valid for 7 days and it is much easier Delegated credentials can be valid for 7 days and it is much easier
for a service to create delegated credential than a certificate for a service to create delegated credential than a certificate
signed by a CA. A service could determine the client time and clock signed by a CA. A service could determine the client time and clock
skew by creating several delegated credentials with different expiry skew by creating several delegated credentials with different expiry
timestamps and observing whether the client would accept it. Client timestamps and observing whether the client would accept it. Client
time could be unique and thus privacy sensitive clients, such as time could be unique and thus privacy sensitive clients, such as
browsers in incognito mode, who do not trust the service might not browsers in incognito mode, who do not trust the service might not
want to advertise support for delegated credentials or limit the want to advertise support for delegated credentials or limit the
number of probes that a server can perform. number of probes that a server can perform.
 End of changes. 30 change blocks. 
63 lines changed or deleted 113 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/