tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7030

 Errata 
Proposed STD
Pages: 53
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: PKIX

Enrollment over Secure Transport

Part 1 of 4, p. 1 to 9
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                  M. Pritikin, Ed.
Request for Comments: 7030                           Cisco Systems, Inc.
Category: Standards Track                                    P. Yee, Ed.
ISSN: 2070-1721                                             AKAYLA, Inc.
                                                         D. Harkins, Ed.
                                                          Aruba Networks
                                                            October 2013


                    Enrollment over Secure Transport

Abstract

   This document profiles certificate enrollment for clients using
   Certificate Management over CMS (CMC) messages over a secure
   transport.  This profile, called Enrollment over Secure Transport
   (EST), describes a simple, yet functional, certificate management
   protocol targeting Public Key Infrastructure (PKI) clients that need
   to acquire client certificates and associated Certification Authority
   (CA) certificates.  It also supports client-generated public/private
   key pairs as well as key pairs generated by the CA.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7030.

Page 2 
Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
   2. Operational Scenario Overviews ..................................5
      2.1. Obtaining CA Certificates ..................................6
      2.2. Initial Enrollment .........................................7
           2.2.1. Certificate TLS Authentication ......................8
           2.2.2. Certificate-Less TLS Authentication .................8
           2.2.3. HTTP-Based Client Authentication ....................8
      2.3. Client Certificate Reissuance ..............................8
      2.4. Server Key Generation ......................................9
      2.5. Full PKI Request Messages ..................................9
      2.6. Certificate Signing Request (CSR) Attributes Request .......9
   3. Protocol Design and Layering ...................................10
      3.1. Application Layer .........................................13
      3.2. HTTP Layer ................................................14
           3.2.1. HTTP Headers for Control ...........................15
           3.2.2. HTTP URIs for Control ..............................16
           3.2.3. HTTP-Based Client Authentication ...................17
           3.2.4. Message Types ......................................19
      3.3. TLS Layer .................................................20
           3.3.1. TLS-Based Server Authentication ....................20
           3.3.2. TLS-Based Client Authentication ....................21
           3.3.3. Certificate-Less TLS Mutual Authentication .........21
      3.4. Proof-of-Possession .......................................22
      3.5. Linking Identity and POP Information ......................22
      3.6. Server Authorization ......................................23
           3.6.1. Client Use of Explicit TA Database .................24
           3.6.2. Client Use of Implicit TA Database .................24
      3.7. Client Authorization ......................................24
   4. Protocol Exchange Details ......................................25
      4.1. Distribution of CA Certificates ...........................25

Top      ToC       Page 3 
           4.1.1. Bootstrap Distribution of CA Certificates ..........25
           4.1.2. CA Certificates Request ............................26
           4.1.3. CA Certificates Response ...........................26
      4.2. Client Certificate Request Functions ......................27
           4.2.1. Simple Enrollment of Clients .......................28
           4.2.2. Simple Re-enrollment of Clients ....................29
           4.2.3. Simple Enroll and Re-enroll Response ...............29
      4.3. Full CMC ..................................................30
           4.3.1. Full CMC Request ...................................30
           4.3.2. Full CMC Response ..................................30
      4.4. Server-Side Key Generation ................................31
           4.4.1. Server-Side Key Generation Request .................32
                  4.4.1.1. Requests for Symmetric Key
                           Encryption of the Private Key .............32
                  4.4.1.2. Requests for Asymmetric Encryption
                           of the Private Key ........................33
           4.4.2. Server-Side Key Generation Response ................33
      4.5. CSR Attributes ............................................35
           4.5.1. CSR Attributes Request .............................35
           4.5.2. CSR Attributes Response ............................35
   5. IANA Considerations ............................................37
   6. Security Considerations ........................................39
   7. References .....................................................41
      7.1. Normative References ......................................41
      7.2. Informative References ....................................43
   Appendix A. Operational Scenario Example Messages .................45
     A.1. Obtaining CA Certificates ..................................45
     A.2. CSR Attributes .............................................47
     A.3. Enroll/Re-enroll ...........................................47
     A.4. Server Key Generation ......................................50
   Appendix B. Contributors and Acknowledgements .....................52

1.  Introduction

   This document profiles certificate enrollment for clients using
   Certificate Management over CMS (CMC) [RFC5272] messages over a
   secure transport.  Enrollment over Secure Transport (EST) describes
   the use of Transport Layer Security (TLS) 1.1 [RFC4346], 1.2
   [RFC5246], or any future version) and Hypertext Transfer Protocol
   (HTTP) [RFC2616] to provide an authenticated and authorized channel
   for Simple Public Key Infrastructure (PKI) Requests and Responses
   [RFC5272].

   Architecturally, the EST service is located between a Certification
   Authority (CA) and a client.  It performs several functions
   traditionally allocated to the Registration Authority (RA) role in a
   PKI.  The nature of communication between an EST server and a CA is
   not described in this document.

