Internet Engineering Task Force M. Pritikin, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track March 7, 2011
Expires: September 8, 2011
Enrollment over Secure Transport
draft-pritikin-est-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2011.
Copyright Notice
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
Pritikin Expires September 8, 2011 [Page 1]
Internet-Draft EST March 2011
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Distribution of CA certificates . . . . . . . . . . . . . . . 6
4.1. Distribution of CA certificates response . . . . . . . . . 6
5. Simple Enrollment of Clients . . . . . . . . . . . . . . . . . 7
5.1. Simple Re-Enrollment of Clients . . . . . . . . . . . . . 7
5.2. Simple Enroll and Re-Enroll Response . . . . . . . . . . . 8
6. Full CMC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Full CMC Response . . . . . . . . . . . . . . . . . . . . 9
7. Authentication and Authorization . . . . . . . . . . . . . . . 10
7.1. HTTPS Based Server Authentication . . . . . . . . . . . . 10
7.2. Server Authorization . . . . . . . . . . . . . . . . . . . 12
7.3. HTTPS Based Client Authentication . . . . . . . . . . . . 12
7.4. HTTP Based Client Authentication . . . . . . . . . . . . . 12
7.5. Client Authorization . . . . . . . . . . . . . . . . . . . 13
7.6. Peer Authentication . . . . . . . . . . . . . . . . . . . 14
8. Contributors/Acknowledgements . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Server Discovery . . . . . . . . . . . . . . . . . . 16
Appendix B. External TLS concentrator . . . . . . . . . . . . . . 16
Appendix C. CGI Server implementation . . . . . . . . . . . . . . 17
Appendix D. Updating SCEP implementations . . . . . . . . . . . . 17
Appendix E. Key Update mechanisms . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Pritikin Expires September 8, 2011 [Page 2]
Internet-Draft EST March 2011
1. Introduction
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.]]
Pritikin Expires September 8, 2011 [Page 3]
Internet-Draft EST March 2011
1.1. Requirements Language
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].
2. Overview
This profile reduces certificate enrollment for clients to the
following operations:
o Distribution of CA certificates
o Authorized enrollment and re-enrollment of clients
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.
3. URLs
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:
Pritikin Expires September 8, 2011 [Page 4]
Internet-Draft EST March 2011
o BASEPATH is a common path for all EST operations
o OPERATIONPATH specifies the specific operation.
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 A. Fully formed base URLs are:
o https://example.org/BASEPATH
o https://example.org:8080/arbitrary/base/path
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:
o /CACerts - The server responds to an HTTPS GET with the CA
certificates as defined in Distribution of CA certificates
(Section 4).
o /simpleEnroll - The client sends a CMC Simple PKI Enrollment
message as specified in Enrollment of Clients (Section 5), the
response is a CMC Simple PKI Response message as specified in
Enroll Response (Section 5.2).
o /simpleReEnroll - Exactly the same as 'simpleEnroll' except that
the request is explicitly for re-enrollment purposes.
o /fullCMC - Provides for a CMC transport
Such that the following examples form valid complete URLs:
o https://example.org/BASEPATH/CACerts
o https://example2.org/arbitrary/base/path/simpleEnroll
o https://example2.org/arbitrary/base/path/simpleReEnroll
o https://example3.org/example/ca/fullCMC
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,
Pritikin Expires September 8, 2011 [Page 5]
Internet-Draft EST March 2011
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.]]
4. Distribution of CA certificates
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 (Section 7). 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 (Section 7).
4.1. Distribution of CA certificates response
The server MUST respond with a list of certificates containing the
current CA certificates. This includes any Root CA Key Update
certificates (Appendix E provides an informative summary of key
renewal).
Pritikin Expires September 8, 2011 [Page 6]
Internet-Draft EST March 2011
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.
5. Simple Enrollment of Clients
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 (Section 7). 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.
5.1. Simple Re-Enrollment of Clients
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
Pritikin Expires September 8, 2011 [Page 7]
Internet-Draft EST March 2011
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.
5.2. Simple Enroll and Re-Enroll Response
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
Pritikin Expires September 8, 2011 [Page 8]
Internet-Draft EST March 2011
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].
6. Full CMC
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 (Section 7.1) if an HTTPS url is used.
The server SHOULD authenticate the client as specified in
Authentication and Authorization (Section 7). 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.]]
6.1. Full CMC Response
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.
Pritikin Expires September 8, 2011 [Page 9]
Internet-Draft EST March 2011
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].
7. Authentication and Authorization
"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:
o TLS
o HTTPS
This profile specifies when information is used from each layer.
7.1. HTTPS Based Server Authentication
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
Pritikin Expires September 8, 2011 [Page 10]
Internet-Draft EST March 2011
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:
1. If the client has a store of certificates for validating HTTPS
connections the client MAY validate the HTTPS server certificate
using the standard HTTP logic of checking the server's identity
as presented in the server's Certificate message against the URL
used (see HTTPS Over TLS, Section 3.1 Server Identity [RFC2818].
This method makes it possible for clients with a large store of
HTTPS certificates to securely obtain the CA server certificate
by leveraging the HTTPS security model (see Section 7.2).
2. If the client already has CA root certificate(s) associated with
this EST server the client MAY validate the TLS server
certificate using the previously known CA root certificate(s)
(see Section 7.2 for authorization details).
3. If the client does not yet have CA root certificate(s) associated
with this EST server then the client MAY provisionally accept the
TLS connection but the inner data must be accepted manually as
described in Section 4. The TLS server certificates, including
any root certificates, are discarded.
4. [[EDNOTE: The use of password based cipher suite such as SRP
would be described here. If the client obtains successful
authentication via SRP then the certificates received are
accepted as valid.]]
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 E provides an informative summary of
key renewal.
Pritikin Expires September 8, 2011 [Page 11]
Internet-Draft EST March 2011
7.2. Server Authorization
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.]]
7.3. HTTPS Based Client Authentication
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 (Section 7.5).
The server MUST support the Root CA Key Update verification
mechanisms specified in CMP [RFC4210] section 4.4 when validating TLS
client certificates. Appendix E provides an informative summary on
key renewal.
7.4. HTTP Based Client Authentication
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.
Pritikin Expires September 8, 2011 [Page 12]
Internet-Draft EST March 2011
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.
7.5. Client Authorization
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:
o Verify TLS client Certificate and Certificate Verify messages
o Perform any appropriate policy lookups based on client certificate
o (optionally) Request additional HTTP user authentication
credentials,
o (optionally) Perform additional policy lookups based on user
authentication credentials.
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.
Pritikin Expires September 8, 2011 [Page 13]
Internet-Draft EST March 2011
7.6. Peer Authentication
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 E provides an informative summary on key
renewal.
8. Contributors/Acknowledgements
The editor would like to thank Vinod Arjun and others for their
consistent feedback and prototypes based on early drafts.
9. IANA Considerations
(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.]]
10. Security Considerations
(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 (Section 7) 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
Pritikin Expires September 8, 2011 [Page 14]
Internet-Draft EST March 2011
TLS connection. A strong binding between the TLS session and the
certificate requests would preclude implementations as described in
Appendix B and 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.
11. Normative References
[IDevID] IEEE Std, "IEEE 802.1AR Secure Device Identifier",
December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, March 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
November 2000.
Pritikin Expires September 8, 2011 [Page 15]
Internet-Draft EST March 2011
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, June 2008.
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC): Transport Protocols", RFC 5273, June 2008.
Appendix A. Server Discovery
(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
(Section 7.1) be used during server authentication.
Appendix B. External TLS concentrator
(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
Pritikin Expires September 8, 2011 [Page 16]
Internet-Draft EST March 2011
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.
Appendix C. CGI Server implementation
(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].
Appendix D. Updating SCEP implementations
(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:
o Implementing a subset of CMC [RFC5272] provides an enhancement
path if the full CMC functionality is required.
Pritikin Expires September 8, 2011 [Page 17]
Internet-Draft EST March 2011
o The use of HTTPS as a transport is often percieved as more secure.
Although the SCEP protocol specification includes mechanisms (and
complexity) to address security issues avoiding a vendor
requirement to educate systems administrators is beneficial.
Implementors can benefit from the wide availability of existing
HTTPS/TLS libraries.
o SCEP servers can use their CA certificate to protect SCEP traffic
in ways that are not appropriate. (See SCEP draft Section 8.2).
This specification precludes those misuses.
o The SCEP draft Appendix D renew and re-key functionalities impy a
'flag moment' where the PKI infrastructure transitions from an
(expired) CA certificate to a new CA certificate. This
specification specifies the better mechanism defined in CMP
[RFC4210].
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:
o The SCEP client supports HTTPS server authentication and
authorization as detailed Section 7.1.
o The SCEP client supports HTTPS client authentication as detailed
in Section 7.3.
o When performing the "Get CA Cert" SCEP transaction the client
supports the Section 4 described CMC Simple PKI Response (ref CMC
4.1, which is extremely similar to the SCEP "CA/RA Certificate
Response Message Format" if not exactly the same).
o When performing the certificate enrollment via SCEP PKCSReq the
outgoing message is simplified to be only the inner PKCS10 (ref
CMC section 3.2.1.2.1).
o When handling the certificate enrollment response the response
format is simplified to be only the SCEP inner 'messageData'
containing the actual certificates in the degenerate PKCS7 form.
(ref CMC 4.1) The only 'authenticatedAttributes' value of
remaining importance is the 'pkiStatus' and this value is now
found in the HTTP header as defined in Section 5.2.
o Polling is simplified with clients repeatingly establishing the
full HTTPS connection; no polling specific state information is
encoded into the EST messages.
Pritikin Expires September 8, 2011 [Page 18]
Internet-Draft EST March 2011
o GetCert is deprecated.
o GetCRL is deprecated.
These simplifications to an existing SCEP implementation result in an
SCEP client that is compliant with CMC when using the EST transport.
Appendix E. Key Update mechanisms
(informative)
(This section is incomplete)
The CMP [RFC4210] section 4.4 defined Root CA Key Update mechanisms
are repeated here for easier reference.
Author's Address
Max Pritikin (editor)
Cisco Systems, Inc.
510 McCarthy Drive
Milpitas, CA
USA
Email: pritikin@cisco.com
Pritikin Expires September 8, 2011 [Page 19]