[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                           O. Friel
Internet-Draft                                                 R. Barnes
Intended status: Standards Track                                   Cisco
Expires: January 3, 2020                                   July 02, 2019


                           ACME Integrations
                    draft-friel-acme-integrations-01

Abstract

   This document outlines multiple advanced use cases and integrations
   that ACME facilitates without any modifications or enhancements
   required to the base ACME specification.  These use cases are not
   immediately obvious from reading the ACME specification and thus are
   explicitly documented here.  The use cases include ACME issuance of
   subdomain certificates, and ACME integration with EST and TEAP.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Friel & Barnes           Expires January 3, 2020                [Page 1]


Internet-Draft                    ATLS                         July 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  ACME Issuance of Subdomain Certificates . . . . . . . . . . .   3
   4.  ACME Integration with EST . . . . . . . . . . . . . . . . . .   5
   5.  ACME Integration with BRSKI . . . . . . . . . . . . . . . . .   8
   6.  ACME Integration with TEAP  . . . . . . . . . . . . . . . . .  10
   7.  ACME Integration with TEAP-BRSKI  . . . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   10. Informative References  . . . . . . . . . . . . . . . . . . .  16
   Appendix A.  Comments . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   ACME [RFC8555] defines a protocol that a certificate authority (CA)
   and an applicant can use to automate the process of domain name
   ownership validation and X.509 (PKIX) certificate issuance.  The
   protocol is rich and flexible and enables multiple use cases that are
   not immediately obvious from reading the specification.  This
   document explicitly outlines multiple advanced ACME use cases
   including:

   o  ACME issuance of subdomain certificates

   o  ACME integration with EST [RFC7030]

   o  ACME integration with BRSKI
      [I-D.ietf-anima-bootstrapping-keyinfra]

   o  ACME integration with TEAP [RFC7170]

   o  ACME integration with TEAP-BRSKI draft-lear-eap-teap-brski

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The following terms are used in this document:



Friel & Barnes           Expires January 3, 2020                [Page 2]


Internet-Draft                    ATLS                         July 2019


   o  BRSKI: Bootstrapping Remote Secure Key Infrastructures
      [I-D.ietf-anima-bootstrapping-keyinfra]

   o  CA: Certificate Authority

   o  CMC: Certificate Management over CMS

   o  CSR: Certificate Signing Request

   o  EST: Enrollment over Secure Transport [RFC7030]

   o  FQDN: Fully Qualified Domain Name

   o  RA: PKI Registration Authority

   o  TEAP: Tunneled Extensible Authentication Protocol [RFC7170]

3.  ACME Issuance of Subdomain Certificates

   A typical ACME workflow for issuance of certificates is as follows:

   1.  client POSTs a newOrder request that contains a set of
       "identifiers"

   2.  server replies with a set of "authorizations" and a "finalize"
       URI

   3.  client sends POST-as-GET requests to retrieve the
       "authorizations", with the downloaded "authorization" object(s)
       containing the "identifier" that the client must prove control of

   4.  client proves control over the "identifier" in the
       "authorization" object by completing the specified challenge, for
       example, by publishing a DNS TXT record

   5.  client POSTs a CSR to the "finalize" API

   ACME places the following restrictions on "identifiers":

   o  section 7.1.4: the only type of "identifier" defined by the ACME
      specification is a fully qualified domain name: "The only type of
      identifier defined by this specification is a fully qualified
      domain name (type: "dns").  The domain name MUST be encoded in the
      form in which it would appear in a certificate."

   o  Section 7.4: the "identifier" in the CSR request must match the
      "identifier" in the newOrder request: "The CSR MUST indicate the




Friel & Barnes           Expires January 3, 2020                [Page 3]


Internet-Draft                    ATLS                         July 2019


      exact same set of requested identifiers as the initial newOrder
      request."

   o  Sections 8.3: the "identifier", or FQDN, in the "authorization"
      object must be used when fulfilling challenges via HTTP:
      "Construct a URL by populating the URL template ... where the
      domain field is set to the domain name being verified"

   o  Section 8.4: the "identifier", or FQDN, in the "authorization"
      object must be used when fulfilling challenges via DNS: "The
      client constructs the validation domain name by prepending the
      label "_acme-challenge" to the domain name being validated."

   ACME does not mandate that the "identifier" in a newOrder request
   matches the "identifier" in "authorization" objects.  This means that
   the ACME specification does not preclude an ACME server processing
   newOrder requests and issuing certificates for a subdomain without
   requiring a challenge to be fulfilled against that explicit
   subdomain.  ACME server policy could allow issuance of certificates
   for a subdomain to a client where the client only has to fulfill an
   authorization challenge for the parent domain.

   This allows a flow where a client proves ownership of "domain.com"
   and then successfully obtains a certificate for "sub.domain.com".
   The ACME pre-authorization flow makes most sense for this use case,
   and that is what is illustrated in the following call flow.

   The client could pre-authorize for the parent domain once, and then
   issue multiple newOrder requests for certificates for multiple
   subdomains.  This call flow illustrates the client only placing one
   newOrder request.

   +--------+             +------+     +-----+
   | Client |             | ACME |     | DNS |
   +--------+             +------+     +-----+
       |                      |           |
    STEP 1: Pre-Authorization of parent domain
       |                      |           |
       | POST /newAuthz       |           |
       |  "domain.com"        |           |
       |--------------------->|           |
       |                      |           |
       | 201 authorizations   |           |
       |<---------------------|           |
       |                      |           |
       | Publish DNS TXT      |           |
       | "domain.com"         |           |
       |--------------------------------->|



Friel & Barnes           Expires January 3, 2020                [Page 4]


Internet-Draft                    ATLS                         July 2019


       |                      |           |
       | POST /challenge      |           |
       |--------------------->|           |
       |                      | Verify    |
       |                      |---------->|
       | 200 status=valid     |           |
       |<---------------------|           |
       |                      |           |
       | Delete DNS TXT       |           |
       | "domain.com"         |           |
       |--------------------------------->|
       |                      |           |
    STEP 2: Place order for subdomain
       |                      |           |
       | POST /newOrder       |           |
       | "sub.domain.com"     |           |
       |--------------------->|           |
       |                      |           |
       | 201 status=ready     |           |
       |<---------------------|           |
       |                      |           |
       | POST /finalize       |           |
       | CSR "sub.domain.com" |           |
       |--------------------->|           |
       |                      |           |
       | 200 OK status=valid  |           |
       |<---------------------|           |
       |                      |           |
       | POST /certificate    |           |
       |--------------------->|           |
       |                      |           |
       | 200 OK               |           |
       | PKI "sub.domain.com" |           |
       |<---------------------|           |


4.  ACME Integration with EST

   EST [RFC7030] defines a mechanism for clients to enroll with a PKI
   Registration Authority by sending CMC messages over HTTP.  EST
   section 1 states:

   "Architecturally, the EST service is located between a Certification
   Authority (CA) and a client.  It performs several functions
   traditionally allocated to the Registration Authority (RA) role in a
   PKI."

   EST section 1.1 states that:



Friel & Barnes           Expires January 3, 2020                [Page 5]


Internet-Draft                    ATLS                         July 2019


   "For certificate issuing services, the EST CA is reached through the
   EST server; the CA could be logically "behind" the EST server or
   embedded within it."

   When the CA is logically "behind" the EST RA, EST does not specify
   how the RA communicates with the CA.  EST section 1 states:

   "The nature of communication between an EST server and a CA is not
   described in this document."

   This section outlines how ACME could be used for communication
   between the EST RA and the CA.  The example call flow shows the RA
   proving ownership of a parent domain, with individual client
   certificates being subdomains under that parent domain.  This is an
   optimisation that reduces DNS and ACME traffic overhead.  The RA
   could of course prove ownership of every explicit client certificate
   identifier.

   The call flow also illustrates how the Pledge inserts relevant domain
   information into the CSR Subject and Subject Alternative Name fields.

   [todo: The details of how the pledge determines what information to
   include in the CSR are TBD.  For example, the pledge could discover
   the DNS domain via DHCP Option 15, and prepend the identifier from
   the IDevID to this.

   Note also that EST https://tools.ietf.org/html/rfc7030#section-4.2.1
   states that the ChangeSubjectName attribute MAY be used, for example,
   if the Pledge uses its IDevID when requesting a CSR/LDevID with a
   different Subject, however this field does not appear to have
   widespread support across CAs.]

   +--------+             +--------+             +------+     +-----+
   | Pledge |             | EST RA |             | ACME |     | DNS |
   +--------+             +--------+             +------+     +-----+
       |                      |                      |           |
                  STEP 1: Pre-Authorization of parent domain
       |                      |                      |           |
       |                      | POST /newAuthz       |           |
       |                      |  "domain.com"        |           |
       |                      |--------------------->|           |
       |                      |                      |           |
       |                      | 201 authorizations   |           |
       |                      |<---------------------|           |
       |                      |                      |           |
       |                      | Publish DNS TXT      |           |
       |                      | "domain.com"         |           |
       |                      |--------------------------------->|



Friel & Barnes           Expires January 3, 2020                [Page 6]


Internet-Draft                    ATLS                         July 2019


       |                      |                      |           |
       |                      | POST /challenge      |           |
       |                      |--------------------->|           |
       |                      |                      | Verify    |
       |                      |                      |---------->|
       |                      | 200 status=valid     |           |
       |                      |<---------------------|           |
       |                      |                      |           |
       |                      | Delete DNS TXT       |           |
       |                      | "domain.com"         |           |
       |                      |--------------------------------->|
       |                      |                      |           |
                  STEP 2: Pledge enrolls against RA
       |                      |                      |           |
       | POST /simpleenroll   |                      |           |
       | PCSK#10 CSR          |                      |           |
       | "pledgeid.domain.com"|                      |           |
       |--------------------->|                      |           |
       |                      |                      |           |
       | 202 Retry-After      |                      |           |
       |<---------------------|                      |           |
       |                      |                      |           |
                  STEP 3: RA places ACME order
       |                      |                      |           |
       |                      | 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"|           |
       |                      |<---------------------|           |
       |                      |                      |           |
                  STEP 4: Pledge retries enroll



Friel & Barnes           Expires January 3, 2020                [Page 7]


Internet-Draft                    ATLS                         July 2019


       |                      |                      |           |
       | POST /simpleenroll   |                      |           |
       | PCSK#10 CSR          |                      |           |
       | "pledgeid.domain.com"|                      |           |
       |--------------------->|                      |           |
       |                      |                      |           |
       | 200 OK               |                      |           |
       | PKCS#7               |                      |           |
       | "pledgeid.domain.com"|                      |           |
       |<---------------------|                      |           |

5.  ACME Integration with BRSKI

   BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is based upon EST
   [RFC7030] and defines how to autonomically bootstrap PKI trust
   anchors into devices via means of signed vouchers.  EST certificate
   enrollment may then optionally take place after trust has been
   established.  BRKSI voucher exchange and trust establishment are
   based on EST extensions and the certificate enrollment part of BRSKI
   is fully based on EST.  Similar to EST, BRSKI does not define how the
   EST RA communicates with the CA.  Therefore, the mechanisms outlined
   in the previous section for using ACME as the communications protocol
   between the EST RA and the CA are equally applicable to BRSKI.

   The following call flow shows how ACME may be integrated into a full
   BRSKI voucher plus EST enrollment workflow.  For brevity, it assumes
   that the EST RA has previously proven ownership of a parent domain
   and that pledge certificate identifiers are a subdomain of that
   parent domain.  The domain ownership exchanges between the RA, ACME
   and DNS are not shown.  Similarly, not all BRSKI interactions are
   shown and only the key protocol flows involving voucher exchange and
   EST enrollment are shown.

   [todo: similar to the EST section above, it is TBD exactly how the
   pledge determines what domain information to insert in the CSR.  A
   possibility is that the Voucher response includes domain information
   and explicitly instructs the pledge what information to insert in the
   CSR.  The RA could also instruct the Pledge to include a guid or a
   new unique random identifier in place of its MAC address, serial
   number, or whatever other identifying information is included in the
   IDevID.

   +--------+             +--------+             +------+     +------+
   | Pledge |             | EST RA |             | ACME |     | MASA |
   +--------+             +--------+             +------+     +------+
       |                      |                      |           |
                  NOTE: Pre-Authorization of "domain.com" is complete
       |                      |                      |           |



Friel & Barnes           Expires January 3, 2020                [Page 8]


Internet-Draft                    ATLS                         July 2019


                  STEP 1: Pledge requests Voucher
       |                      |                      |           |
       | POST /requestvoucher |                      |           |
       |--------------------->|                      |           |
       |                      | POST /requestvoucher |           |
       |                      |--------------------------------->|
       |                      |                      |           |
       |                      | 200 OK Voucher       |           |
       |                      |<---------------------------------|
       | 200 OK Voucher       |                      |           |
       |<---------------------|                      |           |
       |                      |                      |           |
                  STEP 2: Pledge enrolls against RA
       |                      |                      |           |
       | POST /simpleenroll   |                      |           |
       | PCSK#10 CSR          |                      |           |
       | "pledgeid.domain.com"|                      |           |
       |--------------------->|                      |           |
       |                      |                      |           |
       | 202 Retry-After      |                      |           |
       |<---------------------|                      |           |
       |                      |                      |           |
                  STEP 3: RA places ACME order
       |                      |                      |           |
       |                      | 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"|           |
       |                      |<---------------------|           |
       |                      |                      |           |
                  STEP 4: Pledge retries enroll



Friel & Barnes           Expires January 3, 2020                [Page 9]


Internet-Draft                    ATLS                         July 2019


       |                      |                      |           |
       | POST /simpleenroll   |                      |           |
       | PCSK#10 CSR          |                      |           |
       | "pledgeid.domain.com"|                      |           |
       |--------------------->|                      |           |
       |                      |                      |           |
       | 200 OK               |                      |           |
       | PKCS#7               |                      |           |
       | "pledgeid.domain.com"|                      |           |
       |<---------------------|                      |           |

6.  ACME Integration with TEAP

   TEAP [RFC7170] define a tunnel-based EAP method that enables secure
   communication between a peer and a server by using TLS to establish a
   mutually authenticated tunnel.  TEAP enables certificate provisioning
   within the tunnel.  TEAP 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.  The example call flow shows the
   TEAP server proving ownership of a parent domain, with individual
   client certificates being subdomains under that parent domain.  This
   is an optimisation that reduces DNS and ACME traffic overhead.  The
   TEAP server could of course prove ownership of every explicit client
   certificate identifier.

   [todo: Similar to the previous section, it is TBD exactly how the
   Pledge determines what Subject/SAN to put in the CSR request.]

   +--------+             +-------------+           +------+     +-----+
   | Pledge |             | TEAP-Server |           | ACME |     | DNS |
   +--------+             +-------------+           +------+     +-----+
       |                         |                      |           |
                  STEP 1: Pre-Authorization of parent domain
       |                         |                      |           |
       |                         | POST /newAuthz       |           |
       |                         |  "domain.com"        |           |
       |                         |--------------------->|           |
       |                         |                      |           |
       |                         | 201 authorizations   |           |
       |                         |<---------------------|           |
       |                         |                      |           |
       |                         | Publish DNS TXT      |           |
       |                         | "domain.com"         |           |
       |                         |--------------------------------->|
       |                         |                      |           |
       |                         | POST /challenge      |           |



Friel & Barnes           Expires January 3, 2020               [Page 10]


Internet-Draft                    ATLS                         July 2019


       |                         |--------------------->|           |
       |                         |                      | Verify    |
       |                         |                      |---------->|
       |                         | 200 status=valid     |           |
       |                         |<---------------------|           |
       |                         |                      |           |
       |                         | Delete DNS TXT       |           |
       |                         | "domain.com"         |           |
       |                         |--------------------------------->|
       |                         |                      |           |
       |                         |                      |           |
                  STEP 2: Establsh EAP Outer Tunnel
       |                         |                      |           |
       |  EAP-Request/           |                      |           |
       |   Type=Identity         |                      |           |
       |<------------------------|                      |           |
       |                         |                      |           |
       |  EAP-Response/          |                      |           |
       |   Type=Identity         |                      |           |
       |------------------------>|                      |           |
       |                         |                      |           |
       |  EAP-Request/           |                      |           |
       |   Type=TEAP,            |                      |           |
       |   TEAP Start,           |                      |           |
       |   Authority-ID TLV      |                      |           |
       |<------------------------|                      |           |
       |                         |                      |           |
       |  EAP-Response/          |                      |           |
       |   Type=TEAP,            |                      |           |
       |   TLS(ClientHello)      |                      |           |
       |------------------------>|                      |           |
       |                         |                      |           |
       |  EAP-Request/           |                      |           |
       |   Type=TEAP,            |                      |           |
       |   TLS(ServerHello,      |                      |           |
       |   Certificate,          |                      |           |
       |   ServerKeyExchange,    |                      |           |
       |   CertificateRequest,   |                      |           |
       |   ServerHelloDone)      |                      |           |
       |<------------------------|                      |           |
       |                         |                      |           |
       |  EAP-Response/          |                      |           |
       |   Type=TEAP,            |                      |           |
       |   TLS(Certificate,      |                      |           |
       |   ClientKeyExchange,    |                      |           |
       |   CertificateVerify,    |                      |           |
       |   ChangeCipherSpec,     |                      |           |
       |   Finished)             |                      |           |



Friel & Barnes           Expires January 3, 2020               [Page 11]


Internet-Draft                    ATLS                         July 2019


       |------------------------>|                      |           |
       |                         |                      |           |
       |  EAP-Request/           |                      |           |
       |   Type=TEAP,            |                      |           |
       |   TLS(ChangeCipherSpec, |                      |           |
       |   Finished),            |                      |           |
       |   {Crypto-Binding TLV,  |                      |           |
       |   Result TLV=Success}   |                      |           |
       |<------------------------|                      |           |
       |                         |                      |           |
       |  EAP-Response/          |                      |           |
       |   Type=TEAP,            |                      |           |
       |   {Crypto-Binding TLV,  |                      |           |
       |   Result TLV=Success}   |                      |           |
       |------------------------>|                      |           |
       |                         |                      |           |
       |  EAP-Request/           |                      |           |
       |   Type=TEAP,            |                      |           |
       |   {Request-Action TLV:  |                      |           |
       |     Status=Failure,     |                      |           |
       |     Action=Process-TLV, |                      |           |
       |     TLV=PKCS#10}        |                      |           |
       |<------------------------|                      |           |
       |                         |                      |           |
                  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    |           |
       |                         |--------------------->|           |



Friel & Barnes           Expires January 3, 2020               [Page 12]


Internet-Draft                    ATLS                         July 2019


       |                         |                      |           |
       |                         | 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            |                      |           |
       |<------------------------|                      |           |


7.  ACME Integration with TEAP-BRSKI

   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.

   [todo: Similar to the previous section, it is TBD exactly how the
   Pledge determines what Subject/SAN to put in the CSR request.]

   +--------+                +-------------+         +------+   +------+
   | 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,                |                     |         |



Friel & Barnes           Expires January 3, 2020               [Page 13]


Internet-Draft                    ATLS                         July 2019


       |  {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:            |                     |         |



Friel & Barnes           Expires January 3, 2020               [Page 14]


Internet-Draft                    ATLS                         July 2019


       |   "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]








Friel & Barnes           Expires January 3, 2020               [Page 15]


Internet-Draft                    ATLS                         July 2019


9.  Security Considerations

   [todo]

10.  Informative References

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-22 (work in progress), June 2019.

   [I-D.lear-eap-teap-brski]
              Lear, E., Friel, O., and N. Cam-Winget, "Bootstrapping Key
              Infrastructure over EAP", draft-lear-eap-teap-brski-02
              (work in progress), February 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

   [RFC7170]  Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
              "Tunnel Extensible Authentication Protocol (TEAP) Version
              1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
              <https://www.rfc-editor.org/info/rfc7170>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/info/rfc8555>.

Appendix A.  Comments

Authors' Addresses







Friel & Barnes           Expires January 3, 2020               [Page 16]


Internet-Draft                    ATLS                         July 2019


   Owen Friel
   Cisco

   Email: ofriel@cisco.com


   Richard Barnes
   Cisco

   Email: rlb@ipv.sx









































Friel & Barnes           Expires January 3, 2020               [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/