[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-pkix-est

Internet Engineering Task Force                         M. Pritikin, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                            May 13, 2011
Expires: November 14, 2011


                    Enrollment over Secure Transport
                         draft-pritikin-est-01

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 November 14, 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 November 14, 2011               [Page 1]

Internet-Draft                     EST                          May 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  . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Distribution of CA certificates  . . . . . . . . . . . . . . .  8
     5.1.  Distribution of CA certificates response . . . . . . . . .  8
   6.  Simple Enrollment of Clients . . . . . . . . . . . . . . . . .  8
     6.1.  Simple Re-Enrollment of Clients  . . . . . . . . . . . . .  9
     6.2.  Simple Enroll and Re-Enroll Response . . . . . . . . . . . 10
   7.  Full CMC . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Full CMC Response  . . . . . . . . . . . . . . . . . . . . 11
   8.  Transport Authentication and Authorization . . . . . . . . . . 12
     8.1.  HTTPS Based Server Authentication  . . . . . . . . . . . . 12
     8.2.  Server Authorization . . . . . . . . . . . . . . . . . . . 13
     8.3.  HTTPS Based Client Authentication  . . . . . . . . . . . . 14
     8.4.  HTTP Based Client Authentication . . . . . . . . . . . . . 14
     8.5.  Client Authorization . . . . . . . . . . . . . . . . . . . 15
     8.6.  Proof-of-Possession  . . . . . . . . . . . . . . . . . . . 15
     8.7.  Peer Authentication  . . . . . . . . . . . . . . . . . . . 16
   9.  Contributors/Acknowledgements  . . . . . . . . . . . . . . . . 17
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Server Discovery  . . . . . . . . . . . . . . . . . . 19
   Appendix B.  External TLS concentrator . . . . . . . . . . . . . . 19
   Appendix C.  CGI Server implementation . . . . . . . . . . . . . . 20
   Appendix D.  Updating SCEP implementations . . . . . . . . . . . . 21
   Appendix E.  Key Update mechanisms . . . . . . . . . . . . . . . . 22
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22









Pritikin                Expires November 14, 2011               [Page 2]

Internet-Draft                     EST                          May 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].

   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.]]

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].





Pritikin                Expires November 14, 2011               [Page 3]

Internet-Draft                     EST                          May 2011


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.  Requirements

   [[EDNOTE: The following section is included here for succinctness.
   It is possible this section will move to an Informational RFC or be
   dropped entirely.]]

   The following describes goals and technical requirements for initial
   PKI certificate enrollment.

   G1 "Completeness".  Implementations compliant with this memo MUST be
      able to interoperate without reference to subsequent profiles or
      additional future specifications.

   NOTE: Requirement statements indicated within parentheticals such as
   "(A6)" are included for completeness and clarity but are not



Pritikin                Expires November 14, 2011               [Page 4]

Internet-Draft                     EST                          May 2011


   requirements.  [[EDNOTE: They are included to highlight their absense
   and engender debate during early drafts.]]

   The goal of this enrollment protocol is to provide a simple and
   ubiquitous method for End-Entities to request, obtain and update a
   certificate issued from a specified Certification Authority.  The
   following certificate management operations are required.  Additional
   operations SHOULD NOT be supported although the protocol design
   SHOULD support extensibility for future work:

   M1 "Distribution of current CA credentials".  Clients MUST be able to
      obtain current PKI hierarchy credentials.

   M2 "Enrollment".  Client MUST be able to use the protocol to submit a
      request and obtain an issued certificate.

   M3 "Renew/Rekey".  Clients MUST be able to use the protocol for
      certificate renewal or rekey operations.

   End-Entity Proof of Identity authentication mechanisms:

   A1 "Username/Password".  It MUST be possible to identify a username
      specified client as being in possession of an associated symmetric
      key.

   A2 "Password".  It MUST be possible to identity the client as being
      in possession of a symmetric key that is not associated with a
      "username".

   A3 "Existing Certificate".  It MUST be possible to identity the
      client by leveraging an existing certificate.  It MUST NOT be
      assumed that the client certificate is from the same PKI
      hierarchy.

   A4 "Username/password and Certificate".  It MUST be possible to
      identity the client by using a combination of a username/password
      and an existing certificate.  This is a combination of A1 and A3.

   A5 "Password and certificate".  It MUST be possible to identity the
      client by using a combination of a symmetric key that is not
      associated with a "username" and an existing certificate.  This is
      a combination of A2 and A3.

   (A6)  "A username/password and a password".  (It is NOT a requirement
      to be able to identity a client by username/password and by
      possession of an additional password.  This would be a combination
      of A1 and A2)