Top      ToC       Page 4 
   EST adopts the Certificate Management Protocol (CMP) [RFC4210] model
   for CA certificate rollover, but it does not use the CMP message
   syntax or protocol.  EST servers are extensible in that new functions
   may be defined to provide additional capabilities not specified in
   CMC [RFC5272], and this document defines two such extensions: one for
   requesting Certificate Signing Request attributes and another for
   requesting server-generated keys.

   EST specifies how to transfer messages securely via HTTP over TLS
   (HTTPS) [RFC2818], where the HTTP headers and media types are used in
   conjunction with TLS.  HTTPS operates over TCP; this document does
   not specify EST over HTTP/Datagram Transport Layer Security/User
   Datagram Protocol (HTTP/DTLS/UDP).  With a suitable specification for
   combining HTTP, DTLS, and UDP, there are no EST requirements that
   would prevent it from working over such a stack.  Figure 1 shows how
   the layers build upon each other.

   EST Layering:

   Protocols:
   +--------------------------------------------+
   |                                            |
   | EST request/response messages              |
   |                                            |
   +--------------------------------------------+
   |                                            |
   | HTTP for message transfer and signaling    |
   |                                            |
   +--------------------------------------------+
   |                                            |
   | TLS for transport security                 |
   |                                            |
   +--------------------------------------------+
   |                                            |
   | TCP for transport                          |
   |                                            |
   +--------------------------------------------+

                                 Figure 1

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

Top      ToC       Page 5 
   It is assumed that the reader is familiar with the terms and concepts
   described in Public Key Cryptography Standard (PKCS) #10 [RFC2986],
   HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272][RFC5273][RFC5274], and
   TLS [RFC4346].

   In addition to the terms defined in the terminology section of CMC
   [RFC5272], the following terms are defined for clarity:

   EST CA:  For certificate issuing services, the EST CA is reached
      through the EST server; the CA could be logically "behind" the EST
      server or embedded within it.

   Third-Party Trust Anchor:  Any trust anchor (TA) that is not
      authoritative for the PKI hierarchy for which the EST server is
      providing services.

   Explicit Trust Anchor:  Any TA that is explicitly configured on the
      client or server for use during EST TLS authentication; for
      example, a TA that is manually configured on the EST client or
      bootstrapped as described in Section 4.1.1.  (See more details in
      Sections 3.6 and 6.)

   Implicit Trust Anchor:  Any third-party TA that is available on the
      client or server for use during TLS authentication but is not
      specifically indicated for use during EST TLS authentication; for
      example, TAs commonly used by web browsers to authenticate web
      servers or TAs used by servers to authenticate manufacturer-
      installed client credentials (such as certificates populated into
      cable modems or routers in the factory).  The authorization model
      for these TAs is different from the authorization model for
      Explicit Trust Anchors.  (See more details in Sections 3.6.1,
      3.6.2, and 6).

   Certificate-Less TLS:  Certificate-less TLS cipher suites provide a
      way to perform mutual authentication in situations where neither
      the client nor server have certificates or are willing to use
      them.  The credential used for authentication is a word, phrase,
      code, or key that is shared between the client and server.  The
      credential must be uniquely shared between the client and server
      in order to provide authentication of an individual client to an
      individual server.

2.  Operational Scenario Overviews

   This section provides an informative overview of the operational
   scenarios to better introduce the reader to the protocol discussion.

