draft-ietf-acme-integrations-01.txt   draft-ietf-acme-integrations-02.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: January 14, 2021 R. Shekh-Yusef Expires: May 22, 2021 R. Shekh-Yusef
Auth0 Auth0
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
July 13, 2020 November 18, 2020
ACME Integrations ACME Integrations
draft-ietf-acme-integrations-01 draft-ietf-acme-integrations-02
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 January 14, 2021. This Internet-Draft will expire on May 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . 3
4. ACME Integration with BRSKI . . . . . . . . . . . . . . . . . 6 4. ACME Integration with BRSKI . . . . . . . . . . . . . . . . . 6
5. ACME Integration with BRSKI Default Cloud Registrar . . . . . 8 5. ACME Integration with BRSKI Default Cloud Registrar . . . . . 8
6. ACME Integration with TEAP . . . . . . . . . . . . . . . . . 10 6. ACME Integration with TEAP . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Informative References . . . . . . . . . . . . . . . . . . . 14 8.1. Denial of Service against ACME infrastructure . . . . . . 15
Appendix A. Comments . . . . . . . . . . . . . . . . . . . . . . 15 9. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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:
skipping to change at page 4, line 39 skipping to change at page 4, line 39
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 |
+--------+ +--------+ +------+ +-----+ +--------+ +--------+ +------+ +-----+
| | | | | | | |
STEP 1: Pre-Authorization of parent domain STEP 1: Pre-Authorization of parent domain
| | | | | | | |
| | POST /newAuthz | | | | POST /newAuthz | |
| | "domain.com" | | | | "example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 authorizations | | | | 201 authorizations | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | Publish DNS TXT | | | | Publish DNS TXT | |
| | "domain.com" | | | | "example.com" | |
| |--------------------------------->| | |--------------------------------->|
| | | | | | | |
| | POST /challenge | | | | POST /challenge | |
| |--------------------->| | | |--------------------->| |
| | | Verify | | | | Verify |
| | |---------->| | | |---------->|
| | 200 status=valid | | | | 200 status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | Delete DNS TXT | | | | Delete DNS TXT | |
| | "domain.com" | | | | "example.com" | |
| |--------------------------------->| | |--------------------------------->|
| | | | | | | |
STEP 2: Pledge enrolls against RA STEP 2: Pledge enrolls against RA
| | | | | | | |
| GET /csrattrs | | | | GET /csrattrs | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| SEQUENCE {AttrOrOID} | | | | SEQUENCE {AttrOrOID} | | |
| SAN OID: | | | | SAN OID: | | |
| "pledgeid.domain.com"| | | | "pledge.example.com" | | |
|<---------------------| | | |<---------------------| | |
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledgeid.domain.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 | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 status=ready | | | | 201 status=ready | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /finalize | | | | POST /finalize | |
| | PKCS#10 CSR | | | | PKCS#10 CSR | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK status=valid | | | | 200 OK status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /certificate | | | | POST /certificate | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| | PEM | | | | PEM | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
STEP 4: Pledge retries enroll STEP 4: Pledge retries enroll
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledgeid.domain.com"| | | | "pledge.example.com" | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| PKCS#7 | | | | PKCS#7 | | |
| "pledgeid.domain.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 [I-D.ietf-anima-bootstrapping-keyinfra] is based upon EST
[RFC7030] and defines how to autonomically bootstrap PKI trust [RFC7030] and defines how to autonomically bootstrap PKI trust
anchors into devices via means of signed vouchers. EST certificate anchors into devices via means of signed vouchers. EST certificate
enrollment may then optionally take place after trust has been enrollment may then optionally take place after trust has been
established. BRKSI voucher exchange and trust establishment are established. BRKSI voucher exchange and trust establishment are
based on EST extensions and the certificate enrollment part of BRSKI based on EST extensions and the certificate enrollment part of BRSKI
skipping to change at page 7, line 9 skipping to change at page 7, line 9
The call flow illustrates the RA returning a 202 Retry-After response The call flow illustrates the RA returning a 202 Retry-After response
to the initial EST /simpleenroll API. This may be appropriate if to the initial EST /simpleenroll API. This may be appropriate if
processing of the /simpleenroll request and ACME interactions takes processing of the /simpleenroll request and ACME interactions takes
some timme to complete. some timme to complete.
+--------+ +--------+ +------+ +------+ +--------+ +--------+ +------+ +------+
| Pledge | | EST RA | | ACME | | MASA | | Pledge | | EST RA | | ACME | | MASA |
+--------+ +--------+ +------+ +------+ +--------+ +--------+ +------+ +------+
| | | | | | | |
NOTE: Pre-Authorization of "domain.com" is complete NOTE: Pre-Authorization of "example.com" is complete
| | | | | | | |
STEP 1: Pledge requests Voucher STEP 1: Pledge requests Voucher
| | | | | | | |
| POST /requestvoucher | | | | POST /requestvoucher | | |
|--------------------->| | | |--------------------->| | |
| | POST /requestvoucher | | | | POST /requestvoucher | |
| |--------------------------------->| | |--------------------------------->|
| | | | | | | |
| | 200 OK Voucher | | | | 200 OK Voucher | |
| |<---------------------------------| | |<---------------------------------|
skipping to change at page 7, line 31 skipping to change at page 7, line 31
|<---------------------| | | |<---------------------| | |
| | | | | | | |
STEP 2: Pledge enrolls against RA STEP 2: Pledge enrolls against RA
| | | | | | | |
| GET /csrattrs | | | | GET /csrattrs | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| SEQUENCE {AttrOrOID} | | | | SEQUENCE {AttrOrOID} | | |
| SAN OID: | | | | SAN OID: | | |
| "pledgeid.domain.com"| | | | "pledge.example.com" | | |
|<---------------------| | | |<---------------------| | |
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledgeid.domain.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 | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 status=ready | | | | 201 status=ready | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /finalize | | | | POST /finalize | |
| | PKCS#10 CSR | | | | PKCS#10 CSR | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK status=valid | | | | 200 OK status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /certificate | | | | POST /certificate | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| | PEM | | | | PEM | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
STEP 4: Pledge retries enroll STEP 4: Pledge retries enroll
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledgeid.domain.com"| | | | "pledge.example.com" | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| PKCS#7 | | | | PKCS#7 | | |
| "pledgeid.domain.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.friel-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 [[TODO ID-TBD]] and allows the specification of a defined in [I-D.friel-anima-brski-cloud], and allows the
bootstrap DNS domain is leveraged. This extension allows the cloud specification of a bootstrap EST domain, is leveraged. This
registrar to specify the local domain RA that the pledge should extension allows the cloud registrar to specify the local domain RA
connect to for the purposes of EST enrollment. that the pledge should connect to for the purposes of EST enrollment.
Similar to the sectiosn above, the client calls EST /csrattrs 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 "domain.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 (EST RA 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: | | |
| "pledgeid.domain.com"| | | | "pledge.example.com" | | |
|<---------------------| | | |<---------------------| | |
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledgeid.domain.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 | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 status=ready | | | | 201 status=ready | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /finalize | | | | POST /finalize | |
| | PKCS#10 CSR | | | | PKCS#10 CSR | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK status=valid | | | | 200 OK status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /certificate | | | | POST /certificate | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| | PEM | | | | PEM | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
STEP 4: Pledge retries enroll STEP 4: Pledge retries enroll
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledgeid.domain.com"| | | | "pledge.example.com" | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| PKCS#7 | | | | PKCS#7 | | |
| "pledgeid.domain.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
skipping to change at page 11, line 12 skipping to change at page 11, line 15
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 | |
| | "domain.com" | | | | "example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 authorizations | | | | 201 authorizations | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | Publish DNS TXT | | | | Publish DNS TXT | |
| | "domain.com" | | | | "example.com" | |
| |--------------------------------->| | |--------------------------------->|
| | | | | | | |
| | POST /challenge | | | | POST /challenge | |
| |--------------------->| | | |--------------------->| |
| | | Verify | | | | Verify |
| | |---------->| | | |---------->|
| | 200 status=valid | | | | 200 status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | Delete DNS TXT | | | | Delete DNS TXT | |
| | "domain.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/ | | |
skipping to change at page 13, line 14 skipping to change at page 13, line 17
|------------------------>| | | |------------------------>| | |
| | | | | | | |
| 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: | | |
| "pledgeid.domain.com"}| | | | "pledge.example.com"} | | |
|------------------------>| | | |------------------------>| | |
| | POST /newOrder | | | | POST /newOrder | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 status=ready | | | | 201 status=ready | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /finalize | | | | POST /finalize | |
| | PKCS#10 CSR | | | | PKCS#10 CSR | |
| | "pledgeid.domain.com"| | | | "pledge.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK status=valid | | | | 200 OK status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /certificate | | | | POST /certificate | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| | PEM | | | | PEM | |
| | "pledgeid.domain.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. IANA Considerations
[todo] This document does not make any requests to IANA.
8. Security Considerations 8. Security Considerations
[todo] This draft is informational and makes no changes to the referenced
specifications. All security considerations from these referenced
documents are applicable here:
o EST [RFC7030]
o BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]
o BRSKI Default Cloud Registrar [I-D.friel-anima-brski-cloud]
o TEAP [RFC7170] and TEAP Update and Extensions for Bootstrapping
[I-D.lear-eap-teap-brski]
Additionally, all Security Considerations in ACME in the following
areas are equally applicable to ACME Integrations.
The integration mechanisms proposed here will primarily use the
DNS-01 challenge documented in [RFC8555] section 8.4. The security
considerations in RFC8555 says:
The DNS is a common point of vulnerability for all of these
challenges. An entity that can provision false DNS records for a
domain can attack the DNS challenge directly and can provision false
A/AAAA records to direct the ACME server to send its HTTP validation
query to a remote server of the attacker's choosing.
It is expected that the TEAP-EAP server/EST Registrar will perform
DNS dynamic updates to a DNS primary server using [RFC3007] Dynamic
updates, secured with with either SIG(0), or TSIG keys.
A major source of vulnerability is the disclosure of these DNS key
records. An attacker that has access to them, can provision their
own certificates into the the name space of the entity.
For many uses, this may allow the attacker to get access to some
enterprise resource. When used to provision, for instance, a (SIP)
phone system this would permit an attacker to impersonate a
legitimate phone. Not only does this allow for redirection of phone
calls, but possibly also toll fraud.
Operators should consider restricting the integration server such
that it can only update the DNS records for a specific zone or zones
where ACME is required for client certificate enrolment automation.
For example, if all IoT devices in an organisation enrol using EST
against an EST RA, and all IoT devices will be issued certificates in
a subdomain under iot.example.com, then the integration server could
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
not allow updating of DNS records under any other example.com DNS
namespace.
When performing challenge fulfilment via writing files to HTTP
webservers, write access should only be granted to a specific set of
servers, and only to a specific set of directories for storage of
challenge files.
8.1. Denial of Service against ACME infrastructure
The intermdiate node (the TEAP-EAP server, or the EST Registrar)
should cache the resulting certificates such that if the
communication with the pledge is lost, subsequent attempts to enroll
will result in the cache certificate being returned.
As many ACME servers have per-day, per-IP and per-subjectAltName
limits, it is prudent not to request identical certificates too
often. This could be due to operator or installer error, with
multiple configuration resets occuring within a short period of time.
The cache should be keyed by the complete contents of the Certificate
Signing Request, and should not persist beyond the notAfter date in
the certificate.
This means that if the private/public keypair changes on the pledge,
then a new certificate will be issued. If the the requested
SubjectAltName changes, then a new certificate will be requested.
In a case where a device is simply factory reset, and enrolls again,
then the same certificate can be returned.
9. Informative References 9. Informative References
[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-02 "ACME for Subdomains", draft-friel-acme-subdomains-03
(work in progress), March 2020. (work in progress), October 2020.
[I-D.friel-anima-brski-cloud] [I-D.friel-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-02 (work Cloud Registrar", draft-friel-anima-brski-cloud-03 (work
in progress), May 2020. in progress), September 2020.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-41 (work in progress), April 2020. 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.
[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
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<https://www.rfc-editor.org/info/rfc3007>.
[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 15, line 19 skipping to change at page 17, line 5
[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>.
Appendix A. Comments
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. 47 change blocks. 
55 lines changed or deleted 136 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/