Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8295

EST (Enrollment over Secure Transport) Extensions

Pages: 54
Proposed Standard
Part 1 of 4 – Pages 1 to 10
None   None   Next

Top   ToC   RFC8295 - Page 1
Internet Engineering Task Force (IETF)                         S. Turner
Request for Comments: 8295                                         sn3rd
Category: Standards Track                                   January 2018
ISSN: 2070-1721


           EST (Enrollment over Secure Transport) Extensions

Abstract

The EST (Enrollment over Secure Transport) protocol defines the Well- Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services. 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 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8295.
Top   ToC   RFC8295 - Page 2
Copyright Notice

   Copyright (c) 2018 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
   (https://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 ....................................................4 1.1. Definitions ................................................6 1.2. Authentication and Authorization ...........................7 1.3. TLS Cipher Suites ..........................................7 1.4. URI Configuration ..........................................7 1.5. Message Types ..............................................8 1.6. Key Words .................................................10 2. Locate Available Packages ......................................10 2.1. PAL Format ................................................12 2.1.1. PAL Package Types ..................................14 2.1.2. PAL XML Schema .....................................19 2.1.3. PAL JSON Object ....................................23 2.2. Request PAL ...............................................23 2.3. Provide PAL ...............................................24 3. Distribute EE Certificates .....................................25 3.1. EE Certificate Request ....................................25 3.2. EE Certificate Response ...................................26 4. Distribute CRLs and ARLs .......................................26 4.1. CRL Request ...............................................26 4.2. CRL Response ..............................................26 5. Symmetric Keys, Receipts, and Errors ...........................27 5.1. Symmetric Keys ............................................27 5.1.1. Distribute Symmetric Keys ..........................28 5.1.2. Symmetric Key Response .............................28 5.2. Symmetric Key Receipts and Errors .........................29 5.2.1. Provide Symmetric Key Receipt or Error .............30 5.2.2. Symmetric Key Receipt or Error Response ............31
Top   ToC   RFC8295 - Page 3
   6. Firmware, Receipts, and Errors .................................31
      6.1. Firmware ..................................................31
           6.1.1. Distribute Firmware ................................32
           6.1.2. Firmware Response ..................................32
      6.2. Firmware Receipts and Errors ..............................33
           6.2.1. Provide Firmware Receipt or Error ..................33
           6.2.2. Firmware Receipt or Error Response .................33
   7. Trust Anchor Management Protocol ...............................34
      7.1. TAMP Status Query, Trust Anchor Update,
           Apex Trust Anchor Update, Community Update,
           and Sequence Number Adjust ................................34
           7.1.1. Request TAMP Packages ..............................34
           7.1.2. Return TAMP Packages ...............................35
      7.2. TAMP Responses, Confirms, and Errors ......................35
           7.2.1. Provide TAMP Responses, Confirms, or Errors ........36
           7.2.2. TAMP Responses, Confirms, and Error Responses ......36
   8. Asymmetric Keys, Receipts, and Errors ..........................36
      8.1. Asymmetric Key Encapsulation ..............................37
      8.2. Asymmetric Key Package Receipts and Errors ................38
      8.3. PKCS #12 ..................................................39
           8.3.1. Server-Side Key Generation Request .................39
           8.3.2. Server-Side Key Generation Response ................39
   9. PAL and Certificate Enrollment .................................40
   10. Security Considerations .......................................43
   11. IANA Considerations ...........................................44
      11.1. PAL Name Space ...........................................44
      11.2. PAL XML Schema ...........................................44
      11.3. PAL Package Types ........................................44
   12. References ....................................................45
      12.1. Normative References .....................................45
      12.2. Informative References ...................................50
   Appendix A. Example Use of PAL ....................................51
   Appendix B. Additional CSR Attributes .............................53
   Acknowledgements ..................................................54
   Author's Address ..................................................54
Top   ToC   RFC8295 - Page 4

1. Introduction

The EST (Enrollment over Secure Transport) protocol [RFC7030] defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- to support selected services related to the PKI (Public Key Infrastructure), with such PCs (path components) as simple enrollment with /simpleenroll, rekey or renew with /simplereenroll, etc. A server that wishes to support additional PKI-related services and other security-related packages could use the same .well-known URI by defining additional PCs. This document defines six such PCs: o /pal - The PAL (Package Availability List) provides a list of all known packages available and authorized for a client. By accessing the service provided by this PC first, the client can walk through the PAL and download all the packages necessary to begin operating securely. The PAL essentially points to other PCs, including the PCs defined in this document as well as those defined in [RFC7030] (e.g., /cacerts, /simpleenroll, /simplereenroll, /fullcmc, /serverkeygen, and /csrattrs). The /pal PC is described in Section 2. o /eecerts - EE (End-Entity) certificates [RFC5280] are needed by the client when they invoke a security protocol for communicating with a peer (i.e., they become operational and do something meaningful as opposed to just communicating with the infrastructure). If the infrastructure knows the certificate(s) needed by the client, then providing the peer's certificate avoids the client having to discover the peer's certificate. This service is not meant to be a general-purpose repository to which clients query a "repository" and then get a response; this is purely a push mechanism. The /eecerts PC is described in Section 3. o /crls - CRLs (Certificate Revocation Lists) and ARLs (Authority Revocation Lists) [RFC5280] are also needed by the client when they validate certificate paths. CRLs (and ARLs) from TAs (Trust Anchors) and intermediate CAs (Certification Authorities) are needed to validate the certificates used to generate the client's certificate or the peer's certificate, which is provided by the /eecerts PC, and providing them saves the client from having to "discover" them and then retrieve them. CRL "discovery" is greatly aided by the inclusion of the CRL Distribution Point certificate extension [RFC5280], but this extension is not always present in certificates and requires another connection to retrieve them. Like the /eecerts PC, this service is not meant to be a general-purpose repository to which clients query a repository and then get a response; this is purely a push mechanism. The /crls PC is described in Section 4.
Top   ToC   RFC8295 - Page 5
   o  /symmetrickeys - In some cases, clients use symmetric keys
      [RFC6031] when communicating with their peers.  If the client's
      peers are known by the server a priori, then providing them saves
      the client or an administrator from later having to find,
      retrieve, and install them.  Like the /eecerts and /crls PCs, this
      service is not meant to be a general-purpose repository to which
      clients query a repository and then get a response; this is purely
      a push mechanism for the keys themselves.  However, things do not
      always go as planned, and clients need to inform the server about
      any errors.  If things did go well, then the client, if requested,
      needs to provide a receipt [RFC7191].  The /symmetrickeys and
      /symmetrickeys/return PCs are described in Section 5.

   o  /firmware - Some client firmware and software support automatic
      update mechanisms, and some do not.  For those that do not, the
      /firmware PC provides a mechanism for the infrastructure to inform
      the client that firmware and software updates [RFC4108] are
      available.  Because updates do not always go as planned and
      because sometimes the server needs to know whether the firmware
      was received and processed, this PC also provides a mechanism to
      return errors and receipts.  The /firmware and /firmware/return
      PCs are defined in Section 6.

   o  /tamp - To control the TAs in client TA databases, servers use the
      /tamp PC to request that clients retrieve TAMP (Trust Anchor
      Management Protocol) query, update, and adjust packages [RFC5934],
      and clients use the /tamp/return PC to return TAMP responses,
      confirms, and errors [RFC5934].  The /tamp and /tamp/return PCs
      are defined in Section 7.

   This document also extends the /est/serverkeygen PC [RFC7030] to
   support the following (see Section 8):

   o  Returning asymmetric key package receipts and errors [RFC7191].

   o  Encapsulating returned asymmetric keys in additional CMS
      (Cryptographic Message Syntax) content types [RFC7193].

   o  Returning server-generated public key pairs encapsulated in
      PKCS #12 (Public Key Cryptography Standard #12) [RFC7292].

   While the motivation is to provide packages to clients during
   enrollment so that they can perform securely after enrollment, the
   services defined in this specification can be used after enrollment.
Top   ToC   RFC8295 - Page 6

1.1. Definitions

Familiarity with the following specifications is assumed: o "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages" [RFC4108] o "Certificate Management over CMS (CMC)" [RFC5272] o "Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type" [RFC6032] o "Cryptographic Message Syntax (CMS)" [RFC5652] o "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)" [RFC6268] o "Trust Anchor Management Protocol (TAMP)" [RFC5934] o "Cryptographic Message Syntax (CMS) Content Constraints Extension" [RFC6010] o "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type" [RFC6031] o "Enrollment over Secure Transport" [RFC7030] o "Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types" [RFC7191] Also, familiarity with the CMS protecting content types signed-data and encrypted-data [RFC5652] is assumed. The CMS encrypted key package is defined in [RFC6032]. In addition to the definitions found in [RFC7030], the following definitions are used in this document: Agent: An entity that performs functions on behalf of a client. Agents can service a) one or more clients on the same network as the server, b) clients on non-IP-based networks, or c) clients that have a non-electronic air gap [RFC4949] between themselves and the server. Interactions between the agent and client in the last two cases are beyond the scope of this document. Before an agent can service clients, the agent must have a trust relationship with the server (i.e., be authorized to act on behalf of clients).
Top   ToC   RFC8295 - Page 7
   Client: A device that ultimately consumes and uses the packages to
      enable communications.  In other words, the client is the endpoint
      for the packages, and an agent may have one or more clients.  To
      avoid confusion, this document henceforth uses the term "client"
      to refer to both agents and clients.

   Package: An object that contains one or more content types.  There
      are numerous types of packages, e.g., packages for asymmetric
      keys, symmetric keys, encrypted keys, CRLs, firmware, and TAMP.
      See Section 2.1.1.  All of these packages are digitally signed by
      their creator and encapsulated in a CMS signed-data [RFC5652]
      [RFC6268] (except the public key certificates and CRLs that are
      already digitally signed by a CA): firmware receipts and errors;
      TAMP responses, confirms, and errors; and "key package" receipts
      and errors that can be optionally signed.  Certificates and CRLs
      are included in a package that uses signed-data, which is often
      referred to as a "degenerate CMS", or as a "certs-only" [RFC5751]
      [RFC6268] or "crls-only" message (see Section 4.2), but no
      signature or content is present -- hence the names "certs-only"
      and "crls-only".

      Note: As per [RFC7030], the creator may or may not be the EST
      server or the EST CA.

