One document matched: draft-pritikin-est-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2315.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
<!ENTITY RFC2986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.xml">
<!ENTITY RFC4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY RFC4306 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml">
<!ENTITY RFC4210 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4210.xml">
<!ENTITY RFC4945 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4945.xml">
<!ENTITY RFC5272 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5272.xml">
<!ENTITY RFC2409 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2409.xml">
<!ENTITY RFC5273 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5273.xml">
<!ENTITY RFC2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-pritikin-est-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="EST">Enrollment over Secure Transport</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Max Pritikin" initials="M" role="editor"
surname="Pritikin">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>510 McCarthy Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Milpitas</city>
<region>CA</region>
<code></code>
<country>USA</country>
</postal>
<email>pritikin@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="March" year="2011" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Security</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>pki</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>This specification profiles the use of <xref
target="RFC5272">Certificate Management over CMS</xref> "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.</t>
<t>A full implementation of all <xref target="RFC5272">CMC</xref>
features is not required to be compliant with this specification. This
is consistent with the <xref target="RFC5272">CMC</xref> protocol
specification of "simple" messages for clients to use "in the event no
other services are needed". When using these messages <xref
target="RFC5272">CMC</xref> 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.</t>
<t>Advanced clients, or components of the PKI hierarchy itself, will
possibly require a complete implementation of the <xref
target="RFC5272">CMC</xref> specification or additional specifications.
This document provides an appropriate transport for the full <xref
target="RFC5272">CMC</xref> specification that is compliant with <xref
target="RFC5273"></xref>.</t>
<t>Servers SHOULD implement the full <xref target="RFC5272">CMC</xref>
functionality. Clients MAY limit their implementation to the abbreviated
functionalities described in this document.</t>
<t>Additionally <xref target="RFC5272">CMC</xref> 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 <xref
target="RFC4210">CMP</xref>.</t>
<t>[[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.]]</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section anchor="overview" title="Overview">
<t>This profile reduces certificate enrollment for clients to the
following operations:</t>
<t><list style="symbols">
<t>Distribution of CA certificates</t>
<t>Authorized enrollment and re-enrollment of clients</t>
</list>These functions are provided by methods at a specified HTTPS
URL.</t>
<t>Some messages formats are defined in <xref
target="RFC5272">CMC</xref> and include subsets of the <xref
target="RFC2986">PKCS#10 Certification Request</xref> and the <xref
target="RFC2315">PKCS#7</xref> message specifications. Additional simple
message formats are defined. </t>
<t>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 <xref
target="IDevID">IEEE 802.1AR IDevID</xref> 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.</t>
<t>HTTP Content-Type headers are as specified in <xref
target="RFC5273">CMC: Transport Protocols</xref>, Table 1. This document
introduces new content types for the simple format messages not
specified by <xref target="RFC5272">CMC</xref>.</t>
<t>The HTTP server MAY provide non-EST services on other URLs. The
server MAY handle full CMC messages over HTTP.</t>
</section>
<section title="URLs">
<t>EST uses the HTTP "GET" and "POST" messages to communicate with the
CA. The following describes the syntax of these messages:</t>
<figure title="">
<artwork><![CDATA["GET" BASEPATH OPERATIONPATH
"POST" BASEPATH OPERATIONPATH]]></artwork>
</figure>
<t>where:</t>
<t><list style="symbols">
<t>BASEPATH is a common path for all EST operations</t>
<t>OPERATIONPATH specifies the specific operation.</t>
</list></t>
<t>When an URL is formed the BASEPATH and OPERATIONPATH are combined to
form the <xref target="RFC2616"></xref> abs_path. The server and port
and MUST be pre-configured or otherwise discovered by the client as
described in <xref target="discovery"></xref>. Fully formed base URLs
are:</t>
<t><list style="symbols">
<t>https://example.org/BASEPATH</t>
<t>https://example.org:8080/arbitrary/base/path</t>
</list></t>
<t>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:</t>
<t><list style="symbols">
<t>/CACerts - The server responds to an HTTPS GET with the CA
certificates as defined in <xref target="CACerts">Distribution of CA
certificates</xref>.</t>
<t>/simpleEnroll - The client sends a CMC Simple PKI Enrollment
message as specified in <xref target="Enroll">Enrollment of
Clients</xref>, the response is a CMC Simple PKI Response message as
specified in <xref target="EnrollResponse">Enroll
Response</xref>.</t>
<t>/simpleReEnroll - Exactly the same as 'simpleEnroll' except that
the request is explicitly for re-enrollment purposes.</t>
<t>/fullCMC - Provides for a CMC transport</t>
</list></t>
<t>Such that the following examples form valid complete URLs:<list
style="symbols">
<t>https://example.org/BASEPATH/CACerts</t>
<t>https://example2.org/arbitrary/base/path/simpleEnroll</t>
<t>https://example2.org/arbitrary/base/path/simpleReEnroll</t>
<t>https://example3.org/example/ca/fullCMC</t>
</list>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.</t>
<t>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.</t>
<t>[[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.]]</t>
</section>
<section anchor="CACerts" title="Distribution of CA certificates">
<t>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'.</t>
<t>The server SHOULD NOT require client authentication or authorization
to service this request.</t>
<t>The client MUST authenticate the server as specified in <xref
target="AuthCandAuthZ">Authentication and Authorization</xref>. 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).</t>
<t>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.</t>
<t>Subsequent connections to the EST server validate the TLS server
certificate using the stored CA root certificates as described in <xref
target="AuthCandAuthZ">Authentication and Authorization</xref>.</t>
<section title="Distribution of CA certificates response">
<t>The server MUST respond with a list of certificates containing the
current CA certificates. This includes any Root CA Key Update
certificates (<xref target="keyupdatemechanisms"></xref> provides an
informative summary of key renewal).</t>
<t>The response format is a text file containing a list of
certificates each formatted as specified in <xref
target="RFC4945">Section 6.1 of</xref>. Each certificate is delimited
by a newline. The content-type of "application/x-est-cacerts" MUST be
specified.</t>
</section>
</section>
<section anchor="Enroll" title="Simple Enrollment of Clients">
<t>At any time the client MAY request a certificate from the EST base
URL with the relative path extension "simpleEnroll'.</t>
<t>When HTTPS POSTing to the 'Enroll' location the client MUST include a
CMC Simple PKI Enrollment request as specified in <xref
target="RFC5272">CMC</xref> Section 3.1 (a <xref
target="RFC2986">PKCS#10 Certification Request</xref>.). The
content-type of "application/x-est-pkcs10" MUST be specified. The format
of the request is as specified in <xref target="RFC4945">Section 6.4 of
</xref>.</t>
<t>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.</t>
<t>[[EDNOTE: This is in alignment with draft-turner-suitb-cmc-03 section
4.1]]</t>
<t>The server MUST authenticate the client as specified in <xref
target="AuthCandAuthZ">Authentication and Authorization</xref>. 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 <xref
target="RFC5272">CMC</xref> Section 3.1.</t>
<t>The client MUST authenticate the server as specified in <xref
target="TLSserverAuthC"></xref>.</t>
<section title="Simple Re-Enrollment of Clients">
<t>At any time the client MAY request a re-enrollment certificate from
the EST base URL with the relative path extension
"simpleReEnroll'.</t>
<t>The server MUST treat the enrollment as a re-enrollment request. As
specified in <xref target="RFC5272">CMC</xref> 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.</t>
<t>[[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.]]</t>
<t>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.</t>
<t>The server MAY revoke the existing certificate once a replacement
has been issued.</t>
</section>
<section anchor="EnrollResponse"
title="Simple Enroll and Re-Enroll Response">
<t>The server responds with the client's newly issued certificate or
provides an error response for either 'simpleEnroll' or
'simpleReEnroll'.</t>
<t>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 <xref
target="RFC4945">Section 6.1 of</xref>.</t>
<t>When rejecting a request the server MUST specify either an <xref
target="RFC2616">HTTP</xref> 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.</t>
<t>If the server responds with an <xref target="RFC2616">HTTP</xref>
501 this indicates that the attempted EST mechanisms is not
implemented. The client SHOULD try using 'fullCMC'.</t>
<t>If the server responds with an <xref target="RFC2616">HTTP</xref>
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).</t>
<t>[[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.]]</t>
<t>All other return codes are handled as specified in <xref
target="RFC2616">HTTP</xref>.</t>
</section>
</section>
<section title="Full CMC ">
<t>At any time the client MAY request a certificate from the EST base
URL with the relative path extension "fullCMC".</t>
<t>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 <xref target="RFC5273">CMC:
Transport Protocols</xref>.</t>
<t>The client MUST authenticate the server as specified in <xref
target="TLSserverAuthC">Server Authentication</xref> if an HTTPS url is
used.</t>
<t>The server SHOULD authenticate the client as specified in <xref
target="AuthCandAuthZ">Authentication and Authorization</xref>. 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 <xref
target="RFC5272">CMC</xref> 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.</t>
<t>[[EDNOTE: text detailing which and how the TLS session key is used to
do this will be specified here.]]</t>
<section title="Full CMC Response">
<t>The server responds with the client's newly issued certificate or
provides an error response.</t>
<t>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 <xref target="RFC5273">CMC: Transport
Protocols</xref>. The response data includes either the CMC Simple PKI
Response or the CMC Full PKI Response.</t>
<t>When rejecting a request the server MAY specify either an <xref
target="RFC2616">HTTP</xref> 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.</t>
<t>If the server responds with an <xref target="RFC2616">HTTP</xref>
501 this indicates that the attempted EST mechanisms is not
implemented. The client SHOULD try using 'simpleEnroll'.</t>
<t>All other return codes are handled as specified in <xref
target="EnrollResponse"></xref> or <xref
target="RFC2616">HTTP</xref>.</t>
</section>
</section>
<section anchor="AuthCandAuthZ" title="Authentication and Authorization">
<t><xref target="RFC5273">"CMC: Transport Protocols"</xref> 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.</t>
<t>HTTPS is defined in <xref target="RFC2818">HTTP Over TLS</xref> 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:<list style="symbols">
<t>TLS</t>
<t>HTTPS</t>
</list></t>
<t>This profile specifies when information is used from each layer.</t>
<section anchor="TLSserverAuthC"
title="HTTPS Based Server Authentication">
<t>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].</t>
<t>[[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.]]</t>
<t>The client validates the HTTPS server certificate presented during
the <xref target="RFC5246">TLS</xref> defined Server Certificate
message. There are multiple methods of validation depending on the
current state of the client:</t>
<t><list style="numbers">
<t>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 <xref target="RFC2818">HTTPS Over TLS, Section 3.1 Server
Identity</xref>. 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 <xref
target="TLSserverAuthZ"></xref>).</t>
<t>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
<xref target="TLSserverAuthZ"></xref> for authorization
details).</t>
<t>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 <xref target="CACerts"></xref>. The TLS
server certificates, including any root certificates, are
discarded.</t>
<t>[[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.]]</t>
</list></t>
<t>If there are any errors the client MUST reject the CA
certificate(s) and SHOULD log or inform the end user.</t>
<t>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 <xref target="RFC5273">"CMC: Transport
Protocols"</xref> Local Registration Authority (LRA) certificates. The
EST server MAY be implemented as a <xref target="RFC5273">"CMC:
Transport Protocols"</xref> described LRA, or an implementation
specific communication channel MAY be used between the EST server and
the CA.</t>
<t>The client MUST support the Root CA Key Update verification
mechanisms specified in <xref target="RFC4210">CMP</xref> section 4.4
when validating TLS server certificates. <xref
target="keyupdatemechanisms"></xref> provides an informative summary
of key renewal.</t>
</section>
<section anchor="TLSserverAuthZ" title="Server Authorization">
<t>The server certificate MUST either be authorized according to <xref
target="RFC2818">Section 3.1 Server Identity</xref> or via the 'LRA
Authorization' Certificate Policy extension OID.</t>
<t>[[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.]]</t>
</section>
<section anchor="TLSclientAuthC"
title="HTTPS Based Client Authentication">
<t>The server MUST send a <xref target="RFC5246">TLS</xref> 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 <xref target="RFC5246">TLS</xref> 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].</t>
<t>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 <xref
target="ClientAuthorization">client authorization</xref>.</t>
<t>The server MUST support the Root CA Key Update verification
mechanisms specified in <xref target="RFC4210">CMP</xref> section 4.4
when validating TLS client certificates. <xref
target="keyupdatemechanisms"></xref> provides an informative summary
on key renewal.</t>
</section>
<section anchor="HTTPuserAuthCandAuthZ"
title="HTTP Based Client Authentication">
<t>As specified in <xref target="RFC5273">CMC: Transport
Protocols</xref> 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.</t>
<t>Servers that support this mechanism reject requests using the <xref
target="RFC2616">HTTP</xref> defined WWW-Authenticate response-header
(Section 14.47). At which point the client SHOULD repeat the request,
including the appropriate <xref target="RFC2617"> HTTP</xref>
Authorization Request Header (Section 3.2.2) as appropriate within the
client security settings.</t>
<t>Support for Basic authentication as specified in <xref
target="RFC2617">HTTP</xref> 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.</t>
<t>[[EDNOTE: the TLS SRP methods MAY be supported and do provide a
secure password method.]]</t>
<t>Password based client authentication does not provide renewal/rekey
functionality.</t>
</section>
<section anchor="ClientAuthorization" title="Client Authorization">
<t>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:</t>
<t><list style="symbols">
<t>Verify TLS client Certificate and Certificate Verify
messages</t>
<t>Perform any appropriate policy lookups based on client
certificate</t>
<t>(optionally) Request additional HTTP user authentication
credentials,</t>
<t>(optionally) Perform additional policy lookups based on user
authentication credentials.</t>
</list>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.</t>
<t>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.</t>
</section>
<section title="Peer Authentication">
<t>Authentication of protocol peers that have obtained credentials via
EST but are communicating using other protocols is out of scope.</t>
<t>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 <xref target="RFC4210">CMP</xref> section 4.4
when validating the peer certificates. <xref
target="keyupdatemechanisms"></xref> provides an informative summary
on key renewal.</t>
</section>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section title="Contributors/Acknowledgements ">
<t>The editor would like to thank Vinod Arjun and others for their
consistent feedback and prototypes based on early drafts. </t>
</section>
<section title="IANA Considerations">
<t>(This section is incomplete)</t>
<t>The following aspects should be registered with IANA
Considerations:</t>
<t>[[EDNOTE: The authorization mechanism as discussed in <xref
target="TLSserverAuthZ"></xref> may require registration with
IANA.]]</t>
<t>[[EDNOTE: The URLs specified in <xref target="overview"></xref>
probably do not need to be registered with IANA.]]</t>
</section>
<section anchor="SecurityConsiderations" title="Security Considerations">
<t>(This section is incomplete)</t>
<t>"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.</t>
<t>The proof-of-identity mechanism specified in <xref
target="AuthCandAuthZ">Authentication and Authorization</xref> does not
support linking the client identity with the proof-of-possession as
described for Full PKI Requests in <xref target="RFC5272">CMC Section
6.3</xref>. 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 <xref
target="externalconcentrator"></xref> and <xref
target="cgiserver"></xref> 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.</t>
<t>As indicated in <xref target="RFC5272">CMC Section 6.7</xref>, "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.</t>
<t>As indicated in <xref target="TLSclientAuthC"></xref> 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 <xref target="TLSclientAuthC"></xref>
and <xref target="ClientAuthorization"></xref>.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC2119;
&RFC2315;
&RFC2616;
&RFC2617;
&RFC2986;
&RFC4210;
&RFC4945;
&RFC5272;
&RFC5273;
&RFC2818;
&RFC5246;
<reference anchor="IDevID"
target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
<front>
<title>IEEE 802.1AR Secure Device Identifier</title>
<author fullname="" surname="IEEE Std">
<organization abbrev="W3C TAG">IEEE</organization>
</author>
<date day="10" month="December" year="2009" />
</front>
</reference>
</references>
<!-- references title="Informative References">
</references -->
<section anchor="discovery" title="Server Discovery">
<t>(informative)</t>
<t>(This section is incomplete)</t>
<t>Cients MAY use DNS-SD or similar discovery algorithms to determine
the EST base URL. In such cases it is expected that <xref
target="TLSserverAuthC">method 1</xref> be used during server
authentication.</t>
</section>
<section anchor="externalconcentrator" title="External TLS concentrator">
<t>(informative)</t>
<t>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.</t>
<t>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.</t>
<t>The TLS concentrator MUST validate the <xref
target="RFC5246">TLS</xref> Section 7.4.8 'Certificate Verify'.</t>
<t>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.</t>
<t>[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.]</t>
<t>[TBD - the HTTP header field names etc shall be specified here]</t>
<t>The EST server MUST be specifically configured by the administrator
to accept this mechanism.</t>
</section>
<section anchor="cgiserver" title="CGI Server implementation">
<t>(informative)</t>
<t>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.</t>
<t>An HTTPS server MUST insert the client certificate into environment
variables before calling a server CGI application.</t>
<t>[TBD - describe the CGI environment variables here. Can likely follow
the apache example].</t>
<t>An HTTP server MUST insert the client certificate into environment
variables before calling a server CGI application.</t>
<t>[TBD - describe the CGI environment variables here. Can likely follow
the apache example].</t>
</section>
<section title="Updating SCEP implementations">
<t>(informative)</t>
<t>SCEP has been used instead of a full implementation of CMC for the
same simplicity reasons discussed in <xref
target="introduction"></xref>. Such implementations would benefit from
being updated to this specification in the following ways:<list
style="symbols">
<t>Implementing a subset of <xref target="RFC5272">CMC</xref>
provides an enhancement path if the full CMC functionality is
required.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref
target="RFC4210">CMP</xref>.</t>
</list>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:</t>
<t><list style="symbols">
<t>The SCEP client supports HTTPS server authentication and
authorization as detailed <xref target="TLSserverAuthC"></xref>.</t>
<t>The SCEP client supports HTTPS client authentication as detailed
in <xref target="TLSclientAuthC"></xref>.</t>
<t>When performing the "Get CA Cert" SCEP transaction the client
supports the <xref target="CACerts"></xref> 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).</t>
<t>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).</t>
<t>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 <xref target="EnrollResponse"></xref>.</t>
<t>Polling is simplified with clients repeatingly establishing the
full HTTPS connection; no polling specific state information is
encoded into the EST messages.</t>
<t>GetCert is deprecated.</t>
<t>GetCRL is deprecated.</t>
</list>These simplifications to an existing SCEP implementation result
in an SCEP client that is compliant with CMC when using the EST
transport.</t>
</section>
<section anchor="keyupdatemechanisms" title="Key Update mechanisms">
<t>(informative)</t>
<t>(This section is incomplete)</t>
<t>The <xref target="RFC4210">CMP</xref> section 4.4 defined Root CA Key
Update mechanisms are repeated here for easier reference.</t>
</section>
<!--
v00 2009-04-13 MCP Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:44:49 |