Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7030

Enrollment over Secure Transport

Pages: 53
Proposed Standard
Updated by:  89518996
Part 2 of 4 – Pages 10 to 24
First   Prev   Next

Top   ToC   RFC7030 - Page 10   prevText

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.
Top   ToC   RFC7030 - Page 11
   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

   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.
Top   ToC   RFC7030 - Page 12
   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
Top   ToC   RFC7030 - Page 13
   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 4

3.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).
Top   ToC   RFC7030 - Page 14
   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., or, 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.,
   "" 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.
Top   ToC   RFC7030 - Page 15

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.
Top   ToC   RFC7030 - Page 16

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 "". 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
Top   ToC   RFC7030 - Page 17
   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:




   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.
Top   ToC   RFC7030 - Page 18
   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).
Top   ToC   RFC7030 - Page 19

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
Top   ToC   RFC7030 - Page 20

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.
Top   ToC   RFC7030 - Page 21

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
Top   ToC   RFC7030 - Page 22
   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.
Top   ToC   RFC7030 - Page 23
   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

   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
Top   ToC   RFC7030 - Page 24
   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)

Next Section