1.2. Authentication and Authorization

Client and server authentication as well as client and server authorization are as defined in [RFC7030]. The requirements for each are discussed in the "request" and "response" sections (e.g., Sections 3.1 and 3.2 of this document) of each of the PCs defined herein. The requirements for the TA databases are as specified in [RFC7030] as well.

1.3. TLS Cipher Suites

TLS (Transport Layer Security) cipher suites and issues associated with them are as defined in [RFC7030].

1.4. URI Configuration

As specified in Section 3.1 of [RFC7030], the client is configured with sufficient information to form the server URI [RFC3986]. Like EST, this configuration mechanism is beyond the scope of this document.
Top   ToC   RFC8295 - Page 8

1.5. Message Types

This document uses existing media types for the messages as specified by "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP" [RFC2585], "The application/pkcs10 Media Type" [RFC5967], and "Certificate Management over CMS (CMC)" [RFC5272]. For consistency with [RFC5273], each distinct EST message type uses an HTTP Content-Type header with a specific media type. The EST messages, their corresponding media types for each operation, and the sections that provide request and response information are as follows: +-------------------+---------------------------------+---------------+ | Message type | Request media type | Request | | | Response media type(s) | Response | | (per operation) | Source(s) of types | | +===================+=================================+===============+ | Locate Available | N/A | Section 2.2 | | Packages | application/xml or | Section 2.3 | | | application/json | | | | [RFC7303] [RFC8259] | | | /pal | | | +===================+=================================+===============+ | Distribute EE | N/A | Section 3.1 | | Certificates | application/pkcs7-mime | Section 3.2 | | | [RFC5751] | | | /eecerts | | | +===================+=================================+===============+ | Distribute CRLs | N/A | Section 4.1 | | | application/pkcs7-mime | Section 4.2 | | | [RFC5751] | | | /crls | | | +===================+=================================+===============+ | Symmetric Key | N/A | Section 5.1.1 | | Distribution | application/cms | Section 5.1.2 | | | [RFC7193] | | | /symmetrickeys | | | +===================+=================================+===============+ | Return Symmetric | application/cms | Section 5.2.1 | | Key | N/A | Section 5.2.2 | | Receipts/Errors | [RFC7193] | | | | | | | /symmetrickeys/ | | | | return | | |
Top   ToC   RFC8295 - Page 9
 +===================+=================================+===============+
 | Firmware          | N/A                             | Section 6.1.1 |
 | Distribution      | application/cms                 | Section 6.1.2 |
 |                   | [RFC7193]                       |               |
 | /firmware         |                                 |               |
 +===================+=================================+===============+
 | Return Firmware   | application/cms                 | Section 6.2.1 |
 | Receipts/Errors   | N/A                             | Section 6.2.2 |
 |                   | [RFC7193]                       |               |
 | /firmware/return  |                                 |               |
 +===================+=================================+===============+
 | Trust Anchor      | N/A                             | Section 7.1.1 |
 | Management        | application/                    | Section 7.1.2 |
 |                   |   tamp-status-query             |               |
 |                   |   tamp-update                   |               |
 |                   |   tamp-apex-update              |               |
 |                   |   tamp-community-update         |               |
 |                   |   tamp-sequence-adjust          |               |
 |                   | [RFC5934]                       |               |
 | /tamp             |                                 |               |
 +===================+=================================+===============+
 | Return TAMP       | application/                    | Section 7.2.1 |
 | Responses/        |   tamp-status-response          |               |
 | Confirms/         |   tamp-update-confirm           |               |
 | Errors            |   tamp-apex-update-confirm      |               |
 |                   |   tamp-community-update-confirm |               |
 |                   |   tamp-sequence-adjust-confirm  |               |
 |                   |   tamp-error                    |               |
 |                   | N/A                             | Section 7.2.2 |
 |                   | [RFC5934]                       |               |
 | /tamp/return      |                                 |               |
 +===================+=================================+===============+
 | Server-Side Key   | application/pkcs10 with         | Section 8.1   |
 | Generation        | content type attribute          |               |
 |                   | CSR*                            |               |
 |                   | application/cms                 | Section 8.1   |
 | /serverkeygen     | [RFC5967] [RFC7193] [RFC7030]   |               |
Top   ToC   RFC8295 - Page 10
 +===================+=================================+===============+
 | Return Asymmetric | application/cms                 | Section 8.2   |
 | Key               | N/A                             | Section 8.2   |
 | Receipts/Errors   | [RFC7193]                       |               |
 |                   |                                 |               |
 | /serverkeygen/    |                                 |               |
 |    return         |                                 |               |
 +===================+=================================+===============+
 | Server-Side Key   | application/pkcs10              | Section 8.3.1 |
 | Generation:       | application/pkcs12              | Section 8.3.2 |
 | PKCS #12          | [RFC5967] [RFC7193] [RFC7030]   |               |
 |                   |                                 |               |
 | /serverkeygen     |                                 |               |
 +===================+=================================+===============+

    * Certificate Signing Request

1.6. Key Words

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.


(page 10 continued on part 2)

Next Section