Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7030

Enrollment over Secure Transport

Pages: 53
Proposed Standard
Errata
Updated by:  89518996
Part 1 of 4 – Pages 1 to 9
None   None   Next

Top   ToC   RFC7030 - 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.
Top   ToC   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   RFC7030 - 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   RFC7030 - 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   RFC7030 - 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   RFC7030 - 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   RFC7030 - 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   RFC7030 - 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   RFC7030 - 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 page on part 2)

Next Section