Pritikin                Expires November 14, 2011               [Page 5]

Internet-Draft                     EST                          May 2011


   End-Entity Proof of Possession:

   P1 Proof-of-Possession of subject keys MUST be supported.

   Key algorithms:

   K1 "Algorithm agility".  All protocol aspects MUST support algorithm
      agility.

   K2 "Suite-B".  The protocol MUST provide for suite-b compatibility.
      (This is a sub-requirement of K1).

   Server Identity mechanism:

   I1 "PKI hierarchy issued certificate".  It MUST be possible to
      identify the server by verifying a certificate issued by the PKI
      hierarchy.

   I2 "Common hierarchy issued certificate".  It MUST be possible to
      identity the server by verifying a certificate from a common
      (mutually trusted) hierarchy.

   I3 "Server authorization."  It MUST be possible to verify the
      server's authorization to act as the EST server.


4.  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:

   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.  The following are two example base URLs:

   o  https://example.org/BASEPATH

   o  https://example.org:8080/arbitrary/base/path




Pritikin                Expires November 14, 2011               [Page 6]

Internet-Draft                     EST                          May 2011


   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 5).

   o  /simpleEnroll - The client sends a CMC Simple PKI Enrollment
      message as specified in Enrollment of Clients (Section 6), the
      response is a CMC Simple PKI Response. message as specified in
      Enroll Response (Section 6.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 (optional).

   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.

   Implementation note: A simple Common Gateway Interface (CGI)
   application at each fully specified path, configured with appropriate
   permissions as per the HTTPS server configuration, is sufficient for
   a working example (the web service can forward the Section 8.6 proof-
   of-possession information to the application).

   [[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.]]





Pritikin                Expires November 14, 2011               [Page 7]

Internet-Draft                     EST                          May 2011


5.  Distribution of CA certificates

   Before engaging in enrollment operations clients MUST 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'.
   Clients SHOULD request an up to date list before existing
   certificates have expired.

   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 8).  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).

   The client SHOULD NOT accept the CA root certificate automatically.

   Subsequent connections to the EST server validate the TLS server
   certificate using the stored CA root certificates as described in
   Authentication and Authorization (Section 8).

5.1.  Distribution of CA certificates response

   The server MUST respond with a list of certificates containing the
   current CA certificates.  This MUST include any Root CA Key Update
   certificates (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.


6.  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]



Pritikin                Expires November 14, 2011               [Page 8]

Internet-Draft                     EST                          May 2011


   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
   certification requests, or MAY be ecdsa-with-sha384 for P-384
   certification 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 8).  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 8.1.

6.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
   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.







Pritikin                Expires November 14, 2011               [Page 9]

Internet-Draft                     EST                          May 2011


6.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].  The issued certificate MAY be signed by a
   new CA key established as described in CMP [RFC4210].

   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].







Pritikin                Expires November 14, 2011              [Page 10]

Internet-Draft                     EST                          May 2011


7.  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 8.1) if an HTTPS url is used.

   The server SHOULD authenticate the client as specified in
   Authentication and Authorization (Section 8).  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.]]

7.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.

   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 6.2 or
   HTTP [RFC2616].



Pritikin                Expires November 14, 2011              [Page 11]

Internet-Draft                     EST                          May 2011


8.  Transport 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.

