| Internet Engineering Task Force | M. Pritikin, Ed. |
| Internet-Draft | Cisco Systems, Inc. |
| Intended status: Standards Track | March 08, 2011 |
| Expires: September 09, 2011 |
Enrollment over Secure Transport
draft-pritikin-est-00
This document specifies certificate Enrollment over Secure Transport (EST). EST is a certificate enrollment over HTTPS protocol that is trivially accessible by modern clients. The CMC "Simple PKI Messages" and simple certificate responses are leveraged and EST is designed to be easily implemented by clients and servers running other common enrollment mechanisms such as SCEP. Renewal and rekey mechanisms are described consistent with CMP.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 09, 2011.
Copyright (c) 2011 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.
This specification profiles the use of Certificate Management over CMS [RFC5272] "simple PKI Request" and "simple PKI Response" messages over HTTPS. A functional certificate management protocol is thus described that is appropriate for simple PKI clients interested in maintaining client certificate(s) and associated infrastructure certificate(s). Suite B compatibility is addressed.
A full implementation of all CMC [RFC5272] features is not required to be compliant with this specification. This is consistent with the CMC [RFC5272] protocol specification of "simple" messages for clients to use "in the event no other services are needed". When using these messages CMC [RFC5272] section 3.1 notes that "the Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included"; which precludes their use if inline authentication and/or authorization is required unless a secured transport is also specified. Many simple clients engaged in certificate enrollment operations will have a TLS client implementation available for secure transport, so HTTPS is specified herein. A Suite B compatible TLS specification exists.
Advanced clients, or components of the PKI hierarchy itself, will possibly require a complete implementation of the CMC [RFC5272] specification or additional specifications. This document provides an appropriate transport for the full CMC [RFC5272] specification that is compliant with [RFC5273].
Servers SHOULD implement the full CMC [RFC5272] functionality. Clients MAY limit their implementation to the abbreviated functionalities described in this document.
Additionally CMC [RFC5272] indicates that: "No special services are provided for doing either renewal (new certificates with the same key) or re-keying (new certificates on new keys) of clients. Instead a renewal/re-key message looks the same as any enrollment message, with the identity proof being supplied by existing certificates from the CA." This profile clarifies the renewal and re-key behavior of both the client and server by specifying the exact functionality and by specific references to the compatible renew and re-key specifications mechanisms documented in CMP [RFC4210].
[[EDNOTE: Comments such as this one, included within double brackets and initiated with an 'EDNOTE', are for editorial use and shall be removed as the document is polished.]]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This profile reduces certificate enrollment for clients to the following operations:
These functions are provided by methods at a specified HTTPS URL.
Some messages formats are defined in CMC [RFC5272] and include subsets of the PKCS#10 Certification Request [RFC2986] and the PKCS#7 [RFC2315] message specifications. Additional simple message formats are defined.
This document specifies a method for authorization of client enrollment requests using existing certificates either issued by the CA or issued by a distinct PKI hierarchy such as with an IEEE 802.1AR IDevID [IDevID] credential. Additionally this document specifies username/password authentication methods beyond those included in CMC. The necessary authentication and authorization mechanisms are provided by HTTP and TLS (HTTPS) mechanisms as indicated in this document.
HTTP Content-Type headers are as specified in CMC: Transport Protocols [RFC5273], Table 1. This document introduces new content types for the simple format messages not specified by CMC [RFC5272].
The HTTP server MAY provide non-EST services on other URLs. The server MAY handle full CMC messages over HTTP.
EST uses the HTTP "GET" and "POST" messages to communicate with the CA. The following describes the syntax of these messages:
"GET" BASEPATH OPERATIONPATH "POST" BASEPATH OPERATIONPATH
where:
When an URL is formed the BASEPATH and OPERATIONPATH are combined to form the [RFC2616] abs_path. The server and port and MUST be pre-configured or otherwise discovered by the client as described in Appendix Appendix A. Fully formed base URLs are:
These can be conveniently distributed as they are a form end users are comfortable with. The following operation URLs for client to access are defined relative to the EST base URL:
Such that the following examples form valid complete URLs:
The mechanisms by which the EST server interacts with an HTTPS server to handle GET and POST operations at these URLs is out of scope. The use of distinct URLs ensures easy implementation for servers that do not perform client authentication when distributing "CACerts" responses.
NOTE: A simple CGI application at each fully specified path, configured with appropriate permissions as per the HTTPS server configuration, is sufficient for a working example.
[[EDNOTE: This does not use the mechanism specified in "Defining Well-Known Uniform Resource Identifiers (URIs)" [RFC5785]. That would be a possibility here for a base url of "https://example.org/.well-known/EST" but such would preclude the flexibility associated with multiple base urls being handled by the same server unless some form of "?designator=value" is included.]]
At any time a client MAY request an up to date list of the CA certificates by sending an HTTPS GET message to the EST base URL with the relative path extension 'CACerts'.
The server SHOULD NOT require client authentication or authorization to service this request.
The client MUST authenticate the server as specified in Authentication and Authorization [AuthCandAuthZ]. If the authentication and authorization is successful the client accepts the CA certificates and stores them appropriately. If the authentication and authorization is not successful then when the response is received the client extracts the CA root certificate and MUST either engage the end-user or otherwise authorize the credential using out-of-band pre-configuration data such as a CA certificate "fingerprint" (eg. a SHA-1, SHA-256, SHA-512, or MD5 hash on the whole CA certificate).
Although not recommended an unconfigured client MAY accept the CA root certificate automatically if this is appropriate for the solution. A possible example is deployment of a client within an absolutely known to be secured network. The server MUST still perform appropriate authorization.
Subsequent connections to the EST server validate the TLS server certificate using the stored CA root certificates as described in Authentication and Authorization [AuthCandAuthZ].
The server MUST respond with a list of certificates containing the current CA certificates. This includes any Root CA Key Update certificates (Appendix Appendix E provides an informative summary of key renewal).
The response format is a text file containing a list of certificates each formatted as specified in Section 6.1 of [RFC4945]. Each certificate is delimited by a newline. The content-type of "application/x-est-cacerts" MUST be specified.
At any time the client MAY request a certificate from the EST base URL with the relative path extension "simpleEnroll'.
When HTTPS POSTing to the 'Enroll' location the client MUST include a CMC Simple PKI Enrollment request as specified in CMC [RFC5272] Section 3.1 (a PKCS#10 Certification Request [RFC2986].). The content-type of "application/x-est-pkcs10" MUST be specified. The format of the request is as specified in Section 6.4 of [RFC4945].
The signatureAlgorithm MAY be ecdsa-with-sha256 for P-256 certificate requests, or MAY be ecdsa-with-sha384 for P-384 certificate requests in addition to other algorithms.
[[EDNOTE: This is in alignment with draft-turner-suitb-cmc-03 section 4.1]]
The server MUST authenticate the client as specified in Authentication and Authorization [AuthCandAuthZ]. The server MAY apply any authorization or policy logic when determining if the certificate should be issued. The server MAY choose to issue a certificate modified from the initial request as specified in CMC [RFC5272] Section 3.1.
The client MUST authenticate the server as specified in Section 7.1.
At any time the client MAY request a re-enrollment certificate from the EST base URL with the relative path extension "simpleReEnroll'.
The server MUST treat the enrollment as a re-enrollment request. As specified in CMC [RFC5272] Section 2 "renewal and rekey requests look the same as any certification request, except that the identity proof is supplied by existing certificates from a trusted CA". The proof of client identity is supplied by client authentication during the HTTPS handshake. When attempting to re-enroll the client MUST use the existing certificate to be renewed.
[[EDNOTE: draft-turner-suiteb-cmc defines a method of recognizing an re-enroll based on PKCS10 contents, see section 4.1. The method described herein is explicit.]]
If the server forwards the request to back-end processes it SHOULD communicate that this is a re-enrollment attempt. For example if using this protocol to communicate with a CA the /simpleReEnroll URL is used.
The server MAY revoke the existing certificate once a replacement has been issued.
The server responds with the client's newly issued certificate or provides an error response for either 'simpleEnroll' or 'simpleReEnroll'.
If the enrollment is successful the server response MUST have a response code of 200 with a content-type of "application/x-est-x509". The response data is the certificate formatted as specified in Section 6.1 of [RFC4945].
When rejecting a request the server MUST specify either an HTTP [RFC2616] 4xx/401 error, or an HTTP 5xx error. A simple CMC response with content-type of "application/pkcs7-mime" MAY be included in the response data for any error response. If the content-type is not set the response data MUST be a plain text human readable error message. Client MAY skip parsing of CMC error responses in favor of a generic error message.
If the server responds with an HTTP [RFC2616] 501 this indicates that the attempted EST mechanisms is not implemented. The client SHOULD try using 'fullCMC'.
If the server responds with an HTTP [RFC2616] 202 this indicates that the request has been accepted for processing but that a response is not yet available. The server SHOULD include a Retry-After header similar to those seen in 503 responses. The client MUST wait at least the specified 'retry-after' time before re-attempting. If no time is specified then the client polls using an upper-bound-limited exponential back-off. The client repeats the initial enrollment request after the appropriate polling interval as expired. The client SHOULD log or inform the end user of this event. The server is responsible for maintaining all state necessary to recognize and handle subsequent poll operations as the client is stateless in this regard (it simply sends the same request repeatedly until it receives a different response code).
[[EDNOTE: An RFC reference for a back-off algorithm would be appropriate here. The initial time increment should reflect the timing of the TLS connection and message processing; selection of initial increment should reflect this.]]
All other return codes are handled as specified in HTTP [RFC2616].
At any time the client MAY request a certificate from the EST base URL with the relative path extension "fullCMC".
When HTTPS POSTing to the 'fullCMC' location the client MUST include a valid CMC message. The content-type MUST be set to "application/pkcs7-mime" as specified in CMC: Transport Protocols [RFC5273].
The client MUST authenticate the server as specified in Server Authentication [TLSserverAuthC] if an HTTPS url is used.
The server SHOULD authenticate the client as specified in Authentication and Authorization [AuthCandAuthZ]. The server MAY apply any authorization or policy logic when determining if the certificate should be issued. The server MAY choose to issue a certificate modified from the initial request as specified in CMC [RFC5272] Section 3.1. The CMS proof-of-identity mechanism MAY be used to bind the CMS message to the TLS protected session. If HTTP is used to post the request then the normal CMC proof-of-identity mechanisms are used without change.
[[EDNOTE: text detailing which and how the TLS session key is used to do this will be specified here.]]
The server responds with the client's newly issued certificate or provides an error response.
If the enrollment is successful the server response MUST have a response code of 200 with a content-type of "application/pkcs7-mime" as specified in CMC: Transport Protocols [RFC5273]. The response data includes either the CMC Simple PKI Response or the CMC Full PKI Response.
When rejecting a request the server MAY specify either an HTTP [RFC2616] 4xx/401 error, an HTTP 5xx error or a response code 200. A CMC response with content-type of "application/pkcs7-mime" MUST be included in the response data for any error response. The client MUST parse the CMC response to determine the current status.
If the server responds with an HTTP [RFC2616] 501 this indicates that the attempted EST mechanisms is not implemented. The client SHOULD try using 'simpleEnroll'.
All other return codes are handled as specified in Section 5.2 or HTTP [RFC2616].
"CMC: Transport Protocols" [RFC5273] provides some guidance for running CMC over HTTP but only notes that "clients MAY attempt to send HTTP requests using TLS 1.0 [TLS] or later, although servers are not required to support TLS". No attempt is made to specify how the client and server might take advantage of a secured transport to better leverage the simple the PKI messages. This profile specifies the transport mechanisms and how values from the TLS exchange, the HTTP exchange, and the CMC Simple PKI messages are used for authentication and authorization purposes by the server. HTTPS MUST be used. TLS 'session resumption' SHOULD be supported.
HTTPS is defined in HTTP Over TLS [RFC2818] and is a definition of how HTTP messages may be sent over TLS. HTTPS (HTTP over TLS) is a commonly used transport and can be easily layered on top of extremely simple client or server code and in some environments even by using an external process. Specifying HTTPS as the secured transport for PKI enrollment messages introduces two potential 'layers' for communication of authorization data or for status/informative responses during the protocol exchange:
This profile specifies when information is used from each layer.
Clients MUST request server_auth and servers MUST support server_auth. The client MUST support TLS_RSA_WITH_AES_128_CBC_SHA, and MAY support other cipher-suites such as the suite-B cipher suites indicated in Suite B Profile for Transport Layer Security (TLS) [RFC5430].
[[EDNOTE: To what extent should be specify mandatory cipher suites? TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA or similar such as TLS_SRP_SHA_WITH_AES_128_CBC_SHA would also be interesting. It is worth calling this out? Note that the methods below are defined such that they work with this type of cipher suite.]]
The client validates the HTTPS server certificate presented during the TLS [RFC5246] defined Server Certificate message. There are multiple methods of validation depending on the current state of the client:
If there are any errors the client MUST reject the CA certificate(s) and SHOULD log or inform the end user.
The actual CA certificate MUST NOT be used to protect the TLS tunnel, thus a CA MUST generate separate certificates for server_auth. These are the equivalent of "CMC: Transport Protocols" [RFC5273] Local Registration Authority (LRA) certificates. The EST server MAY be implemented as a "CMC: Transport Protocols" [RFC5273] described LRA, or an implementation specific communication channel MAY be used between the EST server and the CA.
The client MUST support the Root CA Key Update verification mechanisms specified in CMP [RFC4210] section 4.4 when validating TLS server certificates. Appendix Appendix E provides an informative summary of key renewal.
The server certificate MUST either be authorized according to Section 3.1 Server Identity [RFC2818] or via the 'LRA Authorization' Certificate Policy extension OID.
[[EDNOTE: The appropriate OID mechanism is not defined in CMC and will be defined in this document. This is the appropriate location to do so. The HTTP over TLS method will work ok in some use cases but requires an external cert to be issued and used with associated complexity on the client. The OID method is better for clients that will have the root cert distributed to them or where the CaCerts method is used and manually authorized and then an HTTPS connection is established.]]
The server MUST send a TLS [RFC5246] section 7.4.4 "Certificate Request" and the client MUST respond. The client MUST respond with a certificate that allows it to subsequently send the a TLS [RFC5246] Section 7.4.8 "Certificate Verify" (i.e. the client MUST use "a client certificate that has signing capability"). The server MUST verify the Certificate Verify message. The server MUST support TLS_DHE_RSA_WITH_AES_128_CBC_SHA, and SHOULD support other cipher-suites such as the suite-B cipher suites indicated in Suite B Profile for Transport Layer Security (TLS) [RFC5430].
The certificate presented by the client MAY be from the same PKI hierarchy as the Server Certificate, from a completely different PKI hierarchy such as an IEEE 802.1AR IDevID issued by the device manufacturer, or as a last resort the client MAY respond with a self-signed certificate. The certificate supplied during authentication is used during client authorization [ClientAuthorization].
The server MUST support the Root CA Key Update verification mechanisms specified in CMP [RFC4210] section 4.4 when validating TLS client certificates. Appendix Appendix E provides an informative summary on key renewal.
As specified in 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 intended for deployments where password authentication is advantageous MAY support this mechanism. Servers SHOULD provide configurable support.
Servers that support this mechanism reject requests using the HTTP [RFC2616] defined WWW-Authenticate response-header (Section 14.47). At which point the client SHOULD repeat the request, including the appropriate HTTP [RFC2617] Authorization Request Header (Section 3.2.2) as appropriate within the client security settings.
Support for Basic authentication as specified in HTTP [RFC2617] allows the server access to the cleartext password. This provides integration with legacy username password databases but involves distribution of the password. The client MUST NOT respond to this request unless TLS server certificate authentication was fully successful.
[[EDNOTE: the TLS SRP methods MAY be supported and do provide a secure password method.]]
Password based client authentication does not provide renewal/rekey functionality.
When the EST server receives a CMC Simple PKI Enrollment or re-enrollment message it MUST determine authorization before responding. The exact authorization checks are out-of-scope but can proceed as follows:
The server MAY use local policy to determine if the certificate should be issued. The server MAY use any information from TLS or HTTP client authentication to determine appropriate authorization and values for the certificate issued.
If the client certificate is determined to be an RA certificate this can be used to determine appropriate behavior. An RA MUST only forward enrollment requests it has determined to be appropriately authorized. The server MAY still reject the request.
Authentication of protocol peers that have obtained credentials via EST but are communicating using other protocols is out of scope.
The EST server can itself be an EST client. Authentication of credentials identifying an EST peer is in scope such that appropriate generic credential authentication in an environment supporting Root CA Key Update is defined. EST clients validating peer (other EST client) certificates MUST support the Root CA Key Update verification mechanisms specified in CMP [RFC4210] section 4.4 when validating the peer certificates. Appendix Appendix E provides an informative summary on key renewal.
The editor would like to thank Vinod Arjun and others for their consistent feedback and prototypes based on early drafts.
(This section is incomplete)
The following aspects should be registered with IANA Considerations:
[[EDNOTE: The authorization mechanism as discussed in Section 7.2 may require registration with IANA.]]
[[EDNOTE: The URLs specified in Section 2 probably do not need to be registered with IANA.]]
(This section is incomplete)
"Badges? We ain't got no badges. We don't need no badges! I don't have to show you any stinkin' badges!" -- The Treasure of the Sierra Madre.
The proof-of-identity mechanism specified in Authentication and Authorization [AuthCandAuthZ] does not support linking the client identity with the proof-of-possession as described for Full PKI Requests in CMC Section 6.3 [RFC5272]. EST servers effectively trust that the client is presenting an appropriate request without a cryptographic binding between the certificate request and the outer TLS connection. A strong binding between the TLS session and the certificate requests would preclude implementations as described in Appendix Appendix B and Appendix Appendix C or running in an RA mode where the request is authorized and forwarded using the RA's credentials but with the request signature intact. Where a cryptographic binding between the client identity and the proof-of-possession is necessary the full CMC specification MUST be used.
As indicated in CMC Section 6.7 [RFC5272], "For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair". For support of keys that can not be used for signatures the full CMC specification MUST be used.
As indicated in Section 7.3 clients use an existing certificate for TLS client authentication. If a certificate with appropriate key usage is not available the full CMC specification MUST be used. If a self-signed certificate with appropriate key usage is used the server will require HTTP based client authentication according to server policy as described in Section 7.3 and Section 7.5.
(informative)
(This section is incomplete)
Cients MAY use DNS-SD or similar discovery algorithms to determine the EST base URL. In such cases it is expected that method 1 [TLSserverAuthC] be used during server authentication.
(informative)
In some deployments it may be beneficial to use a TLS concentrator to offload the TLS processing from the server. In such a deployment the TLS client authentication result must, in some way, be forwarded to the server.
The TLS server SHOULD NOT reject the connection based on PKIX validation of the client certificate. The client certificate SHOULD be passed to the EST layer for verification and authorization. This allows support of external TLS concentrators, or an external web server, that might provide an independent TLS implementation.
The TLS concentrator MUST validate the TLS [RFC5246] Section 7.4.8 'Certificate Verify'.
A TLS concentrator MUST insert the client certificate into the HTTP header. The TLS concentrator MUST first remove any existing client certificates, possibly inserted by a nefarious client, from the HTTP headers before forwarding the HTTP connection to the server.
[TBD - need to better understand what would happen in the case of proxy's or multiple concentrators. Or specifically state that as out of scope.]
[TBD - the HTTP header field names etc shall be specified here]
The EST server MUST be specifically configured by the administrator to accept this mechanism.
(informative)
In some deployments it may be beneficial to use a HTTPS server that runs the EST server as a CGI application. In such a deployment the HTTPS server client authentication result must, in some way, be forwarded to the server.
An HTTPS server MUST insert the client certificate into environment variables before calling a server CGI application.
[TBD - describe the CGI environment variables here. Can likely follow the apache example].
An HTTP server MUST insert the client certificate into environment variables before calling a server CGI application.
[TBD - describe the CGI environment variables here. Can likely follow the apache example].
(informative)
SCEP has been used instead of a full implementation of CMC for the same simplicity reasons discussed in Section 1. Such implementations would benefit from being updated to this specification in the following ways:
Updating an SCEP client implementation to support this protocol involves the following changes to the SCEP implementation. There is no server side indication that SCEP clients should be so modified so this depends on a client side configuration:
These simplifications to an existing SCEP implementation result in an SCEP client that is compliant with CMC when using the EST transport.
(informative)
(This section is incomplete)
The CMP [RFC4210] section 4.4 defined Root CA Key Update mechanisms are repeated here for easier reference.