RFC 7030
Enrollment over Secure Transport
Internet Engineering Task Force (IETF) M. Pritikin, Ed. Request for Comments: 7030 Cisco Systems, Inc. Category: Standards Track P. Yee, Ed. ISSN: 2070-1721 AKAYLA, Inc. D. Harkins, Ed. Aruba Networks October 2013 Enrollment over Secure TransportAbstract
This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7030.
Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................3 1.1. Terminology ................................................4 2. Operational Scenario Overviews ..................................5 2.1. Obtaining CA Certificates ..................................6 2.2. Initial Enrollment .........................................7 2.2.1. Certificate TLS Authentication ......................8 2.2.2. Certificate-Less TLS Authentication .................8 2.2.3. HTTP-Based Client Authentication ....................8 2.3. Client Certificate Reissuance ..............................8 2.4. Server Key Generation ......................................9 2.5. Full PKI Request Messages ..................................9 2.6. Certificate Signing Request (CSR) Attributes Request .......9 3. Protocol Design and Layering ...................................10 3.1. Application Layer .........................................13 3.2. HTTP Layer ................................................14 3.2.1. HTTP Headers for Control ...........................15 3.2.2. HTTP URIs for Control ..............................16 3.2.3. HTTP-Based Client Authentication ...................17 3.2.4. Message Types ......................................19 3.3. TLS Layer .................................................20 3.3.1. TLS-Based Server Authentication ....................20 3.3.2. TLS-Based Client Authentication ....................21 3.3.3. Certificate-Less TLS Mutual Authentication .........21 3.4. Proof-of-Possession .......................................22 3.5. Linking Identity and POP Information ......................22 3.6. Server Authorization ......................................23 3.6.1. Client Use of Explicit TA Database .................24 3.6.2. Client Use of Implicit TA Database .................24 3.7. Client Authorization ......................................24 4. Protocol Exchange Details ......................................25 4.1. Distribution of CA Certificates ...........................25
4.1.1. Bootstrap Distribution of CA Certificates ..........25
4.1.2. CA Certificates Request ............................26
4.1.3. CA Certificates Response ...........................26
4.2. Client Certificate Request Functions ......................27
4.2.1. Simple Enrollment of Clients .......................28
4.2.2. Simple Re-enrollment of Clients ....................29
4.2.3. Simple Enroll and Re-enroll Response ...............29
4.3. Full CMC ..................................................30
4.3.1. Full CMC Request ...................................30
4.3.2. Full CMC Response ..................................30
4.4. Server-Side Key Generation ................................31
4.4.1. Server-Side Key Generation Request .................32
4.4.1.1. Requests for Symmetric Key
Encryption of the Private Key .............32
4.4.1.2. Requests for Asymmetric Encryption
of the Private Key ........................33
4.4.2. Server-Side Key Generation Response ................33
4.5. CSR Attributes ............................................35
4.5.1. CSR Attributes Request .............................35
4.5.2. CSR Attributes Response ............................35
5. IANA Considerations ............................................37
6. Security Considerations ........................................39
7. References .....................................................41
7.1. Normative References ......................................41
7.2. Informative References ....................................43
Appendix A. Operational Scenario Example Messages .................45
A.1. Obtaining CA Certificates ..................................45
A.2. CSR Attributes .............................................47
A.3. Enroll/Re-enroll ...........................................47
A.4. Server Key Generation ......................................50
Appendix B. Contributors and Acknowledgements .....................52
1. Introduction
This document profiles certificate enrollment for clients using
Certificate Management over CMS (CMC) [RFC5272] messages over a
secure transport. Enrollment over Secure Transport (EST) describes
the use of Transport Layer Security (TLS) 1.1 [RFC4346], 1.2
[RFC5246], or any future version) and Hypertext Transfer Protocol
(HTTP) [RFC2616] to provide an authenticated and authorized channel
for Simple Public Key Infrastructure (PKI) Requests and Responses
[RFC5272].
Architecturally, the EST service is located between a Certification
Authority (CA) and a client. It performs several functions
traditionally allocated to the Registration Authority (RA) role in a
PKI. The nature of communication between an EST server and a CA is
not described in this document.
EST adopts the Certificate Management Protocol (CMP) [RFC4210] model for CA certificate rollover, but it does not use the CMP message syntax or protocol. EST servers are extensible in that new functions may be defined to provide additional capabilities not specified in CMC [RFC5272], and this document defines two such extensions: one for requesting Certificate Signing Request attributes and another for requesting server-generated keys. EST specifies how to transfer messages securely via HTTP over TLS (HTTPS) [RFC2818], where the HTTP headers and media types are used in conjunction with TLS. HTTPS operates over TCP; this document does not specify EST over HTTP/Datagram Transport Layer Security/User Datagram Protocol (HTTP/DTLS/UDP). With a suitable specification for combining HTTP, DTLS, and UDP, there are no EST requirements that would prevent it from working over such a stack. Figure 1 shows how the layers build upon each other. EST Layering: Protocols: +--------------------------------------------+ | | | EST request/response messages | | | +--------------------------------------------+ | | | HTTP for message transfer and signaling | | | +--------------------------------------------+ | | | TLS for transport security | | | +--------------------------------------------+ | | | TCP for transport | | | +--------------------------------------------+ Figure 11.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
It is assumed that the reader is familiar with the terms and concepts described in Public Key Cryptography Standard (PKCS) #10 [RFC2986], HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272][RFC5273][RFC5274], and TLS [RFC4346]. In addition to the terms defined in the terminology section of CMC [RFC5272], the following terms are defined for clarity: EST CA: For certificate issuing services, the EST CA is reached through the EST server; the CA could be logically "behind" the EST server or embedded within it. Third-Party Trust Anchor: Any trust anchor (TA) that is not authoritative for the PKI hierarchy for which the EST server is providing services. Explicit Trust Anchor: Any TA that is explicitly configured on the client or server for use during EST TLS authentication; for example, a TA that is manually configured on the EST client or bootstrapped as described in Section 4.1.1. (See more details in Sections 3.6 and 6.) Implicit Trust Anchor: Any third-party TA that is available on the client or server for use during TLS authentication but is not specifically indicated for use during EST TLS authentication; for example, TAs commonly used by web browsers to authenticate web servers or TAs used by servers to authenticate manufacturer- installed client credentials (such as certificates populated into cable modems or routers in the factory). The authorization model for these TAs is different from the authorization model for Explicit Trust Anchors. (See more details in Sections 3.6.1, 3.6.2, and 6). Certificate-Less TLS: Certificate-less TLS cipher suites provide a way to perform mutual authentication in situations where neither the client nor server have certificates or are willing to use them. The credential used for authentication is a word, phrase, code, or key that is shared between the client and server. The credential must be uniquely shared between the client and server in order to provide authentication of an individual client to an individual server.2. Operational Scenario Overviews
This section provides an informative overview of the operational scenarios to better introduce the reader to the protocol discussion.
Both the EST clients and server are configured with information that provides the basis for mutual authentication and for authorization. The specific initialization data depends on the methods available in the client and server, but it can include shared secrets, network service names and locations (e.g., a Uniform Resource Identifier (URI) [RFC3986]), trust anchor information (e.g., a CA certificate or a hash of a TA's certificate), and enrollment keys and certificates. Depending on an enterprise's acquisition and network management practices, some initialization may be performed by the vendor prior to delivery of client hardware and software. In that case, the client vendor may provide data, such as trust anchors, to the enterprise via a secure procedure. The distribution of this initial information is out of scope. Distribution of trust anchors and other certificates can be effected via the EST server. However, nothing can be inferred about the authenticity of this data until an out-of-band mechanism is used to verify them. Sections 2.1-2.3 very closely mirror the text of the Scenarios Appendix of [RFC6403] with such modifications as are appropriate for this profile. Sections 2.1-2.6, below, enumerate the set of EST functions (see Figure 5) and provide an informative overview of EST's capabilities. The general client/server interaction proceeds as follows: The client initiates a TLS-secured HTTP session with an EST server. A specific EST service is requested based on a portion of the URI used for the session. The client and server authenticate each other. The client verifies that the server is authorized to serve this client. The server verifies that the client is authorized to make use of this server and the request that the client has made. The server acts upon the client request.2.1. Obtaining CA Certificates
The EST client can request a copy of the current EST CA certificate(s) from the EST server. The EST client is assumed to perform this operation before performing other operations.
Throughout this document we assume the EST CA has a certificate that is used by the client to verify signed objects issued by the CA, e.g., certificates and certificate revocation lists (CRLs), and that a different certificate than the one used to verify signatures on certificates and CRLs is used when EST protocol communication requires additional encryption. The EST client authenticates and verifies the authorization scope of the EST server when requesting the current CA certificate(s). As detailed in Sections 3.3.1 and 3.3.3, available options include: o Verifying the EST server's HTTPS URI against the EST server's certificate using Implicit TAs (similar to a common HTTPS exchange). This allows the EST server and client to leverage existing TAs that might be known to the EST client. o The client can leverage a previously distributed trust anchor specific to the EST server. This allows the EST client to use an existing, potentially older, CA certificate to request a current CA certificate. o For bootstrapping, the EST client can rely upon manual authentication performed by the end-user as detailed in Section 4.1.1. o The client can leverage the binding of a shared credential to a specific EST server with a certificate-less TLS cipher suite. Client authentication is not required for this exchange, so it is trivially supported by the EST server.2.2. Initial Enrollment
After authenticating an EST server and verifying that it is authorized to provide services to the client, an EST client can acquire a certificate for itself by submitting an enrollment request to that server. The EST server authenticates and authorizes the EST client as specified in Sections 3.3.2, 3.3.3, and 3.7. The methods described in the normative text that are discussed in this overview include: o TLS with a previously issued client certificate (e.g., an existing certificate issued by the EST CA); o TLS with a previously installed certificate (e.g., manufacturer- installed certificate or a certificate issued by some other party);
o Certificate-less TLS (e.g., with a shared credential distributed
out-of-band);
o HTTP-based with a username/password distributed out-of-band.
2.2.1. Certificate TLS Authentication
If the EST client has a previously installed certificate issued by a
third-party CA, this certificate can be used to authenticate the
client's request for a certificate from the EST server (if that CA is
recognized by the EST server). An EST client responds to the EST
server's TLS certificate request message with the existing
certificate already held by the client. The EST server will verify
the client's existing certificate and authorize the client's request
as described in Section 3.3.2.
2.2.2. Certificate-Less TLS Authentication
The EST client and EST server can be mutually authenticated using a
certificate-less TLS cipher suite (see Section 3.3.3).
2.2.3. HTTP-Based Client Authentication
The EST server can optionally also request that the EST client submit
a username/password using the HTTP Basic or Digest authentication
methods (see Section 3.2.3). This approach is desirable if the EST
client cannot be authenticated during the TLS handshake (see
Section 3.3.2) or the EST server policy requires additional
authentication information; see Section 3.2.3. In all cases,
HTTP-based client authentication is only to be performed over a
TLS-protected transport (see Section 3.3).
2.3. Client Certificate Reissuance
An EST client can renew/rekey its existing client certificate by
submitting a re-enrollment request to an EST server.
When the current EST client certificate can be used for TLS client
authentication (Section 3.3.2), the client presents this certificate
to the EST server for client authentication. When the to be reissued
EST client certificate cannot be used for TLS client authentication,
any of the authentication methods used for initial enrollment can be
used.
For example, if the client has an alternative certificate issued by
the EST CA that can be used for TLS client authentication, then it
can be used.
The certificate request message includes the same Subject and SubjectAltName as the current certificate. Name changes are requested as specified in Section 4.2.2.2.4. Server Key Generation
The EST client can request a server-generated certificate and key pair (see Section 4.4).2.5. Full PKI Request Messages
Full PKI Request [RFC5272] messages can be transported via EST using the Full CMC Request function. This affords access to functions not provided by the Simple Enrollment functions. Full PKI Request messages are defined in Sections 3.2 and 4.2 of [RFC5272]. See Section 4.3 for a discussion of how EST provides a transport for these messages.2.6. Certificate Signing Request (CSR) Attributes Request
Prior to sending an enrollment request to an EST server, an EST client can query the EST server for a set of additional attributes that the client is requested to use in a subsequent enrollment request. These attributes can provide additional descriptive information that the EST server cannot access itself, such as the Media Access Control (MAC) address of an interface of the EST client. Alternatively, these attributes can indicate the kind of enrollment request, such as a specific elliptic curve or a specific hash function that the client is expected to use when generating the CSR.
(next page on part 2)
