RFC 7030
Enrollment over Secure Transport
3. Protocol Design and Layering
Figure 2 provides an expansion of Figure 1, describing how the layers are used. Each aspect is described in more detail in the sections that follow. EST Layering: Protocols and uses: +----------------------------------------------------+ | | | Message types: | | - "Simple PKI" messages | | (incorporates proof-of-possession) | | - CA certificate retrieval | | - "Full PKI" messages (OPTIONAL) | | (incorporates proof-of-possession) | | - CSR Attributes Request (OPTIONAL) | | - Server-generated key request (OPTIONAL) | | | +----------------------------------------------------+ | | | HTTP: | | - HTTP headers and URIs for control | | - Content-Type headers specify message type | | - Headers for control/error messages | | - URIs for selecting functions | | - Basic or Digest authentication (OPTIONAL) | | | +----------------------------------------------------+ | | | TLS for transport security: | | - Authentication of the EST server | | - Authentication of the EST client (OPTIONAL) | | - Provides communications integrity | | and confidentiality | | - Supplies channel-binding [RFC5929] information | | to link proof-of-identity with message-based | | proof-of-possession (OPTIONAL) | | | +----------------------------------------------------+ Figure 2 Specifying HTTPS as the secure transport for enrollment messages introduces two "layers" to communicate authentication and control messages: TLS and HTTP.
The TLS layer provides integrity and confidentiality during transport. The proof-of-identity is supplied by TLS handshake authentication and optionally also by the HTTP layer headers. The message type and control/error messages are included in the HTTP headers. CMC ([RFC5272], Section 3.1) notes that "the Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included". Since the TLS and HTTP layers can provide proof-of-identity for EST clients and servers, the Simple PKI message types are used. The TLS layer certificate exchange provides a method for authorizing client enrollment requests using existing certificates. Such certificates may have been issued by the CA (from which the client is requesting a certificate), or they may have been issued under a distinct PKI (e.g., an IEEE 802.1AR Initial Device Identifier (IDevID) [IDevID] credential). Proof-of-possession (POP) is a distinct issue from proof-of-identity and is included in the Simple PKI message type as described in Section 3.4. A method of linking proof-of-identity and proof-of-possession is described in Section 3.5. This document also defines transport for CMC [RFC5272] that complies with the CMC Transport Protocols [RFC5273]. CMC's POP and proof-of-identity mechanisms are defined in CMC, but the mechanisms here can also be used in conjunction with those mechanisms in "Full PKI" messages. During protocol exchanges, different certificates can be used. The following table provides an informative overview. End-entities can have one or more certificates of each type listed in Figure 3 and use one or more trust anchor databases of each type listed in Figure 4.
Certificates and their corresponding uses: +--------------+--------------------+-------------------------------+ | Certificate | Issuer | Use and section references | +==============+====================+===============================+ | EST server | The CA served by | Presented by the EST server | | certificate | the EST server | during the TLS handshake. | | | | | | | | Section 3.3.1 | +--------------+--------------------+-------------------------------+ | EST server | A CA | Presented by the EST server | | certificate | authenticatable by | during the TLS handshake. | | | a third-party TA, | | | | e.g., a web server | Section 3.3.1 and | | | CA | Security Considerations | +--------------+--------------------+-------------------------------+ | Third-party | A CA | Presented by the EST client | | EST client | authenticatable by | to the EST server by clients | | certificate | a third-party TA, | that have not yet enrolled. | | | e.g., a device | | | | manufacturer | Section 3.3.2 | +--------------+--------------------+-------------------------------+ | EST client | The CA served by | Presented to the EST server | | certificate | the EST server | during future EST operations. | | | | | | | | Section 3.3.2 | +--------------+--------------------+-------------------------------+ | End-entity | The CA served by | Clients can obtain certs | | certificate | the EST server | that are intended for | | | | non-EST uses. This includes | | | | certs that cannot be used | | | | for EST operations. | | | | | | | | Section 4.2.3 | +--------------+--------------------+-------------------------------+ Figure 3
Trust anchor databases and their corresponding uses: +--------------+----------------------------------------------------+ | TA database | Use and section references | +==============+====================================================+ | EST server | EST servers use this TA database to authenticate | | Explicit | certificates issued by the EST CA, including EST | | TA database | client certificates during enroll/re-enroll | | | operations. | | | | | | Section 3.3.2 | +--------------+----------------------------------------------------+ | EST server | EST servers use this TA database to authenticate | | Implicit | certificates issued by third-party TAs; | | TA database | e.g., EST client certificates issued by a device | | | manufacturer. | | | An Implicit TA database can be disabled. | | | | | | Section 3.3.2 | +--------------+----------------------------------------------------+ | EST client | EST clients use this TA database to authenticate | | Explicit | certificates issued by the EST CA, including EST | | TA database | server certificates. | | | | | | Sections 3.1, 3.3.1, 3.6.1, and 4.1.1 | +--------------+----------------------------------------------------+ | EST client | EST clients use this TA database to | | Implicit | authenticate an EST server that uses an externally | | TA database | issued certificate. | | | An Implicit TA database can be disabled. | | | | | | Sections 3.1, 3.3.1, 3.6.2, and | | | Security Considerations | +--------------+----------------------------------------------------+ Figure 43.1. Application Layer
The EST client MUST be capable of generating and parsing Simple PKI messages (see Section 4.2). Generating and parsing Full PKI messages is OPTIONAL (see Section 4.3). The client MUST also be able to request CA certificates from the EST server and parse the returned "bag" of certificates (see Section 4.1). Requesting CSR attributes and parsing the returned list of attributes is OPTIONAL (see Section 4.5).
Details of the EST client application configuration are out of scope of the protocol discussion but are necessary for understanding the prerequisites of initiating protocol operations. The EST client is RECOMMENDED to be configured with TA databases for Section 3.3.1 or with a secret key for Section 3.3.3. Implementations conforming to this standard MUST provide the ability to designate Explicit TAs. For human usability reasons, a "fingerprint" of an Explicit TA database entry can be configured for bootstrapping as discussed in Section 4.1.1. Configuration of an Implicit TA database, perhaps by its inclusion within the EST client distribution or available from the operating system, provides flexibility along with the caveats detailed in Section 6. Implementations conforming to this standard MUST provide the ability to disable use of any Implicit TA database. The EST client is configured with sufficient information to form the EST server URI. This can be the full operation path segment (e.g., https://www.example.com/.well-known/est/ or https://www.example.com/.well-known/est/arbitraryLabel1), or the EST client can be configured with a tuple composed of the authority portion of the URI along with the OPTIONAL label (e.g., "www.example.com:80" and "arbitraryLabel1") or just the authority portion of the URI.3.2. HTTP Layer
HTTP is used to transfer EST messages. URIs are defined for handling each media type (i.e., message type) as described in Section 3.2.2. HTTP is also used for client authentication services when TLS client authentication is not available, due to the lack of a client certificate suitable for use by TLS (see Section 3.2.3). HTTP authentication can also be used in addition to TLS client authentication if the EST server wishes additional authentication information, as noted in Section 2.2.3. Registered media types are used to convey EST messages as specified in Figure 6. HTTP 1.1 [RFC2616] and above support persistent connections. As described in Section 8.1 of RFC 2616, persistent connections may be used to reduce network and processing loads associated with multiple HTTP requests. EST does not require or preclude persistent HTTP connections.
3.2.1. HTTP Headers for Control
The HTTP Status value is used to communicate success or failure of an EST function. HTTP authentication is used by a client when requested by the server. The media types specified in the HTTP Content-Type header indicate which EST message is being transferred. Media types used by EST are specified in Section 3.2.4. HTTP redirections (3xx status codes) to the same web origin (see [RFC6454]) SHOULD be handled by the client without user input so long as all applicable security checks (Sections 3.3 and 3.6) have been enforced on the initial connection. The client initiates a new TLS connection and performs all applicable security checks when redirected to other web origin servers. Redirections to other web origins require the EST client to obtain user input for non-GET or HEAD requests as specified in [RFC2616]. Additionally, if the client has already generated a CSR that includes linking identity and POP information (Section 3.5), then the CSR will need to be recreated to incorporate the tls-unique from the new, redirected session. Note: the key pair need not be regenerated. These are processing and interface burdens on the client. EST server administrators are advised to take this into consideration.
3.2.2. HTTP URIs for Control
The EST server MUST support the use of the path-prefix of "/.well- known/" as defined in [RFC5785] and the registered name of "est". Thus, a valid EST server URI path begins with "https://www.example.com/.well-known/est". Each EST operation is indicated by a path-suffix that indicates the intended operation: Operations and their corresponding URIs: +------------------------+-----------------+-------------------+ | Operation |Operation path | Details | +========================+=================+===================+ | Distribution of CA | /cacerts | Section 4.1 | | Certificates (MUST) | | | +------------------------+-----------------+-------------------+ | Enrollment of | /simpleenroll | Section 4.2 | | Clients (MUST) | | | +------------------------+-----------------+-------------------+ | Re-enrollment of | /simplereenroll | Section 4.2.2 | | Clients (MUST) | | | +------------------------+-----------------+-------------------+ | Full CMC (OPTIONAL) | /fullcmc | Section 4.3 | +------------------------+-----------------+-------------------+ | Server-Side Key | /serverkeygen | Section 4.4 | | Generation (OPTIONAL) | | | +------------------------+-----------------+-------------------+ | CSR Attributes | /csrattrs | Section 4.5 | | (OPTIONAL) | | | +------------------------+-----------------+-------------------+ Figure 5 The operation path (Figure 5) is appended to the path-prefix to form the URI used with HTTP GET or POST to perform the desired EST operation. An example valid URI absolute path for the "/cacerts" operation is "/.well-known/est/cacerts". To retrieve the CA's certificates, the EST client would use the following HTTP request-line: GET /.well-known/est/cacerts HTTP/1.1 Likewise, to request a new certificate in this example scheme, the EST client would use the following request-line: POST /.well-known/est/simpleenroll HTTP/1.1
The use of distinct operation paths simplifies implementation for servers that do not perform client authentication when distributing /cacerts responses. An EST server MAY provide service for multiple CAs as indicated by an OPTIONAL additional path segment between the registered application name and the operation path. To avoid conflict, the CA label MUST NOT be the same as any defined operation path segment. The EST server MUST provide services regardless of whether the additional path segment is present. The following are three example valid URIs: 1. https://www.example.com/.well-known/est/cacerts 2. https://www.example.com/.well-known/est/arbitraryLabel1/cacerts 3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts In this specification, the distinction between enroll and renew/rekey is explicitly indicated by the HTTP URI. When requesting /fullcmc operations, CMC [RFC5272] uses the same messages for certificate renewal and certificate rekey. An EST server can provide additional services using other URIs.3.2.3. HTTP-Based Client Authentication
The EST server MAY request HTTP-based client authentication. This request can be in addition to successful TLS client authentication (Section 3.3.2) if EST server policy requires additional authentication. (For example, the EST server may require that an EST client "knows" a password in addition to "having" an existing client certificate.) Or, HTTP-based client authentication can be an EST server policy-specified fallback in situations where the EST client did not successfully complete the TLS client authentication. (This might arise if the EST client is enrolling for the first time or if the certificates available to an EST client cannot be used for TLS client authentication.) HTTP Basic and Digest authentication MUST only be performed over TLS 1.1 [RFC4346] or later versions. NULL and anon cipher suites MUST NOT be used because they do not provide confidentiality or support mutual certificate-based or certificate-less authentication, respectively. As specified in "Certificate Management over CMS (CMC): Transport Protocols" [RFC5273], the server "MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication". Clients SHOULD support the Basic and Digest authentication mechanism.
Servers that wish to use Basic and Digest authentication reject the HTTP request using the HTTP-defined WWW-Authenticate response-header ([RFC2616], Section 14.47). The client is expected to retry the request, including the appropriate Authorization Request header ([RFC2617], Section 3.2.2), if the client is capable of using the Basic or Digest authentication. If the client is not capable of retrying the request or it is not capable of Basic or Digest authentication, then the client MUST terminate the connection. A client MAY set the username to the empty string ("") if it is presenting a password that is not associated with a username. Support for HTTP-based client authentication has security ramifications as discussed in Section 6. The client MUST NOT respond to the server's HTTP authentication request unless the client has authorized the EST server (as per Section 3.6).
3.2.4. Message Types
This document uses existing media types for the messages as specified by FTP and HTTP [RFC2585], application/pkcs10 [RFC5967], and CMC [RFC5272]. For consistency with [RFC5273], each distinct EST message type uses an HTTP Content-Type header with a specific media type. The EST messages and their corresponding media types for each operation are: +--------------------+--------------------------+-------------------+ | Message type | Request media type | Request section(s)| | | Response media type(s) | Response section | | (per operation) | Source(s) of types | | +====================+==========================+===================+ | Distribution of CA | N/A | Section 4.1 | | Certificates | application/pkcs7-mime | Section 4.1.1 | | | [RFC5751] | | | /cacerts | | | +--------------------+--------------------------+-------------------+ | Client Certificate | application/pkcs10 | Sections 4.2/4.2.1| | Request Functions | application/pkcs7-mime | Section 4.2.2 | | | [RFC5967] [RFC5751] | | | /simpleenroll | | | | /simplereenroll | | | +--------------------+--------------------------+-------------------+ | Full CMC | application/pkcs7-mime | Section 4.3.1 | | | application/pkcs7-mime | Section 4.3.2 | | /fullcmc | [RFC5751] | | +--------------------+--------------------------+-------------------+ | Server-Side Key | application/pkcs10 | Section 4.4.1 | | Generation | multipart/mixed | Section 4.4.2 | | | (application/pkcs7-mime &| | | | application/pkcs8) | | | | [RFC5967] [RFC5751] | | | /serverkeygen | [RFC5958] | | +--------------------+--------------------------+-------------------+ | CSR Attributes | N/A | Section 4.5.1 | | | application/csrattrs | Section 4.5.2 | | | (This document) | | | /csrattrs | | | +--------------------+--------------------------+-------------------+ Figure 6
3.3. TLS Layer
TLS provides authentication, which in turn enables authorization decisions. The EST server and EST client are responsible for ensuring that an acceptable cipher suite is negotiated and that mutual authentication has been performed. TLS authentication is most commonly enabled with the use of certificates [RFC5280]. Alternately, certificate-less TLS authentication, where neither the client nor server present a certificate, is also an acceptable method for EST mutual authentication (Section 3.3.3). The EST server MUST be authenticated during the TLS handshake unless the client is requesting Bootstrap Distribution of CA certificates (Section 4.1.1) or Full CMC (Section 4.3). HTTPS [RFC2818] specifies how HTTP messages are carried over TLS. HTTPS MUST be used. TLS 1.1 [RFC4346] (or a later version) MUST be used for all EST communications. TLS session resumption [RFC5077] SHOULD be supported. TLS channel-binding information can be inserted into a certificate request, as detailed in Section 3.5, in order to provide the EST server with assurance that the authenticated TLS client has access to the private key for the certificate being requested. The EST server MUST implement Section 3.5.3.3.1. TLS-Based Server Authentication
TLS server authentication with certificates MUST be supported. The EST client authenticates the EST server as defined for the cipher suite negotiated. The following text provides details assuming a certificate-based cipher suite, such as the TLS 1.1 [RFC4346] mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). Certificate validation MUST be performed as per [RFC5280]. The EST server certificate MUST conform to the [RFC5280] certificate profile. The client validates the TLS server certificate using the EST client Explicit and, if enabled, Implicit TA database(s). The client MUST maintain a distinction between the use of Explicit and Implicit TA databases during authentication in order to support proper authorization. The EST client MUST perform authorization checks as specified in Section 3.6. If certificate validation fails, the client MAY follow the procedure outlined in Section 4.1.1 for Bootstrap Distribution of CA certificates.
3.3.2. TLS-Based Client Authentication
TLS client authentication is the RECOMMENDED method for identifying EST clients. HTTP-based client authentication (Section 3.2.3) MAY be used. The EST server authenticates the EST client as defined for the cipher suite negotiated. The following text provides details assuming a certificate-based cipher suite such as the TLS 1.1 [RFC4346] mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). The EST server MUST support certificate-based client authentication. Generally, the client will use an existing certificate for renew or rekey operations. If the certificate to be renewed or rekeyed is appropriate for the negotiated cipher suite, then the client MUST use it for the TLS handshake, otherwise the client SHOULD use an alternate certificate that is suitable for the cipher suite and contains the same subject identity information. When requesting an enroll operation, the client MAY use a client certificate issued by a third party to authenticate itself. Certificate validation MUST be performed as per [RFC5280]. The EST client certificate MUST conform to the [RFC5280] certificate profile. The server validates the TLS client certificate using the EST server Explicit and, if enabled, Implicit TA database(s). The server MUST maintain a distinction between the use of Explicit and Implicit TA databases during authentication in order to support proper authorization. The EST server MUST perform authorization checks as specified in Section 3.7. If a client does not support TLS client authentication, then it MUST support HTTP-based client authentication (Section 3.2.3) or certificate-less TLS authentication (Section 3.3.3).3.3.3. Certificate-Less TLS Mutual Authentication
Certificate-less TLS cipher suites provide a way to perform mutual authentication in situations where neither the client nor server have certificates, do not desire to use certificates, or do not have the trust anchors necessary to verify a certificate. The client and server MAY negotiate a certificate-less cipher suite for mutual authentication. When using certificate-less mutual authentication in TLS for enrollment, the cipher suite MUST be based on a protocol that is
resistant to dictionary attack and MUST be based on a zero knowledge protocol. Transport Layer Security-Secure Remote Password (TLS-SRP) cipher suites, i.e., those with _SRP_ in the name, listed in Section 2.7 of [RFC5054] are suitable for this purpose. Section 6 lists the characteristics of a cipher suite that are suitable for use in certificate-less mutual authentication for enrollment. Successful authentication using a certificate-less cipher suite proves knowledge of a pre-shared secret that implicitly authorizes a peer in the exchange.3.4. Proof-of-Possession
As defined in Section 2.1 of CMC [RFC5272], proof-of-possession (POP) "refers to a value that can be used to prove that the private key corresponding to the public key is in the possession of and can be used by an end-entity". The signed enrollment request provides a signature-based proof-of-possession. The mechanism described in Section 3.5 strengthens this by optionally including "Direct"-based proof-of-possession [RFC5272] by including TLS session-specific information within the data covered by the enrollment request signature (thus linking the enrollment request to the authenticated end point of the TLS connection).3.5. Linking Identity and POP Information
Server policy will determine whether clients are required to use the mechanism specified in this section. This specification provides a method of linking identity and proof-of-possession by including information specific to the current authenticated TLS session within the signed certification request. The client can determine if the server requires the linking of identity and POP by examining the CSR Attributes Response (see Section 4.5.2). Regardless of the CSR Attributes Response, clients SHOULD link identity and POP by embedding tls-unique information in the certification request. If tls-unique information is included by the client, the server MUST verify it. The EST server MAY reject requests without tls-unique information as indicated by server policy. Linking identity and proof-of-possession proves to the server that the authenticated TLS client has possession of the private key associated with the certification request, and that the client was able to sign the certification request after the TLS session was established. This is an alternative to the "Linking Identity and POP Information" method defined by Section 6 of [RFC5272] that is available if Full PKI messages are used.
The client generating the CSR obtains the tls-unique value from the TLS subsystem as described in Channel Bindings for TLS [RFC5929]. The EST client operations between obtaining the tls-unique value through generation of the CSR that contains the current tls-unique value and the subsequent verification of this value by the EST server are the "phases of the application protocol during which application- layer authentication occurs"; these operations are protected by the synchronization interoperability mechanism described in the "Channel Bindings for TLS" interoperability notes in Section 3.1 of [RFC5929]. When performing renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used. The tls-unique value is base64 encoded as specified in Section 4 of [RFC4648], and the resulting string is placed in the certification request challenge-password field ([RFC2985], Section 5.4.1). The challenge-password field is limited to 255 bytes (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite would result in an issue with this limitation). If the challenge-password attribute is absent, the client did not include the optional channel-binding information (the presence of the challenge-password attribute indicates the inclusion of tls-unique information). If the EST server makes use of a back-end infrastructure for processing, it is RECOMMENDED that the results of this verification be communicated. (For example, this communication might use the CMC [RFC5272] "RA POP Witness Control" in a CMC Full PKI Request message. Or, an EST server might TLS-authenticate an EST client as being a trusted infrastructure element that does not forward invalid requests. A detailed discussion of back-end processing is out of scope.) When rejecting requests, the EST server response is as described for all enroll responses (Section 4.2.3). If a Full PKI Response is included, the CMCFailInfo MUST be set to popFailed. If a human- readable reject message is included, it SHOULD include an informative text message indicating that the linking of identity and POP information is required.3.6. Server Authorization
The client MUST check EST server authorization before accepting any server responses or responding to HTTP authentication requests. The EST client authorization method depends on which method was used to authenticate the server. When the Explicit TA database is used to authenticate the EST server, then Section 3.6.1 applies. When the Implicit TA database is used to authenticate the EST server, then
Section 3.6.2 applies. Successful authentication using a certificate-less cipher suite implies authorization of the server. The client MAY perform bootstrapping as specified in Section 4.1.1 even if these checks fail.3.6.1. Client Use of Explicit TA Database
When the EST client Explicit TA database is used to validate the EST server certificate, the client MUST check either the configured URI or the most recent HTTP redirection URI against the server's identity according to the rules specified in [RFC6125], Section 6.4, or the EST server certificate MUST contain the id-kp-cmcRA [RFC6402] extended key usage extension.3.6.2. Client Use of Implicit TA Database
When the EST client Implicit TA database is used to validate the EST server certificate, the client MUST check the configured URI and each HTTP redirection URI according to the rules specified in [RFC6125], Section 6.4. The provisioned URI or the most recent HTTP redirection URI provides the basis for authorization, and the server's authenticated identity confirms it is the authorized server.3.7. Client Authorization
The decision to issue a certificate to a client is always controlled by local CA policy. The EST server configuration reflects this CA policy. This document does not specify any constraints on such policy. EST provides the EST server access to each client's authenticated identity -- e.g., the TLS client's certificate in addition to any HTTP user authentication credentials -- to help in implementing such policy. If the client's certificate was issued by the EST CA, and it includes the id-kp-cmcRA [RFC6402] extended key usage extension, then the client is a Registration Authority (RA) as described in [RFC5272] and [RFC6402]. In this case, the EST server SHOULD apply authorization policy consistent with an RA client. For example, when handling /simpleenroll requests, the EST server could be configured to accept POP linking information that does not match the current TLS session because the authenticated EST client RA has verified this information when acting as an EST server (as specified in Section 3.5). More specific RA mechanisms are available if the EST client uses /fullcmc methods.
(next page on part 3)
