draft-ietf-acme-integrations-00.txt   draft-ietf-acme-integrations-01.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: July 23, 2020 R. Shekh-Yusef Expires: January 14, 2021 R. Shekh-Yusef
Avaya Auth0
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
January 20, 2020 July 13, 2020
ACME Integrations ACME Integrations
draft-ietf-acme-integrations-00 draft-ietf-acme-integrations-01
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 July 23, 2020. This Internet-Draft will expire on January 14, 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 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . 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. ACME Integration with TEAP-BRSKI . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Informative References . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . 16 Appendix A. Comments . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Comments . . . . . . . . . . . . . . . . . . . . . . 17 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:
o ACME integration with EST [RFC7030] o ACME integration with EST [RFC7030]
o ACME integration with BRSKI o ACME integration with BRSKI
[I-D.ietf-anima-bootstrapping-keyinfra] [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.friel-anima-brski-cloud]
o ACME integration with TEAP [RFC7170] o ACME integration with TEAP [RFC7170] and TEAP Update and
Extensions for Bootstrapping [I-D.lear-eap-teap-brski]
o ACME integration with TEAP-BRSKI [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 enrolment 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
optimisation 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
skipping to change at page 4, line 19 skipping to change at page 4, line 14
When the CA is logically "behind" the EST RA, EST does not specify When the CA is logically "behind" the EST RA, EST does not specify
how the RA communicates with the CA. EST section 1 states: how the RA communicates with the CA. EST section 1 states:
"The nature of communication between an EST server and a CA is not "The nature of communication between an EST server and a CA is not
described in this document." described in this document."
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 optimisation 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. This enables the EST
server to indicate to the client what attributes it expects the server to indicate to the client what attributes it expects the
client to include in the CSR request send in the /simpleenroll API. client to include in the CSR request sent in the /simpleenroll API.
For example, EST servers could use this mechanism to tell the client For example, EST servers could use this mechanism to tell the client
what fields to include in the CSR Subject and Subject Alternative what fields to include in the CSR Subject and Subject Alternative
Name fields. 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 ACME server is unable to issue a step and may be necessary if the interactions between the RA and the
certificate immediately. ACME server take some time to complete. The exact details of when
the RA returns a 202 Retry-After are implementation specific.
[[ TODO the 202 response should probably be returned by the EST RA
only if ACME returns newOrder 'pending' or finalize 'processing'
responses. How much detail should be included in this document? ]]
+--------+ +--------+ +------+ +-----+ +--------+ +--------+ +------+ +-----+
| 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" | | | | "domain.com" | |
| |--------------------->| | | |--------------------->| |
skipping to change at page 7, line 7 skipping to change at page 6, line 47
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.
Similar to the EST section above, the client calls EST /csrattrs API Similar to the EST section above, the client calls EST /csrattrs API
before calling the EST /simpleenroll API. This enables the server to before calling the EST /simpleenroll API. This enables the server to
indicate what fields the pledge should include in the CSR that the indicate what fields the pledge should include in the CSR that the
client sends in the /simpleenroll API. client sends in the /simpleenroll API.
[[ TODO: the same question about 202 handling details as outlined in The call flow illustrates the RA returning a 202 Retry-After response
the EST section apply here. ]] to the initial EST /simpleenroll API. This may be appropriate if
processing of the /simpleenroll request and ACME interactions takes
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 "domain.com" is complete
| | | | | | | |
STEP 1: Pledge requests Voucher STEP 1: Pledge requests Voucher
| | | | | | | |
| POST /requestvoucher | | | | POST /requestvoucher | | |
skipping to change at page 10, line 32 skipping to change at page 10, line 26
| 200 OK | | | | 200 OK | | |
| PKCS#7 | | | | PKCS#7 | | |
| "pledgeid.domain.com"| | | | "pledgeid.domain.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 does not define how the TEAP server within the tunnel. TEAP Update and Extensions for Bootstrapping
communicates with the CA. [I-D.lear-eap-teap-brski] defines extensions to TEAP that includes
additional TLVs for certificate enrollment and BRSKI handling inside
the TEAP tunnel. Neither TEAP [RFC7170] or TEAP Update and
Extensions for Bootstrapping [I-D.lear-eap-teap-brski] define how the
TEAP server communicates with the CA.
This section outlines how ACME could be used for communication This section outlines how ACME could be used for communication
between the TEAP server and the CA. The example call flow leverages between the TEAP server and the CA. The example call flow leverages
[I-D.friel-acme-subdomains] and shows the TEAP server proving [I-D.friel-acme-subdomains] and shows the TEAP server proving
ownership of a parent domain, with individual client certificates ownership of a parent domain, with individual client certificates
being subdomains under that parent domain. being subdomains under that parent domain.
The example illustrates the TEAP server sending a Request-Action TLV The example illustrates the TEAP server sending a Request-Action TLV
including a CSR-Attributes TLV instructing the peer to send a CSR- including a CSR-Attributes TLV instructing the peer to send a CSR-
Attributes TLV to the server. This enables the server to indicate Attributes TLV to the server. This enables the server to indicate
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.
[[ TODO: Hmm, this section probably needs to be deleted. It shows Althought not explicitly illustrated in this call flow, the Peer and
use of CSR-Attributes TLV which is not defined in RFC7170, and is TEAP Server could exchange BRSKI TLVs, and a BRSKI integration and
only introduced in draft-lear-eap-teap-brski. We likely need CSR- voucher exchange with a MASA server could take place over TEAP.
Attributes TLV for in band cert enrollment. ]] Whether a BRSKI TLV exchange takes place or not does not impact the
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" | | | | "domain.com" | |
| |--------------------->| | | |--------------------->| |
skipping to change at page 14, line 5 skipping to change at page 14, line 5
|<------------------------| | | |<------------------------| | |
| | | | | | | |
| EAP-Response/ | | | | EAP-Response/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {Result TLV=Success} | | | | {Result TLV=Success} | | |
|------------------------>| | | |------------------------>| | |
| | | | | | | |
| EAP-Success | | | | EAP-Success | | |
|<------------------------| | | |<------------------------| | |
7. ACME Integration with TEAP-BRSKI 7. IANA Considerations
TEAP-BRSKI [I-D.lear-eap-teap-brski] defines how to execute BRSKI at
layer 2 inside a TEAP tunnel. Similar to the TEAP proposal in the
previous section, BRSKI-TEAP leverages the existing TEAP PKXS#10 and
PKCS#7 mechanisms for certificate enrollment, and does not define how
the TEAP server communicates with the CA.
This section outlines how ACME could be used for communication
between the TEAP server and the CA, and how this fits in with the
TEAP-BRSKI proposal.
The TEAP server uses the CSR-Atributes TLV to tell the peer what
attributes to include in its CSR request.
[[ TODO: probably need to describe how Retry-After TLV can be used
when ACME returns newOrder 'pending' or finalize 'processing' ]]
+--------+ +-------------+ +------+ +------+
| Pledge | | TEAP-Server | | ACME | | MASA |
+--------+ +-------------+ +------+ +------+
| | | |
NOTE: Pre-Authorization of "domain.com" is complete
and EAP outer tunnel is established as outlined in
the previous section
| | | |
STEP 1: Perform BRSKI Flow
| | | |
| EAP-Request/ | | |
| Type=TEAP, | | |
| {Request-Action TLV: | | |
| Status=Failure, | | |
| Action=Process-TLV, | | |
| TLV=Request-Voucher, | | |
| TLV=Trusted-Server-Root,| | |
| TLV=CSR-Attributes, | | |
| TLV=PKCS#10} | | |
|<---------------------------| | |
| | | |
| EAP-Response/ | | |
| Type=TEAP, | | |
| {Request-Voucher TLV} | | |
|--------------------------->| RequestVoucher | |
| |-------------------/ | \------>|
| | Voucher | |
| |<------------------/ | \-------|
| EAP-Request/ | | |
| Type=TEAP, | | |
| {Voucher TLV} | | |
|<---------------------------| | |
| | | |
STEP 2: Retrieve CA Configuration
| | | |
| EAP-Response/ | | |
| Type=TEAP, | | |
| {Trusted-Server-Root TLV} | | |
|--------------------------->| | |
| | | |
| EAP-Request/ | | |
| Type=TEAP, | | |
| {Trusted-Server-Root TLV} | | |
|<---------------------------| | |
| | | |
| EAP-Response/ | | |
| Type=TEAP, | | |
| {CSR-Attributes TLV} | | |
|--------------------------->| | |
| | | |
| EAP-Request/ | | |
| Type=TEAP, | | |
| {CSR-Attributes TLV} | | |
|<---------------------------| | |
| | | |
STEP 3: Enroll for certificate
| | | |
| EAP-Response/ | | |
| Type=TEAP, | | |
| {PKCS#10 TLV: | | |
| "pledgeid.domain.com"} | | |
|--------------------------->| | |
| |POST /newOrder | |
| |"pledgeid.domain.com"| |
| |-------------------->| |
| | | |
| | 201 status=ready | |
| |<--------------------| |
| | | |
| |POST /finalize | |
| |PKCS#10 CSR | |
| |"pledgeid.domain.com"| |
| |-------------------->| |
| | | |
| | 200 OK status=valid | |
| |<--------------------| |
| | | |
| | POST /certificate | |
| |-------------------->| |
| | | |
| |200 OK | |
| |PEM | |
| |"pledgeid.domain.com"| |
| |<--------------------| |
| | | |
| EAP-Request/ | | |
| Type=TEAP, | | |
| {PKCS#7 TLV, | | |
| Result TLV=Success} | | |
|<---------------------------| | |
| | | |
| EAP-Response/ | | |
| Type=TEAP, | | |
| {Result TLV=Success} | | |
|--------------------------->| | |
| | | |
| EAP-Success | | |
|<---------------------------| | |
8. IANA Considerations
[todo] [todo]
9. Security Considerations 8. Security Considerations
[todo] [todo]
10. Informative References 9. Informative References
[I-D.friel-acme-subdomains] [I-D.friel-acme-subdomains]
Friel, O., Barnes, R., and T. Hollebeek, "ACME for Friel, O., Barnes, R., Hollebeek, T., and M. Richardson,
Subdomains", draft-friel-acme-subdomains-00 (work in "ACME for Subdomains", draft-friel-acme-subdomains-02
progress), October 2019. (work in progress), March 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-01 (work Cloud Registrar", draft-friel-anima-brski-cloud-02 (work
in progress), October 2019. in progress), May 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-34 (work in progress), January 2020. keyinfra-41 (work in progress), April 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>.
skipping to change at page 18, line 4 skipping to change at page 15, line 32
Owen Friel Owen Friel
Cisco Cisco
Email: ofriel@cisco.com Email: ofriel@cisco.com
Richard Barnes Richard Barnes
Cisco Cisco
Email: rlb@ipv.sx Email: rlb@ipv.sx
Rifaat Shekh-Yusef Rifaat Shekh-Yusef
Avaya Auth0
Email: rifaat.ietf@gmail.com Email: rifaat.s.ietf@gmail.com
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
 End of changes. 22 change blocks. 
159 lines changed or deleted 45 lines changed or added

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