Top      ToC       Page 6 
   Both the EST clients and server are configured with information that
   provides the basis for mutual authentication and for authorization.
   The specific initialization data depends on the methods available in
   the client and server, but it can include shared secrets, network
   service names and locations (e.g., a Uniform Resource Identifier
   (URI) [RFC3986]), trust anchor information (e.g., a CA certificate or
   a hash of a TA's certificate), and enrollment keys and certificates.
   Depending on an enterprise's acquisition and network management
   practices, some initialization may be performed by the vendor prior
   to delivery of client hardware and software.  In that case, the
   client vendor may provide data, such as trust anchors, to the
   enterprise via a secure procedure.  The distribution of this initial
   information is out of scope.

   Distribution of trust anchors and other certificates can be effected
   via the EST server.  However, nothing can be inferred about the
   authenticity of this data until an out-of-band mechanism is used to
   verify them.

   Sections 2.1-2.3 very closely mirror the text of the Scenarios
   Appendix of [RFC6403] with such modifications as are appropriate for
   this profile.  Sections 2.1-2.6, below, enumerate the set of EST
   functions (see Figure 5) and provide an informative overview of EST's
   capabilities.

   The general client/server interaction proceeds as follows:

      The client initiates a TLS-secured HTTP session with an EST
      server.

      A specific EST service is requested based on a portion of the URI
      used for the session.

      The client and server authenticate each other.

      The client verifies that the server is authorized to serve this
      client.

      The server verifies that the client is authorized to make use of
      this server and the request that the client has made.

      The server acts upon the client request.

2.1.  Obtaining CA Certificates

   The EST client can request a copy of the current EST CA
   certificate(s) from the EST server.  The EST client is assumed to
   perform this operation before performing other operations.

Top      ToC       Page 7 
   Throughout this document we assume the EST CA has a certificate that
   is used by the client to verify signed objects issued by the CA,
   e.g., certificates and certificate revocation lists (CRLs), and that
   a different certificate than the one used to verify signatures on
   certificates and CRLs is used when EST protocol communication
   requires additional encryption.

   The EST client authenticates and verifies the authorization scope of
   the EST server when requesting the current CA certificate(s).  As
   detailed in Sections 3.3.1 and 3.3.3, available options include:

   o  Verifying the EST server's HTTPS URI against the EST server's
      certificate using Implicit TAs (similar to a common HTTPS
      exchange).  This allows the EST server and client to leverage
      existing TAs that might be known to the EST client.

   o  The client can leverage a previously distributed trust anchor
      specific to the EST server.  This allows the EST client to use an
      existing, potentially older, CA certificate to request a current
      CA certificate.

   o  For bootstrapping, the EST client can rely upon manual
      authentication performed by the end-user as detailed in
      Section 4.1.1.

   o  The client can leverage the binding of a shared credential to a
      specific EST server with a certificate-less TLS cipher suite.

   Client authentication is not required for this exchange, so it is
   trivially supported by the EST server.

2.2.  Initial Enrollment

   After authenticating an EST server and verifying that it is
   authorized to provide services to the client, an EST client can
   acquire a certificate for itself by submitting an enrollment request
   to that server.

   The EST server authenticates and authorizes the EST client as
   specified in Sections 3.3.2, 3.3.3, and 3.7.  The methods described
   in the normative text that are discussed in this overview include:

   o  TLS with a previously issued client certificate (e.g., an existing
      certificate issued by the EST CA);

   o  TLS with a previously installed certificate (e.g., manufacturer-
      installed certificate or a certificate issued by some other
      party);

Top      ToC       Page 8 
   o  Certificate-less TLS (e.g., with a shared credential distributed
      out-of-band);

   o  HTTP-based with a username/password distributed out-of-band.

2.2.1.  Certificate TLS Authentication

   If the EST client has a previously installed certificate issued by a
   third-party CA, this certificate can be used to authenticate the
   client's request for a certificate from the EST server (if that CA is
   recognized by the EST server).  An EST client responds to the EST
   server's TLS certificate request message with the existing
   certificate already held by the client.  The EST server will verify
   the client's existing certificate and authorize the client's request
   as described in Section 3.3.2.

2.2.2.  Certificate-Less TLS Authentication

   The EST client and EST server can be mutually authenticated using a
   certificate-less TLS cipher suite (see Section 3.3.3).

2.2.3.  HTTP-Based Client Authentication

   The EST server can optionally also request that the EST client submit
   a username/password using the HTTP Basic or Digest authentication
   methods (see Section 3.2.3).  This approach is desirable if the EST
   client cannot be authenticated during the TLS handshake (see
   Section 3.3.2) or the EST server policy requires additional
   authentication information; see Section 3.2.3.  In all cases,
   HTTP-based client authentication is only to be performed over a
   TLS-protected transport (see Section 3.3).

2.3.  Client Certificate Reissuance

   An EST client can renew/rekey its existing client certificate by
   submitting a re-enrollment request to an EST server.

   When the current EST client certificate can be used for TLS client
   authentication (Section 3.3.2), the client presents this certificate
   to the EST server for client authentication.  When the to be reissued
   EST client certificate cannot be used for TLS client authentication,
   any of the authentication methods used for initial enrollment can be
   used.

   For example, if the client has an alternative certificate issued by
   the EST CA that can be used for TLS client authentication, then it
   can be used.

Top      ToC       Page 9 
   The certificate request message includes the same Subject and
   SubjectAltName as the current certificate.  Name changes are
   requested as specified in Section 4.2.2.

2.4.  Server Key Generation

   The EST client can request a server-generated certificate and key
   pair (see Section 4.4).

2.5.  Full PKI Request Messages

   Full PKI Request [RFC5272] messages can be transported via EST using
   the Full CMC Request function.  This affords access to functions not
   provided by the Simple Enrollment functions.  Full PKI Request
   messages are defined in Sections 3.2 and 4.2 of [RFC5272].  See
   Section 4.3 for a discussion of how EST provides a transport for
   these messages.

2.6.  Certificate Signing Request (CSR) Attributes Request

   Prior to sending an enrollment request to an EST server, an EST
   client can query the EST server for a set of additional attributes
   that the client is requested to use in a subsequent enrollment
   request.

   These attributes can provide additional descriptive information that
   the EST server cannot access itself, such as the Media Access Control
   (MAC) address of an interface of the EST client.  Alternatively,
   these attributes can indicate the kind of enrollment request, such as
   a specific elliptic curve or a specific hash function that the client
   is expected to use when generating the CSR.


Next RFC Part