Network Working Group O. Friel
Internet-Draft R. Barnes
Intended status: Informational Cisco
Expires: June 20, 2022 R. Shekh-Yusef
Auth0
M. Richardson
Sandelman Software Works
December 17, 2021
ACME Integrations
draft-ietf-acme-integrations-06
Abstract
This document outlines multiple advanced use cases and integrations
that ACME facilitates without any modifications or enhancements
required to the base ACME specification. The use cases include ACME
integration with EST, BRSKI and TEAP.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 20, 2022.
Copyright Notice
Copyright (c) 2021 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
Friel, et al. Expires June 20, 2022 [Page 1]
Internet-Draft ACME-INTEGRATIONS December 2021
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ACME Integration with EST . . . . . . . . . . . . . . . . . . 4
4. ACME Integration with BRSKI . . . . . . . . . . . . . . . . . 7
5. ACME Integration with BRSKI Default Cloud Registrar . . . . . 9
6. ACME Integration with TEAP . . . . . . . . . . . . . . . . . 11
7. ACME Integration Considerations . . . . . . . . . . . . . . . 15
7.1. Service Operators . . . . . . . . . . . . . . . . . . . . 15
7.2. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 15
7.3. Certificate Chains and Trust Anchors . . . . . . . . . . 15
7.3.1. EST /cacerts . . . . . . . . . . . . . . . . . . . . 16
7.3.2. TEAP PKCS#7 TLV . . . . . . . . . . . . . . . . . . . 16
7.4. id-kp-cmcRA . . . . . . . . . . . . . . . . . . . . . . . 16
7.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Denial of Service against ACME infrastructure . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
ACME [RFC8555] defines a protocol that a certification authority (CA)
and an applicant can use to automate the process of domain name
ownership validation and X.509 (PKIX) certificate issuance. The
protocol is rich and flexible and enables multiple use cases that are
not immediately obvious from reading the specification. This
document explicitly outlines multiple advanced ACME use cases
including:
o ACME integration with EST [RFC7030]
o ACME integration with BRSKI [RFC8995]
o ACME integration with BRSKI Default Cloud Registrar
[I-D.ietf-anima-brski-cloud]
o ACME integration with TEAP [RFC7170] and TEAP Update and
Extensions for Bootstrapping [I-D.lear-eap-teap-brski]
The integrations with EST, BRSKI (which is based upon EST), and TEAP
enable automated certificate enrollment for devices.
Friel, et al. Expires June 20, 2022 [Page 2]
Internet-Draft ACME-INTEGRATIONS December 2021
ACME for subdomains [I-D.ietf-acme-subdomains] outlines how ACME can
be used by a client to obtain a certificate for a subdomain
identifier from an ACME server where the client has fulfilled a
challenge against a parent domain, but does not need to fulfil a
challenge against the explicit subdomain. This is a useful
optimization when ACME is used to issue certificates for large
numbers of devices as it reduces the domain ownership proof traffic
(DNS or HTTP) and ACME traffic overhead, but is not a necessary
requirement.
2. 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are defined in DNS Terminology [RFC8499] and are
reproduced here:
o Label: An ordered list of zero or more octets that makes up a
portion of a domain name. Using graph theory, a label identifies
one node in a portion of the graph of all possible domain names.
o Domain Name: An ordered list of one or more labels.
o Subdomain: "A domain is a subdomain of another domain if it is
contained within that domain. This relationship can be tested by
seeing if the subdomain's name ends with the containing domain's
name." (Quoted from [RFC1034], Section 3.1) For example, in the
host name "nnn.mmm.example.com", both "mmm.example.com" and
"nnn.mmm.example.com" are subdomains of "example.com". Note that
the comparisons here are done on whole labels; that is,
"ooo.example.com" is not a subdomain of "oo.example.com".
o Fully-Qualified Domain Name (FQDN): This is often just a clear way
of saying the same thing as "domain name of a node", as outlined
above. However, the term is ambiguous. Strictly speaking, a
fully-qualified domain name would include every label, including
the zero-length label of the root: such a name would be written
"www.example.net." (note the terminating dot). But, because every
name eventually shares the common root, names are often written
relative to the root (such as "www.example.net") and are still
called "fully qualified". This term first appeared in [RFC0819].
In this document, names are often written relative to the root.
The following terms are used in this document:
Friel, et al. Expires June 20, 2022 [Page 3]
Internet-Draft ACME-INTEGRATIONS December 2021
o BRSKI: Bootstrapping Remote Secure Key Infrastructures [RFC8995]
o Certification Authority (CA): An organization that is responsible
for the creation, issuance, revocation, and management of
Certificates. The term applies equally to both Roots CAs and
Subordinate CAs
o CMS: Cryptographic Message Syntax [RFC5652]
o CMC: Certificate Management over CMS [RFC5272]
o CSR: Certificate Signing Request
o EST: Enrollment over Secure Transport [RFC7030]
o MASA: Manufacturer Authorized Signing Authority as defined in
[RFC8995]
o RA: PKI Registration Authority
o TEAP: Tunneled Extensible Authentication Protocol [RFC7170]
o TLV: Type-Length-Value format defined in TEAP
3. ACME Integration with EST
EST [RFC7030] defines a mechanism for clients to enroll with a PKI
Registration Authority by sending CMC messages over HTTP. EST
section 1 states:
"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."
EST section 1.1 states that:
"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."
When the CA is logically "behind" the EST RA, EST does not specify
how the RA communicates with the CA. EST section 1 states:
"The nature of communication between an EST server and a CA is not
described in this document."
Friel, et al. Expires June 20, 2022 [Page 4]
Internet-Draft ACME-INTEGRATIONS December 2021
This section outlines how ACME could be used for communication
between the EST RA and the CA. The example call flow leverages
[I-D.ietf-acme-subdomains] and shows the RA proving ownership of a
parent domain, with individual client certificates being subdomains
under that parent domain. This is an optimization that reduces DNS
and ACME traffic overhead. The RA could of course prove ownership of
every explicit client certificate identifier. The example also
illustrates using the ACME DNS challenge type, but this integration
is not limited to DNS challenges.
The call flow illustrates the client calling the EST /csrattrs API
before calling the EST /simpleenroll API. This enables the server to
indicate what fields the client should include in the CSR that the
client sends in the /simpleenroll API. CSR Attributes handling are
discussed in Section 7.2.
The call flow illustrates the EST RA returning a 202 Retry-After
response to the client's simpleenroll request. This is an optional
step and may be necessary if the interactions between the RA and the
ACME server take some time to complete. The exact details of when
the RA returns a 202 Retry-After are implementation specific.
+--------+ +--------+ +--------+ +-----+
| Client | | EST RA | | ACME | | DNS |
+--------+ +--------+ | Server | +-----+
| | +--------+ |
| | | |
STEP 1: Pre-Authorization of parent domain
| | | |
| | POST /newAuthz | |
| | "example.com" | |
| |--------------------->| |
| | | |
| | 201 authorizations | |
| |<---------------------| |
| | | |
| | Publish DNS TXT | |
| | "example.com" | |
| |--------------------------------->|
| | | |
| | POST /challenge | |
| |--------------------->| |
| | | Verify |
| | |---------->|
| | 200 status=valid | |
| |<---------------------| |
| | | |
| | Delete DNS TXT | |
Friel, et al. Expires June 20, 2022 [Page 5]
Internet-Draft ACME-INTEGRATIONS December 2021
| | "example.com" | |
| |--------------------------------->|
| | | |
STEP 2: Client enrolls against RA
| | | |
| GET /csrattrs | | |
|--------------------->| | |
| | | |
| 200 OK | | |
| SEQUENCE {AttrOrOID} | | |
| SAN OID: | | |
| "client.example.com" | | |
|<---------------------| | |
| | | |
| POST /simpleenroll | | |
| PCSK#10 CSR | | |
| "client.example.com" | | |
|--------------------->| | |
| | | |
| 202 Retry-After | | |
|<---------------------| | |
| | | |
STEP 3: RA places ACME order
| | | |
| | POST /newOrder | |
| | "client.example.com" | |
| |--------------------->| |
| | | |
| | 201 status=ready | |
| |<---------------------| |
| | | |
| | POST /finalize | |
| | PKCS#10 CSR | |
| | "client.example.com" | |
| |--------------------->| |
| | | |
| | 200 OK status=valid | |
| |<---------------------| |
| | | |
| | POST /certificate | |
| |--------------------->| |
| | | |
| | 200 OK | |
| | PKCS#7 | |
| | "client.example.com" | |
| |<---------------------| |
| | | |
STEP 4: Client retries enroll
Friel, et al. Expires June 20, 2022 [Page 6]
Internet-Draft ACME-INTEGRATIONS December 2021
| | | |
| POST /simpleenroll | | |
| PCSK#10 CSR | | |
| "client.example.com" | | |
|--------------------->| | |
| | | |
| 200 OK | | |
| PKCS#7 | | |
| "client.example.com" | | |
|<---------------------| | |
4. ACME Integration with BRSKI
BRSKI [RFC8995] is based upon EST [RFC7030] and defines how to
autonomically bootstrap PKI trust anchors into devices via means of
signed vouchers. EST certificate enrollment may then optionally take
place after trust has been established. BRKSI voucher exchange and
trust establishment are based on EST extensions and the certificate
enrollment part of BRSKI is fully based on EST. Similar to EST,
BRSKI does not define how the EST RA communicates with the CA.
Therefore, the mechanisms outlined in the previous section for using
ACME as the communications protocol between the EST RA and the CA are
equally applicable to BRSKI.
The following call flow shows how ACME may be integrated into a full
BRSKI voucher plus EST enrollment workflow. For brevity, it assumes
that the EST RA has previously proven ownership of a parent domain
and that pledge certificate identifiers are a subdomain of that
parent domain. The domain ownership exchanges between the RA, ACME
and DNS are not shown. Similarly, not all BRSKI interactions are
shown and only the key protocol flows involving voucher exchange and
EST enrollment are shown.
Similar to the EST section above, the client calls EST /csrattrs API
before calling the EST /simpleenroll API. This enables the server to
indicate what fields the pledge should include in the CSR that the
client sends in the /simpleenroll API. Refer to section {csr-
attributes} for more details.
The call flow illustrates the RA returning a 202 Retry-After response
to the initial EST /simpleenroll API. This may be appropriate if
processing of the /simpleenroll request and ACME interactions takes
some time to complete.
+--------+ +--------+ +--------+ +------+
| Pledge | | EST RA | | ACME | | MASA |
+--------+ +--------+ | Server | +------+
| | +--------+ |
Friel, et al. Expires June 20, 2022 [Page 7]
Internet-Draft ACME-INTEGRATIONS December 2021
| | | |
NOTE: Pre-Authorization of "example.com" is complete
| | | |
STEP 1: Pledge requests Voucher
| | | |
| POST /requestvoucher | | |
|--------------------->| | |
| | POST /requestvoucher | |
| |--------------------------------->|
| | | |
| | 200 OK Voucher | |
| |<---------------------------------|
| 200 OK Voucher | | |
|<---------------------| | |
| | | |
STEP 2: Pledge enrolls against RA
| | | |
| GET /csrattrs | | |
|--------------------->| | |
| | | |
| 200 OK | | |
| SAN: | | |
| "pledge.example.com" | | |
|<---------------------| | |
| | | |
| POST /simpleenroll | | |
| PCSK#10 CSR | | |
| "pledge.example.com" | | |
|--------------------->| | |
| | | |
| 202 Retry-After | | |
|<---------------------| | |
| | | |
STEP 3: RA places ACME order
| | | |
| | POST /newOrder | |
| | "pledge.example.com" | |
| |--------------------->| |
| | | |
| | 201 status=ready | |
| |<---------------------| |
| | | |
| | POST /finalize | |
| | PKCS#10 CSR | |
| | "pledge.example.com" | |
| |--------------------->| |
| | | |
| | 200 OK status=valid | |
Friel, et al. Expires June 20, 2022 [Page 8]
Internet-Draft ACME-INTEGRATIONS December 2021
| |<---------------------| |
| | | |
| | POST /certificate | |
| |--------------------->| |
| | | |
| | 200 OK | |
| | PKCS#7 | |
| | "pledge.example.com" | |
| |<---------------------| |
| | | |
STEP 4: Pledge retries enroll
| | | |
| POST /simpleenroll | | |
| PCSK#10 CSR | | |
| "pledge.example.com" | | |
|--------------------->| | |
| | | |
| 200 OK | | |
| PKCS#7 | | |
| "pledge.example.com" | | |
|<---------------------| | |
5. ACME Integration with BRSKI Default Cloud Registrar
BRSKI Cloud Registrar [I-D.ietf-anima-brski-cloud] specifies the
behaviour of a BRSKI Cloud Registrar, and how a pledge can interact
with a BRSKI Cloud Registrar when bootstrapping. Similar to the
local domain registrar BRSKI flow, ACME can be easily integrated with
a cloud registrar bootstrap flow.
BRSKI cloud registrar is flexible and allows for multiple different
local domain discovery and redirect scenarios. In the example
illustrated here, the extension to [RFC8366] Vouchers which is
defined in [I-D.ietf-anima-brski-cloud], and allows the specification
of a bootstrap EST domain, is leveraged. This extension allows the
cloud registrar to specify the local domain RA that the pledge should
connect to for the purposes of EST enrollment.
Similar to the sections above, the client calls EST /csrattrs API
before calling the EST /simpleenroll API.
+--------+ +--------+ +--------+ +----------+
| Pledge | | EST RA | | ACME | | Cloud RA |
+--------+ +--------+ | Server | | / MASA |
| +--------+ +----------+
| |
NOTE: Pre-Authorization of "example.com" is complete
| |
Friel, et al. Expires June 20, 2022 [Page 9]
Internet-Draft ACME-INTEGRATIONS December 2021
STEP 1: Pledge requests Voucher from Cloud Registrar
| |
| POST /requestvoucher |
|-------------------------------------------------------->|
| |
| 200 OK Voucher (includes 'est-domain') |
|<--------------------------------------------------------|
| | | |
STEP 2: Pledge enrolls against local domain RA
| | | |
| GET /csrattrs | | |
|--------------------->| | |
| | | |
| 200 OK | | |
| SAN: | | |
| "pledge.example.com" | | |
|<---------------------| | |
| | | |
| POST /simpleenroll | | |
| PCSK#10 CSR | | |
| "pledge.example.com" | | |
|--------------------->| | |
| | | |
| 202 Retry-After | | |
|<---------------------| | |
| | | |
STEP 3: RA places ACME order
| | | |
| | POST /newOrder | |
| | "pledge.example.com" | |
| |--------------------->| |
| | | |
| | 201 status=ready | |
| |<---------------------| |
| | | |
| | POST /finalize | |
| | PKCS#10 CSR | |
| | "pledge.example.com" | |
| |--------------------->| |
| | | |
| | 200 OK status=valid | |
| |<---------------------| |
| | | |
| | POST /certificate | |
| |--------------------->| |
| | | |
| | 200 OK | |
| | PKCS#7 | |
Friel, et al. Expires June 20, 2022 [Page 10]
Internet-Draft ACME-INTEGRATIONS December 2021
| | "pledge.example.com" | |
| |<---------------------| |
| | | |
STEP 4: Pledge retries enroll
| | | |
| POST /simpleenroll | | |
| PCSK#10 CSR | | |
| "pledge.example.com" | | |
|--------------------->| | |
| | | |
| 200 OK | | |
| PKCS#7 | | |
| "pledge.example.com" | | |
|<---------------------| | |
6. ACME Integration with TEAP
TEAP [