draft-ietf-acme-integrations-03.txt   draft-ietf-acme-integrations-04.txt 
Network Working Group O. Friel Network Working Group O. Friel
Internet-Draft R. Barnes Internet-Draft R. Barnes
Intended status: Informational Cisco Intended status: Informational Cisco
Expires: September 10, 2021 R. Shekh-Yusef Expires: December 25, 2021 R. Shekh-Yusef
Auth0 Auth0
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
March 09, 2021 June 23, 2021
ACME Integrations ACME Integrations
draft-ietf-acme-integrations-03 draft-ietf-acme-integrations-04
Abstract Abstract
This document outlines multiple advanced use cases and integrations This document outlines multiple advanced use cases and integrations
that ACME facilitates without any modifications or enhancements that ACME facilitates without any modifications or enhancements
required to the base ACME specification. The use cases include ACME required to the base ACME specification. The use cases include ACME
integration with EST, BRSKI and TEAP. integration with EST, BRSKI and TEAP.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2021. This Internet-Draft will expire on December 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ACME Integration with EST . . . . . . . . . . . . . . . . . . 3 3. ACME Integration with EST . . . . . . . . . . . . . . . . . . 4
4. ACME Integration with BRSKI . . . . . . . . . . . . . . . . . 6 4. ACME Integration with BRSKI . . . . . . . . . . . . . . . . . 7
5. ACME Integration with BRSKI Default Cloud Registrar . . . . . 8 5. ACME Integration with BRSKI Default Cloud Registrar . . . . . 9
6. ACME Integration with TEAP . . . . . . . . . . . . . . . . . 10 6. ACME Integration with TEAP . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. ACME Integration Considerations . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.1. Service Operators . . . . . . . . . . . . . . . . . . . . 14
8.1. Denial of Service against ACME infrastructure . . . . . . 15 7.2. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 15
9. Informative References . . . . . . . . . . . . . . . . . . . 16 7.3. Certificate Chains and Trust Anchors . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 7.3.1. EST /cacerts . . . . . . . . . . . . . . . . . . . . 15
7.3.2. TEAP PKCS#7 TLV . . . . . . . . . . . . . . . . . . . 16
7.4. id-kp-cmcRA . . . . . . . . . . . . . . . . . . . . . . . 16
7.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Denial of Service against ACME infrastructure . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
ACME [RFC8555] defines a protocol that a certificate authority (CA) ACME [RFC8555] defines a protocol that a certificate authority (CA)
and an applicant can use to automate the process of domain name and an applicant can use to automate the process of domain name
ownership validation and X.509 (PKIX) certificate issuance. The ownership validation and X.509 (PKIX) certificate issuance. The
protocol is rich and flexible and enables multiple use cases that are protocol is rich and flexible and enables multiple use cases that are
not immediately obvious from reading the specification. This not immediately obvious from reading the specification. This
document explicitly outlines multiple advanced ACME use cases document explicitly outlines multiple advanced ACME use cases
including: including:
o ACME integration with EST [RFC7030] o ACME integration with EST [RFC7030]
o ACME integration with BRSKI o ACME integration with BRSKI [RFC8995]
[I-D.ietf-anima-bootstrapping-keyinfra]
o ACME integration with BRSKI Default Cloud Registrar o ACME integration with BRSKI Default Cloud Registrar
[I-D.friel-anima-brski-cloud] [I-D.ietf-anima-brski-cloud]
o ACME integration with TEAP [RFC7170] and TEAP Update and o ACME integration with TEAP [RFC7170] and TEAP Update and
Extensions for Bootstrapping [I-D.lear-eap-teap-brski] Extensions for Bootstrapping [I-D.lear-eap-teap-brski]
The integrations with EST, BRSKI (which is based upon EST), and TEAP The integrations with EST, BRSKI (which is based upon EST), and TEAP
enable automated certificate enrolment for devices. enable automated certificate enrollment for devices.
ACME for subdomains [I-D.friel-acme-subdomains] outlines how ACME can ACME for subdomains [I-D.friel-acme-subdomains] outlines how ACME can
be used by a client to obtain a certificate for a subdomain be used by a client to obtain a certificate for a subdomain
identifier from a certificate authority where the client has identifier from a certificate authority where the client has
fulfilled a challenge against a parent domain, but does not need to fulfilled a challenge against a parent domain, but does not need to
fulfil a challenge against the explicit subdomain. This is a useful fulfil a challenge against the explicit subdomain. This is a useful
optimization when ACME is used to issue certificates for large optimization when ACME is used to issue certificates for large
numbers of devices as it reduces the domain ownership proof traffic numbers of devices as it reduces the domain ownership proof traffic
(DNS or HTTP) and ACME traffic overhead, but is not a necessary (DNS or HTTP) and ACME traffic overhead, but is not a necessary
requirement. requirement.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are used in this document: The following terms are defined in the CA/Browser Forum Baseline
Requirements [CAB] and are reproduced here:
o BRSKI: Bootstrapping Remote Secure Key Infrastructures o Authorization Domain Name (ADN): The Domain Name used to obtain
[I-D.ietf-anima-bootstrapping-keyinfra] authorization for certificate issuance for a given FQDN. The CA
may use the FQDN returned from a DNS CNAME lookup as the FQDN for
the purposes of domain validation. If the FQDN contains a
wildcard character, then the CA MUST remove all wildcard labels
from the left most portion of requested FQDN. The CA may prune
zero or more labels from left to right until encountering a Base
Domain Name and may use any one of the intermediate values for the
purpose of domain validation
o CA: Certificate Authority o Base Domain Name: The portion of an applied-for FQDN that is the
first domain name node left of a registry-controlled or public
suffix plus the registry-controlled or public suffix (e.g.
"example.co.uk" or "example.com"). For FQDNs where the right-most
domain name node is a gTLD having ICANN Specification 13 in its
registry agreement, the gTLD itself may be used as the Base Domain
Name.
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 Domain Name: The label assigned to a node in the Domain Name
System
o Domain Namespace: The set of all possible Domain Names that are
subordinate to a single node in the Domain Name System
o Fully-Qualified Domain Name (FQDN): A Domain Name that includes
the labels of all superior nodes in the Internet Domain Name
System.
The following terms are used in this document:
o BRSKI: Bootstrapping Remote Secure Key Infrastructures [RFC8995]
o CMC: Certificate Management over CMS o CMC: Certificate Management over CMS
o CSR: Certificate Signing Request o CSR: Certificate Signing Request
o EST: Enrollment over Secure Transport [RFC7030] o EST: Enrollment over Secure Transport [RFC7030]
o FQDN: Fully Qualified Domain Name
o RA: PKI Registration Authority o RA: PKI Registration Authority
o TEAP: Tunneled Extensible Authentication Protocol [RFC7170] o TEAP: Tunneled Extensible Authentication Protocol [RFC7170]
3. ACME Integration with EST 3. ACME Integration with EST
EST [RFC7030] defines a mechanism for clients to enroll with a PKI EST [RFC7030] defines a mechanism for clients to enroll with a PKI
Registration Authority by sending CMC messages over HTTP. EST Registration Authority by sending CMC messages over HTTP. EST
section 1 states: section 1 states:
skipping to change at page 4, line 19 skipping to change at page 5, line 9
This section outlines how ACME could be used for communication This section outlines how ACME could be used for communication
between the EST RA and the CA. The example call flow leverages between the EST RA and the CA. The example call flow leverages
[I-D.friel-acme-subdomains] and shows the RA proving ownership of a [I-D.friel-acme-subdomains] and shows the RA proving ownership of a
parent domain, with individual client certificates being subdomains parent domain, with individual client certificates being subdomains
under that parent domain. This is an optimization that reduces DNS under that parent domain. This is an optimization that reduces DNS
and ACME traffic overhead. The RA could of course prove ownership of and ACME traffic overhead. The RA could of course prove ownership of
every explicit client certificate identifier. every explicit client certificate identifier.
The call flow illustrates the client calling the EST /csrattrs API The call flow illustrates the client calling the EST /csrattrs API
before calling the EST /simpleenroll API. This enables the EST before calling the EST /simpleenroll API.
server to indicate to the client what attributes it expects the
client to include in the CSR request sent in the /simpleenroll API.
For example, EST servers could use this mechanism to tell the client
what fields to include in the CSR Subject and Subject Alternative
Name fields.
The call flow illustrates the EST RA returning a 202 Retry-After The call flow illustrates the EST RA returning a 202 Retry-After
response to the client's simpleenroll request. This is an optional response to the client's simpleenroll request. This is an optional
step and may be necessary if the interactions between the RA and the 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 ACME server take some time to complete. The exact details of when
the RA returns a 202 Retry-After are implementation specific. the RA returns a 202 Retry-After are implementation specific.
+--------+ +--------+ +------+ +-----+ +--------+ +--------+ +------+ +-----+
| Pledge | | EST RA | | ACME | | DNS | | Pledge | | EST RA | | ACME | | DNS |
+--------+ +--------+ +------+ +-----+ +--------+ +--------+ +------+ +-----+
skipping to change at page 6, line 4 skipping to change at page 6, line 37
| | "pledge.example.com" | | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK status=valid | | | | 200 OK status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /certificate | | | | POST /certificate | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| | PEM | | | | PKCS#7 | |
| | "pledge.example.com" | | | | "pledge.example.com" | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
STEP 4: Pledge retries enroll STEP 4: Pledge retries enroll
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledge.example.com" | | | | "pledge.example.com" | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| PKCS#7 | | | | PKCS#7 | | |
| "pledge.example.com" | | | | "pledge.example.com" | | |
|<---------------------| | | |<---------------------| | |
4. ACME Integration with BRSKI 4. ACME Integration with BRSKI
BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is based upon EST BRSKI [RFC8995] is based upon EST [RFC7030] and defines how to
[RFC7030] and defines how to autonomically bootstrap PKI trust autonomically bootstrap PKI trust anchors into devices via means of
anchors into devices via means of signed vouchers. EST certificate signed vouchers. EST certificate enrollment may then optionally take
enrollment may then optionally take place after trust has been place after trust has been established. BRKSI voucher exchange and
established. BRKSI voucher exchange and trust establishment are trust establishment are based on EST extensions and the certificate
based on EST extensions and the certificate enrollment part of BRSKI enrollment part of BRSKI is fully based on EST. Similar to EST,
is fully based on EST. Similar to EST, BRSKI does not define how the BRSKI does not define how the EST RA communicates with the CA.
EST RA communicates with the CA. Therefore, the mechanisms outlined Therefore, the mechanisms outlined in the previous section for using
in the previous section for using ACME as the communications protocol ACME as the communications protocol between the EST RA and the CA are
between the EST RA and the CA are equally applicable to BRSKI. equally applicable to BRSKI.
Note that BRSKI mandates that the id-kp-cmcRA extended key usage bit
is set in the Registrar (or EST RA) end entity certificate that the
Registrar uses when signing voucher request messages sent to the
MASA. Public ACME servers may not be willing to issue end entity
certificates that have the id-kp-cmcRA extended key usage bit set.
In these scenarios, the EST RA may be used by the pledge to get
issued certificates by a public ACME server, but the EST RA itself
will need an end entity certificate that has been issued by a CA
(e.g. an operator deployed private CA) and that has the id-kp-cmcRA
bit set.
The following call flow shows how ACME may be integrated into a full The following call flow shows how ACME may be integrated into a full
BRSKI voucher plus EST enrollment workflow. For brevity, it assumes BRSKI voucher plus EST enrollment workflow. For brevity, it assumes
that the EST RA has previously proven ownership of a parent domain that the EST RA has previously proven ownership of a parent domain
and that pledge certificate identifiers are a subdomain of that and that pledge certificate identifiers are a subdomain of that
parent domain. The domain ownership exchanges between the RA, ACME parent domain. The domain ownership exchanges between the RA, ACME
and DNS are not shown. Similarly, not all BRSKI interactions are and DNS are not shown. Similarly, not all BRSKI interactions are
shown and only the key protocol flows involving voucher exchange and shown and only the key protocol flows involving voucher exchange and
EST enrollment are shown. EST enrollment are shown.
skipping to change at page 8, line 25 skipping to change at page 8, line 46
| | "pledge.example.com" | | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK status=valid | | | | 200 OK status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /certificate | | | | POST /certificate | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| | PEM | | | | PKCS#7 | |
| | "pledge.example.com" | | | | "pledge.example.com" | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
STEP 4: Pledge retries enroll STEP 4: Pledge retries enroll
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledge.example.com" | | | | "pledge.example.com" | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| PKCS#7 | | | | PKCS#7 | | |
| "pledge.example.com" | | | | "pledge.example.com" | | |
|<---------------------| | | |<---------------------| | |
5. ACME Integration with BRSKI Default Cloud Registrar 5. ACME Integration with BRSKI Default Cloud Registrar
BRSKI Cloud Registrar [I-D.friel-anima-brski-cloud] specifies the BRSKI Cloud Registrar [I-D.ietf-anima-brski-cloud] specifies the
behaviour of a BRSKI Cloud Registrar, and how a pledge can interact behaviour of a BRSKI Cloud Registrar, and how a pledge can interact
with a BRSKI Cloud Registrar when bootstrapping. Similar to the with a BRSKI Cloud Registrar when bootstrapping. Similar to the
local domain registrar BRSKI flow, ACME can be easily integrated with local domain registrar BRSKI flow, ACME can be easily integrated with
a cloud registrar bootstrap flow. a cloud registrar bootstrap flow.
BRSKI cloud registrar is flexible and allows for multiple different BRSKI cloud registrar is flexible and allows for multiple different
local domain discovery and redirect scenarios. In the example local domain discovery and redirect scenarios. In the example
illustrated here, the extension to [RFC8366] Vouchers which is illustrated here, the extension to [RFC8366] Vouchers which is
defined in [I-D.friel-anima-brski-cloud], and allows the defined in [I-D.ietf-anima-brski-cloud], and allows the specification
specification of a bootstrap EST domain, is leveraged. This of a bootstrap EST domain, is leveraged. This extension allows the
extension allows the cloud registrar to specify the local domain RA cloud registrar to specify the local domain RA that the pledge should
that the pledge should connect to for the purposes of EST enrollment. connect to for the purposes of EST enrollment.
Similar to the sectiosn above, the client calls EST /csrattrs API Similar to the sectioms above, the client calls EST /csrattrs API
before calling the EST /simpleenroll API. before calling the EST /simpleenroll API.
+--------+ +--------+ +------+ +----------+ +--------+ +--------+ +------+ +----------+
| Pledge | | EST RA | | ACME | | Cloud RA | | Pledge | | EST RA | | ACME | | Cloud RA |
+--------+ +--------+ +------+ | / MASA | +--------+ +--------+ +------+ | / MASA |
| +----------+ | +----------+
| | | |
NOTE: Pre-Authorization of "example.com" is complete NOTE: Pre-Authorization of "example.com" is complete
| | | |
STEP 1: Pledge requests Voucher from Cloud Registrar STEP 1: Pledge requests Voucher from Cloud Registrar
| | | |
| POST /requestvoucher | | POST /requestvoucher |
|-------------------------------------------------------->| |-------------------------------------------------------->|
| | | |
| 200 OK Voucher (includes 'est-domain') | | 200 OK Voucher (includes 'est-domain') |
|<--------------------------------------------------------| |<--------------------------------------------------------|
| | | | | | | |
STEP 2: Pledge enrolls against local domain RA STEP 2: Pledge enrolls against local domain RA
| | | | | | | |
| GET /csrattrs | | | | GET /csrattrs | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| SEQUENCE {AttrOrOID} | | | | SEQUENCE {AttrOrOID} | | |
| SAN OID: | | | | SAN OID: | | |
| "pledge.example.com" | | | | "pledge.example.com" | | |
|<---------------------| | | |<---------------------| | |
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledge.example.com" | | | | "pledge.example.com" | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 202 Retry-After | | | | 202 Retry-After | | |
|<---------------------| | | |<---------------------| | |
| | | | | | | |
STEP 3: RA places ACME order STEP 3: RA places ACME order
| | | | | | | |
| | POST /newOrder | | | | POST /newOrder | |
| | "pledge.example.com" | | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 status=ready | | | | 201 status=ready | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /finalize | | | | POST /finalize | |
| | PKCS#10 CSR | | | | PKCS#10 CSR | |
| | "pledge.example.com" | | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK status=valid | | | | 200 OK status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /certificate | | | | POST /certificate | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| | PEM | | | | PKCS#7 | |
| | "pledge.example.com" | | | | "pledge.example.com" | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
STEP 4: Pledge retries enroll STEP 4: Pledge retries enroll
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledge.example.com" | | | | "pledge.example.com" | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| PKCS#7 | | | | PKCS#7 | | |
| "pledge.example.com" | | | | "pledge.example.com" | | |
|<---------------------| | | |<---------------------| | |
6. ACME Integration with TEAP 6. ACME Integration with TEAP
TEAP [RFC7170] defines a tunnel-based EAP method that enables secure TEAP [RFC7170] defines a tunnel-based EAP method that enables secure
communication between a peer and a server by using TLS to establish a communication between a peer and a server by using TLS to establish a
mutually authenticated tunnel. TEAP enables certificate provisioning mutually authenticated tunnel. TEAP enables certificate provisioning
within the tunnel. TEAP Update and Extensions for Bootstrapping within the tunnel. TEAP Update and Extensions for Bootstrapping
[I-D.lear-eap-teap-brski] defines extensions to TEAP that includes [I-D.lear-eap-teap-brski] defines extensions to TEAP that includes
additional TLVs for certificate enrollment and BRSKI handling inside additional TLVs for certificate enrollment and BRSKI handling inside
the TEAP tunnel. Neither TEAP [RFC7170] or TEAP Update and the TEAP tunnel. Neither TEAP [RFC7170] or TEAP Update and
skipping to change at page 11, line 18 skipping to change at page 11, line 39
what fields the peer should include in the CSR that the peer sends in what fields the peer should include in the CSR that the peer sends in
the PKCS#10 TLV. For example, the TEAP server could instruct the the PKCS#10 TLV. For example, the TEAP server could instruct the
peer what Subject or SAN entries to include in its CSR. peer what Subject or SAN entries to include in its CSR.
Althought not explicitly illustrated in this call flow, the Peer and Althought not explicitly illustrated in this call flow, the Peer and
TEAP Server could exchange BRSKI TLVs, and a BRSKI integration and TEAP Server could exchange BRSKI TLVs, and a BRSKI integration and
voucher exchange with a MASA server could take place over TEAP. voucher exchange with a MASA server could take place over TEAP.
Whether a BRSKI TLV exchange takes place or not does not impact the Whether a BRSKI TLV exchange takes place or not does not impact the
ACME specific message exchanges. ACME specific message exchanges.
+------+ +-------------+ +------+ +-----+ +------+ +-------------+ +------+ +-----+
| Peer | | TEAP-Server | | ACME | | DNS | | Peer | | TEAP-Server | | ACME | | DNS |
+------+ +-------------+ +------+ +-----+ +------+ +-------------+ +------+ +-----+
| | | | | | | |
STEP 1: Pre-Authorization of parent domain STEP 1: Pre-Authorization of parent domain
| | | | | | | |
| | POST /newAuthz | | | | POST /newAuthz | |
| | "example.com" | | | | "example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 authorizations | | | | 201 authorizations | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | Publish DNS TXT | | | | Publish DNS TXT | |
| | "example.com" | | | | "example.com" | |
| |--------------------------------->| | |--------------------------------->|
| | | | | | | |
| | POST /challenge | | | | POST /challenge | |
| |--------------------->| | | |--------------------->| |
| | | Verify | | | | Verify |
| | |---------->| | | |---------->|
| | 200 status=valid | | | | 200 status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | Delete DNS TXT | | | | Delete DNS TXT | |
| | "example.com" | | | | "example.com" | |
| |--------------------------------->| | |--------------------------------->|
| | | | | | | |
| | | | | | | |
STEP 2: Establsh EAP Outer Tunnel STEP 2: Establsh EAP Outer Tunnel
| | | | | | | |
| EAP-Request/ | | | | EAP-Request/ | | |
| Type=Identity | | | | Type=Identity | | |
|<------------------------| | | |<------------------------| | |
| | | | | | | |
| EAP-Response/ | | | | EAP-Response/ | | |
| Type=Identity | | | | Type=Identity | | |
|------------------------>| | | |------------------------>| | |
| | | | | | | |
| EAP-Request/ | | | | EAP-Request/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| TEAP Start, | | | | TEAP Start, | | |
| Authority-ID TLV | | | | Authority-ID TLV | | |
|<------------------------| | | |<------------------------| | |
| | | | | | | |
| EAP-Response/ | | | | EAP-Response/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| TLS(ClientHello) | | | | TLS(ClientHello) | | |
|------------------------>| | | |------------------------>| | |
| | | | | | | |
| EAP-Request/ | | | | EAP-Request/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| TLS(ServerHello, | | | | TLS(ServerHello, | | |
| Certificate, | | | | Certificate, | | |
| ServerKeyExchange, | | | | ServerKeyExchange, | | |
| CertificateRequest, | | | | CertificateRequest, | | |
| ServerHelloDone) | | | | ServerHelloDone) | | |
|<------------------------| | | |<------------------------| | |
| | | | | | | |
| EAP-Response/ | | | | EAP-Response/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| TLS(Certificate, | | | | TLS(Certificate, | | |
| ClientKeyExchange, | | | | ClientKeyExchange, | | |
| CertificateVerify, | | | | CertificateVerify, | | |
| ChangeCipherSpec, | | | | ChangeCipherSpec, | | |
| Finished) | | | | Finished) | | |
|------------------------>| | | |------------------------>| | |
| | | | | | | |
| EAP-Request/ | | | | EAP-Request/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| TLS(ChangeCipherSpec, | | | | TLS(ChangeCipherSpec, | | |
| Finished), | | | | Finished), | | |
| {Crypto-Binding TLV, | | | | {Crypto-Binding TLV, | | |
| Result TLV=Success} | | | | Result TLV=Success} | | |
|<------------------------| | | |<------------------------| | |
| | | | | | | |
| EAP-Response/ | | | | EAP-Response/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {Crypto-Binding TLV, | | | | {Crypto-Binding TLV, | | |
| Result TLV=Success} | | | | Result TLV=Success} | | |
|------------------------>| | | |------------------------>| | |
| | | | | | | |
| EAP-Request/ | | | | EAP-Request/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {Request-Action TLV: | | | | {Request-Action TLV: | | |
| Status=Failure, | | | | Status=Failure, | | |
| Action=Process-TLV, | | | | Action=Process-TLV, | | |
| TLV=CSR-Attributes, | | | | TLV=CSR-Attributes, | | |
| TLV=PKCS#10} | | | | TLV=PKCS#10} | | |
|<------------------------| | | |<------------------------| | |
| | | | | | | |
STEP 3: Enroll for certificate STEP 3: Enroll for certificate
| | | | | | | |
| EAP-Response/ | | | | EAP-Response/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {CSR-Attributes TLV} | | | | {CSR-Attributes TLV} | | |
|------------------------>| | | |------------------------>| | |
| | | | | | | |
| EAP-Request/ | | | | EAP-Request/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {CSR-Attributes TLV} | | | | {CSR-Attributes TLV} | | |
|<------------------------| | | |<------------------------| | |
| | | | | | | |
| EAP-Response/ | | | | EAP-Response/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {PKCS#10 TLV: | | | | {PKCS#10 TLV: | | |
| "pledge.example.com"} | | | | "pledge.example.com"} | | |
|------------------------>| | | |------------------------>| | |
| | POST /newOrder | | | | POST /newOrder | |
| | "pledge.example.com" | | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 status=ready | | | | 201 status=ready | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /finalize | | | | POST /finalize | |
| | PKCS#10 CSR | | | | PKCS#10 CSR | |
| | "pledge.example.com" | | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK status=valid | | | | 200 OK status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /certificate | | | | POST /certificate | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| | PEM | | | | PKCS#7 | |
| | "pledge.example.com" | | | | "pledge.example.com" | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| EAP-Request/ | | | | EAP-Request/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {PKCS#7 TLV, | | | | {PKCS#7 TLV, | | |
| Result TLV=Success} | | | | Result TLV=Success} | | |
|<------------------------| | | |<------------------------| | |
| | | | | | | |
| EAP-Response/ | | | | EAP-Response/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {Result TLV=Success} | | | | {Result TLV=Success} | | |
|------------------------>| | | |------------------------>| | |
| | | | | | | |
| EAP-Success | | | | EAP-Success | | |
|<------------------------| | | |<------------------------| | |
7. IANA Considerations 7. ACME Integration Considerations
7.1. Service Operators
The goal of these integrations is enabling issuance of certificates
with identitiers in a given domain by an ACME server to a client. It
is expected that the EST RA or TEAP servers that the client sends
certificate enrollment requests to are operated by the organization
that controls the domains. The ACME server is not necessarily
operated by the organization that controls the domain.
7.2. CSR Attributes
In all integrations, the client MUST send a CSR Attributes request to
the EST or TEAP server prior to sending a certificate enrollment
request. This enables the server to indicate to the client what
attributes it expects the client to include in the subsequent CSR
request.
Servers MUST use this mechanism to tell the client what identifiers
to include in CSR request. ACME [RFC8555] allows the identifier to
be included in either CSR Subject or Subject Alternative Name fields,
however [I-D.ietf-uta-use-san] states that Subject Alternative Name
field MUST be used. This document aligns with [I-D.ietf-uta-use-san]
and Subject Alternate Name field MUST be used. The identifier must
be a Domain Name in a Domain Namespace that the server has control
over and can fulfill ACME challenges against. The leftmost part of
the identifier MAY be a field that the client presented to the server
in an IEEE 802.1AR [IDevID].
Servers MAY use this field to instruct the client to include other
attributes such as specific policy OIDs. Refer to EST [RFC7030]
section 2.6 for further details.
7.3. Certificate Chains and Trust Anchors
ACME [RFC8555] section 9.1 states that ACME servers may return a
certificate chain to an ACME client where an end entity certificate
is followed by certificates that certify it. The trust anchor
certificate MAY be ommitted from the chain as it is assumed that the
trust anchor is already known by the ACME client i.e. the EST or TEAP
server.
7.3.1. EST /cacerts
EST [RFC7030] section 4.2.3 states that the /simpleenroll response
contains "only the certificate that was issued". EST [RFC7030]
section 4.1.3 states that the /cacerts response "MUST include any
additional certificates the client would need to build a chain from
an EST CA-issued certificate to the current EST CA TA".
Therefore, the EST server MUST return only the ACME end entity
certificate in the /simpleenroll response. The EST server MUST
return the remainder of the chain returned by the ACME server to the
EST server in the /cacerts response to the client, appending the
trust anchor root CA if necessary.
7.3.2. TEAP PKCS#7 TLV
TEAP [RFC7170] section 4.2.16 allows for download of a PKCS#7
certificate chain in response to a TEAP PKCS#10 TLV request. TEAP
also allows for download of multiple PKCS#7 certificates in response
to a TEAP Trusted-Server-Root TLV request.
The TEAP server MUST return the full ACME client certificate chain in
the PKCS#7 response to the PKCS#10 TLV request. The TEAP server MUST
return the ACME server trust anchor in a PKCS#7 response to a
Trusted-Server-Root TLV request. As outlined in Section 7.4, the
TEAP server SHOULD also return the trust anchor that was used for
issuing its own identity certificate, if different from the ACME
server trust anchor.
7.4. id-kp-cmcRA
BRSKI [RFC8995] mandates that the id-kp-cmcRA extended key usage bit
is set in the Registrar (or EST RA) end entity certificate that the
Registrar uses when signing voucher request messages sent to the
MASA. Public ACME servers may not be willing to issue end entity
certificates that have the id-kp-cmcRA extended key usage bit set.
In these scenarios, the EST RA may be used by the pledge to get
issued certificates by a public ACME server, but the EST RA itself
will need an end entity certificate that has been issued by a
different CA (e.g. an operator deployed private CA) and that has the
id-kp-cmcRA bit set.
7.5. Error Handling
ACME [RFC8555] section 6.7 defines multiple errors that may be
returned by an ACME server to an ACME client. TEAP [RFC7170] section
4.2.6 defines multiple errors that may be returned by a TEAP server
to a client in an Error TLV. EST [RFC7030] section 4.2.3 defines how
an EST server may return an error encoded in a CMC response, or may
return a human readable error in the response body.
The following mapping from ACME errors to CMC [RFC5272] section 6.1.4
CMCFailInfo and TEAP [RFC7170] section 4.2.6 error codes is
RECOMMENDED.
+--------------------+-----------------+--------------------------+
| ACME | CMCFailInfo | TEAP Error Code |
+--------------------+-----------------+--------------------------+
| badCSR | badRequest | 1025 Bad CSR |
| caa | badRequest | 1025 Bad CSR |
| rejectedIdentifier | badIdentity | 1024 Bad Identity In CSR |
| all other errors | internalCAError | 1026 Internal CA Error |
+--------------------+-----------------+--------------------------+
8. IANA Considerations
This document does not make any requests to IANA. This document does not make any requests to IANA.
8. Security Considerations 9. Security Considerations
This draft is informational and makes no changes to the referenced This draft is informational and makes no changes to the referenced
specifications. All security considerations from these referenced specifications. All security considerations from these referenced
documents are applicable here: documents are applicable here:
o EST [RFC7030] o EST [RFC7030]
o BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] o BRSKI [RFC8995]
o BRSKI Default Cloud Registrar [I-D.friel-anima-brski-cloud] o BRSKI Default Cloud Registrar [I-D.ietf-anima-brski-cloud]
o TEAP [RFC7170] and TEAP Update and Extensions for Bootstrapping o TEAP [RFC7170] and TEAP Update and Extensions for Bootstrapping
[I-D.lear-eap-teap-brski] [I-D.lear-eap-teap-brski]
Additionally, all Security Considerations in ACME in the following Additionally, all Security Considerations in ACME in the following
areas are equally applicable to ACME Integrations. areas are equally applicable to ACME Integrations.
The integration mechanisms proposed here will primarily use the The integration mechanisms proposed here will primarily use the
DNS-01 challenge documented in [RFC8555] section 8.4. The security DNS-01 challenge documented in [RFC8555] section 8.4. The security
considerations in RFC8555 says: considerations in RFC8555 says:
skipping to change at page 15, line 21 skipping to change at page 18, line 17
own certificates into the the name space of the entity. own certificates into the the name space of the entity.
For many uses, this may allow the attacker to get access to some For many uses, this may allow the attacker to get access to some
enterprise resource. When used to provision, for instance, a (SIP) enterprise resource. When used to provision, for instance, a (SIP)
phone system this would permit an attacker to impersonate a phone system this would permit an attacker to impersonate a
legitimate phone. Not only does this allow for redirection of phone legitimate phone. Not only does this allow for redirection of phone
calls, but possibly also toll fraud. calls, but possibly also toll fraud.
Operators should consider restricting the integration server such Operators should consider restricting the integration server such
that it can only update the DNS records for a specific zone or zones that it can only update the DNS records for a specific zone or zones
where ACME is required for client certificate enrolment automation. where ACME is required for client certificate enrollment automation.
For example, if all IoT devices in an organisation enrol using EST For example, if all IoT devices in an organisation enroll using EST
against an EST RA, and all IoT devices will be issued certificates in against an EST RA, and all IoT devices will be issued certificates in
a subdomain under iot.example.com, then the integration server could a subdomain under iot.example.com, then the integration server could
be issued a credential that only allows updating of DNS records in a be issued a credential that only allows updating of DNS records in a
zone that includes domains in the iot.example.com namespace, but does zone that includes domains in the iot.example.com namespace, but does
not allow updating of DNS records under any other example.com DNS not allow updating of DNS records under any other example.com DNS
namespace. namespace.
When performing challenge fulfilment via writing files to HTTP When performing challenge fulfilment via writing files to HTTP
webservers, write access should only be granted to a specific set of webservers, write access should only be granted to a specific set of
servers, and only to a specific set of directories for storage of servers, and only to a specific set of directories for storage of
challenge files. challenge files.
8.1. Denial of Service against ACME infrastructure 9.1. Denial of Service against ACME infrastructure
The intermdiate node (the TEAP-EAP server, or the EST Registrar) The intermdiate node (the TEAP-EAP server, or the EST Registrar)
should cache the resulting certificates such that if the should cache the resulting certificates such that if the
communication with the pledge is lost, subsequent attempts to enroll communication with the pledge is lost, subsequent attempts to enroll
will result in the cache certificate being returned. will result in the cache certificate being returned.
As many ACME servers have per-day, per-IP and per-subjectAltName As many ACME servers have per-day, per-IP and per-subjectAltName
limits, it is prudent not to request identical certificates too limits, it is prudent not to request identical certificates too
often. This could be due to operator or installer error, with often. This could be due to operator or installer error, with
multiple configuration resets occuring within a short period of time. multiple configuration resets occuring within a short period of time.
The cache should be keyed by the complete contents of the Certificate The cache should be indexed by the complete contents of the
Signing Request, and should not persist beyond the notAfter date in Certificate Signing Request, and should not persist beyond the
the certificate. notAfter date in the certificate.
This means that if the private/public keypair changes on the pledge, This means that if the private/public keypair changes on the pledge,
then a new certificate will be issued. If the the requested then a new certificate will be issued. If the the requested
SubjectAltName changes, then a new certificate will be requested. SubjectAltName changes, then a new certificate will be requested.
In a case where a device is simply factory reset, and enrolls again, In a case where a device is simply factory reset, and enrolls again,
then the same certificate can be returned. then the same certificate can be returned.
9. Informative References 10. Informative References
[CAB] CA/Browser Forum, "Baseline Requirements for the Issuance
and Management of Publicly-Trusted Certificates", n.d.,
<https://cabforum.org/wp-content/uploads/CA-Browser-Forum-
BR-1.7.1.pdf>.
[I-D.friel-acme-subdomains] [I-D.friel-acme-subdomains]
Friel, O., Barnes, R., Hollebeek, T., and M. Richardson, Friel, O., Barnes, R., Hollebeek, T., and M. Richardson,
"ACME for Subdomains", draft-friel-acme-subdomains-03 "ACME for Subdomains", draft-friel-acme-subdomains-04
(work in progress), October 2020. (work in progress), March 2021.
[I-D.friel-anima-brski-cloud] [I-D.ietf-anima-brski-cloud]
Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI
Cloud Registrar", draft-friel-anima-brski-cloud-03 (work Cloud Registrar", draft-ietf-anima-brski-cloud-00 (work in
in progress), September 2020. progress), April 2021.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-uta-use-san]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Salz, R., "Update to Verifying TLS Server Identities with
and K. Watsen, "Bootstrapping Remote Secure Key X.509 Certificates", draft-ietf-uta-use-san-00 (work in
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- progress), April 2021.
keyinfra-45 (work in progress), November 2020.
[I-D.lear-eap-teap-brski] [I-D.lear-eap-teap-brski]
Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP
Update and Extensions for Bootstrapping", draft-lear-eap- Update and Extensions for Bootstrapping", draft-lear-eap-
teap-brski-05 (work in progress), November 2019. teap-brski-05 (work in progress), November 2019.
[IDevID] IEEE, "IEEE Standard for Local and metropolitan area
networks - Secure Device Identity", n.d.,
<https://1.ieee802.org/security/802-1ar>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<https://www.rfc-editor.org/info/rfc3007>. <https://www.rfc-editor.org/info/rfc3007>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version "Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>. <https://www.rfc-editor.org/info/rfc7170>.
skipping to change at page 17, line 19 skipping to change at page 20, line 24
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
Authors' Addresses Authors' Addresses
Owen Friel Owen Friel
Cisco Cisco
Email: ofriel@cisco.com Email: ofriel@cisco.com
Richard Barnes Richard Barnes
Cisco Cisco
 End of changes. 36 change blocks. 
293 lines changed or deleted 439 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/