8.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 SHOULD support other cipher-suites such as the suite-B cipher
   suites indicated in Suite B Profile for Transport Layer Security
   (TLS) [RFC5430].

   [[EDNOTE: 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 but these
   are 'informational' from RFC5054 and won't be referenced here.  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:





Pritikin                Expires November 14, 2011              [Page 12]

Internet-Draft                     EST                          May 2011


   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.  The EST server URL MUST
       be securely specified to the client.

   2.  If the client already has CA root certificate(s) associated with
       this EST server the client MAY validate the EST server
       certificate using the previously known CA root certificate(s).  A
       discovery mechanism such as DNS-SD (or otherwise) MAY be used to
       determine the EST server URI.

   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 5.  The certificate chain distributed during
       the TLS handshake is discarded.  HTTP authentication requests
       MUST NOT be responded to until after manual authentication
       occurs.

   4.  [[EDNOTE: The use of password based cipher suite such as TLS-PSK
       would be described here.  If the client obtains successful
       authentication via TLS-PSK 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 the EST server.
   These are the similar to "CMC: Transport Protocols" [RFC5273] Local
   Registration Authority (LRA) certificates.

   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.

8.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.




Pritikin                Expires November 14, 2011              [Page 13]

Internet-Draft                     EST                          May 2011


   If the 'LRA Authorization' Certificate Policy extension is in the
   server certificate

   [[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 HTTPS method requires the EST server to be issued a
   certificate with the appropriate subjectname.  The OID method is
   useful for clients where DNS is unavailable or where server IP
   address might dynamically change.]]

8.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 8.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.

8.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 the Basic and Digest authentication
   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.



Pritikin                Expires November 14, 2011              [Page 14]

Internet-Draft                     EST                          May 2011


   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 Section 8.2 was fully successful.

   Clients MAY set the username to the empty string ("") if they wish to
   present a "one time password" or "PIN" that is not associated with a
   username.

   Password based client authentication does not provide renewal/rekey
   functionality.

8.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.

8.6.  Proof-of-Possession

   As discussed in Appendix C of RFC4211 Proof-of-Possession "means that
   the CA is adequately convinced that the entity requesting a
   certificate for the public key Y, has access to the corresponding
   private key X".  This can be an important security consideration for
   servers.




Pritikin                Expires November 14, 2011              [Page 15]

Internet-Draft                     EST                          May 2011


   This specification provides proof-of-possession by binding the
   certification request to the client_authenticated TLS session by
   using a method very similar to tls-unique defined in [RFC5929].  The
   binding method defined here is:

      tls-unique-securerenegotiation: The first TLS Finished message
      sent in the _first_ TLS handshake of the TLS connection being
      bound to.  Any TLS renegotiation MUST use "secure_renegotiation"
      [RFC5746] (thus maintaining the binding).  Mandating secure
      renegotiation allows implementations to avoid the synchronization
      issues encountered with tls-unique.

   The client generating the request MUST obtain the tls-unique-
   securerenegotation value, encode it using base64 encoding, and place
   the resulting string in the certification request challenge password
   field.  The server MUST verify the tls-unique-securerenegotation
   information and uses the verification result as an input to policy
   decisions.

   The tls-unique-securerenegotiation value is encoded into the
   certification request by the client but back-end infrastructure
   elements which process the request might not have access to the
   initial TLS session.  For example the existing client certificate
   might have been issued to an RA which is known to independently
   verify the proof-of-possession, or the HTTP Client Authentication
   authorization checks might have authorized granting despite a failed
   proof-of-possession check.  The server policy decision MAY be to
   grant the certification request even when proof-of-possession checks
   fail.

   Implementation Note: This is distinct from channel binding as
   specified in [RFC5746].  As an implementation concern the tls-unique
   value is consistent with this definition until a subsequent
   renegotiation (at which point the tls-unique value is the TLS
   Finished message of the "most recent TLS handshake" instead of the
   first handshake).  The tls-unique-securerenegotiation value can thus
   be obtained by careful use of the implementation's tls-unique channel
   binding TLS APIs so long as renegotiation has not yet taken place.
   The definition of tls-unique-securerenegotiation makes it possible
   for servers to wait to request TLS client authentication until after
   the URI has been parsed, as is commonly implemented, and yet still
   use the existing tls-unique APIs that might be available to them.

8.7.  Peer Authentication

   Authentication of protocol peers that have obtained credentials via
   EST but are communicating using other protocols is out of scope.




Pritikin                Expires November 14, 2011              [Page 16]

Internet-Draft                     EST                          May 2011


   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.


9.  Contributors/Acknowledgements

   The editor would like to thank Vinod Arjun, Jan Vilhuber and others
   for their consistent feedback and prototypes based on early drafts.


10.  IANA Considerations

   (This section is incomplete)

   The following aspects should be registered with IANA Considerations:

   [[EDNOTE: The authorization mechanism as discussed in Section 8.2 may
   require registration with IANA.]]

   [[EDNOTE: The URLs specified in Section 2 probably do not need to be
   registered with IANA.]]


11.  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.

   As described 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".  The inclusion of tls-unique-
   securerenegotiation within the certification request provides
   timeliness to the proof-of-possession.  For support of keys that can
   not be used for signing the certification request the full CMC
   specification MUST be used.

   As described in Section 8.3 clients use an existing certificate for
   TLS client authentication.  If a certificate with appropriate key
   usage is not available the client MAY generate one.  If a self-signed



Pritikin                Expires November 14, 2011              [Page 17]

Internet-Draft                     EST                          May 2011


   certificate with appropriate key usage is used the server SHOULD
   require HTTP based client authentication according to server policy
   as described in Section 8.3 and Section 8.5.  The server MAY fall
   back on manual authorization by the server administrator.

   As described in Section 8.1 servers use an existing certificate for
   TLS server authentication.  When the server certificate is issued by
   a mutually trusted PKI hierarchy validation proceeds as specified in
   Section 8.2.  In this situation the client has validated the server
   as being a valid responder for the URI configured but can not
   directly verify that the responder is authorized as an RA within the
   to-be-enrolled PKI hierarchy.  A client may thus be enticed to expose
   username/password or certificate enrollment requests to an
   unauthorized server (if the server presents a valid HTTPS certificate
   for an erroneous URL that the client has been tricked into using).
   Proof-of-Identity and Proof-of-Possession checks prevent an
   illegitimate RA from leveraging such misconfigured clients to act as
   a man-in-the-middle during client authenticated operations but it is
   possible for such illegitimate RAs to respond with doctored messages
   or erroneous CA certificate lists.  If the illegitimate RA has
   successfully phished a username/password or PIN from the client it
   might try to use these values to enroll its own keypair with the real
   PKI hierarchy.  EST servers identified with an externally issued
   server certificate SHOULD require HTTPS based client authentication
   (Section 8.3).


12.  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.




Pritikin                Expires November 14, 2011              [Page 18]

Internet-Draft                     EST                          May 2011


   [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.

   [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.

   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
              "Transport Layer Security (TLS) Renegotiation Indication
              Extension", RFC 5746, February 2010.

   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
              for TLS", RFC 5929, July 2010.


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 2
   (Section 8.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



Pritikin                Expires November 14, 2011              [Page 19]

Internet-Draft                     EST                          May 2011


   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.


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].





Pritikin                Expires November 14, 2011              [Page 20]

Internet-Draft                     EST                          May 2011


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.

   o  The use of HTTPS as a transport is often perceived 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 8.1.

   o  The SCEP client supports HTTPS client authentication as detailed
      in Section 8.3.

   o  When performing the "Get CA Cert" SCEP transaction the client
      supports the Section 5 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).



Pritikin                Expires November 14, 2011              [Page 21]

Internet-Draft                     EST                          May 2011


   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 6.2.

   o  Polling is simplified with clients repeatingly establishing the
      full HTTPS connection; no polling specific state information is
      encoded into the EST messages.

   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.

   Implementation note: The use of tls-unique-securerenegotiation
   precludes the use of SCEP 'challenge-password' within the pkcs10 for
   password/PIN assertion.  Instead these values must be asserted with
   the Section 8.4 described mechanism.  A side effect of this is that a
   client communicating with an EST server can not embed an SCEP
   'challenge-password' within the PKCS#10.  An EST service running as
   an RA thus can not forward the PKCS#10 using SCEP to an SCEP server
   that expects the 'challenge-password' to be populated.


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 November 14, 2011              [Page 22]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/