Skip to main content

BRSKI Cloud Registrar
draft-ietf-anima-brski-cloud-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Owen Friel , Rifaat Shekh-Yusef , Michael Richardson
Last updated 2023-05-17 (Latest revision 2022-11-13)
Replaces draft-friel-anima-brski-cloud
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Sheng Jiang
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to jiangsheng@huawei.com
draft-ietf-anima-brski-cloud-06
Network Working Group                                           O. Friel
Internet-Draft                                                     Cisco
Intended status: Standards Track                          R. Shekh-Yusef
Expires: 18 November 2023                                          Auth0
                                                           M. Richardson
                                                Sandelman Software Works
                                                             17 May 2023

                         BRSKI Cloud Registrar
                    draft-ietf-anima-brski-cloud-06

Abstract

   Bootstrapping Remote Secure Key Infrastructures defines how to
   onboard a device securely into an operator maintained infrastructure.
   It assumes that there is local network infrastructure for the device
   to discover and to help the device.  This document extends the new
   device behaviour so that if no local infrastructure is available,
   such as in a home or remote office, that the device can use a well
   defined "call-home" mechanism to find the operator maintained
   infrastructure.

   To this, this document defines how to contact a well-known cloud
   registrar, and two ways in which the new device may be redirected
   towards the operator maintained infrastructure.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/.

   Discussion of this document takes place on the anima Working Group
   mailing list (mailto:anima@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/anima/.

   Source for this draft and an issue tracker can be found at
   https://github.com/anima-wg/brski-cloud.

Status of This Memo

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

Friel, et al.           Expires 18 November 2023                [Page 1]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   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 18 November 2023.

Copyright Notice

   Copyright (c) 2023 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Target Use Cases  . . . . . . . . . . . . . . . . . . . .   4
       1.2.1.  Owner Registrar Discovery . . . . . . . . . . . . . .   4
       1.2.2.  Bootstrapping with no Owner Registrar . . . . . . . .   5
   2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Network Connectivity  . . . . . . . . . . . . . . . . . .   7
     2.2.  Pledge Certificate Identity Considerations  . . . . . . .   7
   3.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Pledge Requests Voucher from Cloud Registrar  . . . . . .   8
       3.1.1.  Cloud Registrar Discovery . . . . . . . . . . . . . .   8
       3.1.2.  Pledge - Cloud Registrar TLS Establishment Details  .   8
       3.1.3.  Pledge Issues Voucher Request . . . . . . . . . . . .   9
     3.2.  Cloud Registrar Handles Voucher Request . . . . . . . . .   9
       3.2.1.  Pledge Ownership Lookup . . . . . . . . . . . . . . .   9
       3.2.2.  Cloud Registrar Redirects to Owner Registrar  . . . .  10
       3.2.3.  Cloud Registrar Issues Voucher  . . . . . . . . . . .  10
     3.3.  Pledge Handles Cloud Registrar Response . . . . . . . . .  10
       3.3.1.  Redirect Response . . . . . . . . . . . . . . . . . .  10
       3.3.2.  Voucher Response  . . . . . . . . . . . . . . . . . .  11

Friel, et al.           Expires 18 November 2023                [Page 2]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   4.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  Voucher Request Redirected to Local Domain Registrar  . .  11
     4.2.  Voucher Request Handled by Cloud Registrar  . . . . . . .  13
   5.  YANG extension for Voucher based redirect . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     7.1.  Issues with Security of HTTP Redirect . . . . . . . . . .  16
     7.2.  Security Updates for the Pledge . . . . . . . . . . . . .  17
     7.3.  Trust Anchors for Cloud Registrar . . . . . . . . . . . .  17
     7.4.  Issues with Redirect via Voucher  . . . . . . . . . . . .  18
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   Bootstrapping Remote Secure Key Infrastructures [BRSKI] and [RFC8994]
   specifies automated network onboarding of devices, referred to as
   pledges, within an Autonomic Control Plane or other managed network
   infrastructure.  BRSKI Section 2.7 describes how a pledge "MAY
   contact a well-known URI of a cloud registrar if a local registrar
   cannot be discovered or if the pledge's target use cases do not
   include a local registrar".

   This document further specifies use of a BRSKI cloud registrar and
   clarifies operations that are not sufficiently specified in BRSKI.

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

   This document uses the terms Pledge, Registrar, MASA, and Voucher
   from [BRSKI] and [RFC8366].

   Local Domain:  The domain where the pledge is physically located and
      bootstrapping from.  This may be different to the pledge owner's
      domain.

   Owner Domain:  The domain that the pledge needs to discover and
      bootstrap with.

   Cloud Registrar:  The default Registrar that is deployed at a URI
      that is well known to the pledge.

Friel, et al.           Expires 18 November 2023                [Page 3]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   Owner Registrar:  The Registrar that is operated by the Owner, or the
      Owner's delegate.  There may not be an Owner Registrar in all
      deployment scenarios.

   Local Domain Registrar:  The Registrar discovered on the Local
      Domain.  There may not be a Local Domain Registrar in all
      deployment scenarios.

   EST:  Enrollment over Secure Transport [RFC7030]

   VAR:  Value Added Reseller

1.2.  Target Use Cases

   Two high level use cases are documented here.  There are more details
   provided in sections Section 4.1 and Section 4.2.  While both use
   cases aid with incremental deployment of BRSKI infrastructure, for
   many smaller sites (such as teleworkers) no further infrastructure is
   expected.

   The pledge is not expected to know which of these two situations it
   is in.  The pledge determines this based upon signals that it
   receives from the Cloud Registrar.  The Cloud Registrar is expected
   to make the determination based upon the identity presented by the
   pledge.

   A Cloud Registrar will typically handle all the devices of a
   particular product line from a particular manufacturer.  This
   document places no restrictions on how many different deployments or
   owner sites the Cloud Registrar can handle, or how many devices per
   site that the Cloud Registrar can handle.  It is also entirely
   possible that all devices sold by through a particular Value Added
   Reseller (VAR) might be preloaded with a configuration that changes
   the Cloud Registrar URL to point to a VAR.  Such an effort would
   require unboxing each device in a controlled environment, but the
   provisioning could occur using a regular BRSKI or SZTP [RFC8572]
   process.

1.2.1.  Owner Registrar Discovery

   A pledge is bootstrapping from a remote location with no local domain
   registrar (specifically: with no local infrastructure to provide for
   automated discovery), and needs to discover its owner registrar.  The
   cloud registrar is used by the pledge to discover the owner
   registrar.  The cloud registrar redirects the pledge to the owner
   registrar, and the pledge completes bootstrap against the owner
   registrar.

Friel, et al.           Expires 18 November 2023                [Page 4]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   A typical example is an enduser deploying a pledge in a home or small
   branch office, where the pledge belongs to the enduser's employer.
   There is no local domain registrar, and the pledge needs to discover
   and bootstrap with the employer's registrar which is deployed in
   headquarters.  For example, an enduser is deploying an IP phone in a
   home office and the phone needs to register to an IP PBX deployed in
   their employer's office.

1.2.2.  Bootstrapping with no Owner Registrar

   A pledge is bootstrapping where the owner organization does not yet
   have an owner registrar deployed.  The cloud registrar issues a
   voucher, and the pledge completes trust bootstrap using the cloud
   registrar.  The voucher issued by the cloud includes domain
   information for the owner's Enrollment over Secure Transport (EST)
   [RFC7030] service the pledge should use for certificate enrollment.

   In one use case, an organization has an EST service deployed, but
   does not have yet a BRSKI capable Registrar service deployed.  The
   pledge is deployed in the organization's domain, but does not
   discover a local domain registrar or owner registrar.  The pledge
   uses the cloud registrar to bootstrap, and the cloud registrar
   provides a voucher that includes instructions on finding the
   organization's EST service.

2.  Architecture

   The high level architecture is illustrated in Figure 1.

   The pledge connects to the cloud registrar during bootstrap.

   The cloud registrar may redirect the pledge to an owner registrar in
   order to complete bootstrap against the owner registrar.

   If the cloud registrar issues a voucher itself without redirecting
   the pledge to an owner registrar, the cloud registrar will inform the
   pledge what domain to use for accessing EST services in the voucher
   response.

   Finally, when bootstrapping against an owner registrar, this
   registrar may interact with a backend CA to assist in issuing
   certificates to the pledge.  The mechanisms and protocols by which
   the registrar interacts with the CA are transparent to the pledge and
   are out-of-scope of this document.

   The architecture shows the cloud registrar and MASA as being
   logically separate entities.  The two functions could of course be
   integrated into a single service.

Friel, et al.           Expires 18 November 2023                [Page 5]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   There are two different mechanisms for a cloud registrar to handle
   voucher requests.  It can redirect the request to Owner Registrar for
   handling, or it can return a voucher that pins the actual Owner
   Register.  When returning a voucher, additional bootstrapping
   information embedded in the voucher.  Both mechanisms are described
   in detail later in this document.

   |<--------------OWNER--------------------------->|   MANUFACTURER

    On-site                Cloud
   +--------+                                          +-----------+
   | Pledge |----------------------------------------->| Cloud     |
   +--------+                                          | Registrar |
       |                                               +-----+-----+
       |                                                     |
       |                 +-----------+                 +-----+-----+
       +---------------->|  Owner    |---------------->|   MASA    |
       |   VR-sign(N)    | Registrar |sign(VR-sign(N)) +-----------+
       |                 +-----------+
       |                       |    +-----------+
       |                       +--->|    CA     |
       |                            +-----------+
       |
       |                 +-----------+
       +---------------->| Services  |
                         +-----------+

                     Figure 1: High Level Architecture

   As depicted in Figure 1, there are a number of parties involve in the
   process.  The Manufacturer, or Original Equipment Maker (OEM) builds
   the device, but also is expected to run the MASA, or arrange for it
   to exist.

   The network operator or enterprise is the intended owner of the new
   device: the pledge.  This could be the enterprise itself, or in many
   cases there is some outsourced IT department that might be involved.
   They operator the Registrar or EST Server.  They may operate the CA,
   or they may contract those services from another entity.

   Unlike in [BRSKI] there is a potential additional party involved, the
   network integrator, who may operate the Cloud Registrar.  This is
   typically a value added reseller who works with the OEM to ship
   products with the right configuration to the owner.  For example, SIP
   telephones or other conferencing systems may be installed by this
   VAR, often shipped directly from a warehouse to the customer's remote
   office location.  The network integrator and manufacturer are aware
   of which devices have been shipped to the integrator through sales

Friel, et al.           Expires 18 November 2023                [Page 6]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   channel integrations, and so the manufacturer's Cloud Registrar is
   able to redirect the pledge through a chain of Cloud Registrars, as
   explained in Section 3.3.1.

2.1.  Network Connectivity

   The assumption is that the pledge already has network connectivity
   prior to connecting to the cloud registrar.  The pledge must have an
   IP address that is able to make DNS queries, and be able to send HTTP
   requests to the cloud registrar.  There are many ways to accomplish
   this, from routeable IPv4 or IPv6 addresses, to use of NAT44, to
   using HTTP or SOCKS proxies.  There are are DHCP options that a
   network operator can configure to accomplish any of these options.
   The pledge operator has already connected the pledge to the network,
   and the mechanism by which this has happened is out of scope of this
   document.  For many telephony applications, this is typically going
   to be a wired connection.  For wireless use cases, some kind of
   existing WiFi onboarding mechanism such as WPS.  Similarly, what
   address space the IP address belongs to, whether it is an IPv4 or
   IPv6 address, or if there are firewalls or proxies deployed between
   the pledge and the cloud registar are all out of scope of this
   document.

2.2.  Pledge Certificate Identity Considerations

   BRSKI section 5.9.2 specifies that the pledge MUST send an EST
   [RFC7030] CSR Attributes request to the registrar.  The registrar MAY
   use this mechanism to instruct the pledge about the identities it
   should include in the CSR request it sends as part of enrollment.
   The registrar may use this mechanism to tell the pledge what Subject
   or Subject Alternative Name identity information to include in its
   CSR request.  This can be useful if the Subject must have a specific
   value in order to complete enrollment with the CA.

   EST [RFC7030] is not clear on how the CSR Attributes response should
   be structured, and in particular is not clear on how a server can
   instruct a client to include specific attribute values in its CSR.
   [I-D.ietf-lamps-rfc7030-csrattrs] clarifies how a server can use CSR
   Attributes response to specify specific values for attributes that
   the client should include in its CSR.

   For example, the pledge may only be aware of its IDevID Subject which
   includes a manufacturer serial number, but must include a specific
   fully qualified domain name in the CSR in order to complete domain
   ownership proofs required by the CA.

Friel, et al.           Expires 18 November 2023                [Page 7]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   As another example, the registrar may deem the manufacturer serial
   number in an IDevID as personally identifiable information, and may
   want to specify a new random opaque identifier that the pledge should
   use in its CSR.

3.  Protocol Operation

3.1.  Pledge Requests Voucher from Cloud Registrar

3.1.1.  Cloud Registrar Discovery

   BRSKI defines how a pledge MAY contact a well-known URI of a cloud
   registrar if a local domain registrar cannot be discovered.
   Additionally, certain pledge types might never attempt to discover a
   local domain registrar and might automatically bootstrap against a
   cloud registrar.

   The details of the URI are manufacturer specific, with BRSKI giving
   the example "brski-registrar.manufacturer.example.com".

   The Pledge SHOULD be provided with the entire URL of the Cloud
   Registrar, including the path component, which is typically "/.well-
   known/brski/requestvoucher", but may be another value.

3.1.2.  Pledge - Cloud Registrar TLS Establishment Details

   The pledge MUST use an Implicit Trust Anchor database (see EST
   [RFC7030]) to authenticate the cloud registrar service.  In order to
   make use of a Cloud Registrar, the Pledge MUST be manufactured with
   pre-loaded trust-anchors that are used to validate the TLS
   connection.  The TLS connection can be validated using a public Web
   PKI trust anchors using [RFC6125] DNS-ID mechanisms, a pinned
   certification authority, or even a pinned raw public key.  This is a
   local implementation decision.

   The pledge MUST NOT establish a provisional TLS connection (see BRSKI
   section 5.1) with the cloud registrar.

   The cloud registrar MUST validate the identity of the pledge by
   sending a TLS CertificateRequest message to the pledge during TLS
   session establishment.  The cloud registrar MAY include a
   certificate_authorities field in the message to specify the set of
   allowed IDevID issuing CAs that pledges may use when establishing
   connections with the cloud registrar.

   The cloud registrar MAY only allow connections from pledges that have
   an IDevID that is signed by one of a specific set of CAs, e.g.
   IDevIDs issued by certain manufacturers.

Friel, et al.           Expires 18 November 2023                [Page 8]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   The cloud registrar MAY allow pledges to connect using self-signed
   identity certificates or using Raw Public Key [RFC7250] certificates.

3.1.3.  Pledge Issues Voucher Request

   After the pledge has established a full TLS connection with the cloud
   registrar and has verified the cloud registrar PKI identity, the
   pledge generates a voucher request message as outlined in BRSKI
   section 5.2, and sends the voucher request message to the cloud
   registrar.

3.2.  Cloud Registrar Handles Voucher Request

   The cloud registrar must determine pledge ownership. if the registrar
   is unwilling or unable to handle the voucher request, for example it
   is unable to determine ownership, then the cloud registrar MUST
   return a suitable 4xx or 5xx error response to the pledge.

   If the cloud registrar successfully determines ownership, then the
   registrar MUST take one of the following actions:

   *  return a suitable 4xx or 5xx error response to the pledge if the
      registrar is unwilling or unable to handle the voucher request for
      any reason

   *  redirect the pledge to an owner register via 307 response code

   *  issue a voucher and return a 200 response code

3.2.1.  Pledge Ownership Lookup

   The cloud registrar needs some suitable mechanism for knowing the
   correct owner of a connecting pledge based on the presented identity
   certificate.  For example, if the pledge establishes TLS using an
   IDevID that is signed by a known manufacturing CA, the registrar
   could extract the serial number from the IDevID and use this to
   lookup a database of pledge IDevID serial numbers to owners.

   Alternatively, if the cloud registrar allows pledges to connect using
   self-signed certificates, the registrar could use the thumbprint of
   the self-signed certificate to lookup a database of pledge self-
   signed certificate thumbprints to owners.

   The mechanism by which the cloud registrar determines pledge
   ownership is out-of-scope of this document.

Friel, et al.           Expires 18 November 2023                [Page 9]
Internet-Draft                 BRSKI-CLOUD                      May 2023

3.2.2.  Cloud Registrar Redirects to Owner Registrar

   Once the cloud registrar has determined pledge ownership, the cloud
   registrar MAY redirect the pledge to the owner registrar in order to
   complete bootstrap.  Ownership registration will require the owner to
   register their local domain.  The mechanism by which pledge owners
   register their domain with the cloud registrar is out-of-scope of
   this document.

   The cloud registrar replies to the voucher request with a suitable
   HTTP 307 response code, including the owner's local domain in the
   HTTP Location header.

3.2.3.  Cloud Registrar Issues Voucher

   If the cloud registrar issues a voucher, it returns the voucher in a
   HTTP response with a 200 response code.

   The cloud registrar MAY issue a 202 response code if it is willing to
   issue a voucher, but will take some time to prepare the voucher.

   The voucher MUST include the "est-domain" field as defined below.
   This tells the pledge where the domain of the EST service to use for
   completing certificate enrollment.

   The voucher MAY include the "additional-configuration" field.  This
   points the pledge to a URI where application specific additional
   configuration information may be retrieved.  Pledge and Registrar
   behavior for handling and specifying the "additional-configuration"
   field is out-of-scope of this document.

3.3.  Pledge Handles Cloud Registrar Response

3.3.1.  Redirect Response

   The cloud registrar returned a 307 response to the voucher request.

   The pledge SHOULD restart the process using a new voucher request
   using the location provided in the HTTP redirect.  Note if the pledge
   is able to validate the new server using a trust anchor found in its
   Implicit Trust Anchor database, then it MAY accept additional 307
   redirects.redirect.  The pledge MUST never visit a location that it
   has already been to.  If that happens then the pledge MUST fail the
   onboarding attempt and go back to the beginning, which includes
   listening to other sources of onboarding information as specified in
   [BRSKI] section 4.1 and 5.0.

Friel, et al.           Expires 18 November 2023               [Page 10]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   The pledge SHOULD establish a provisional TLS connection with
   specified local domain registrar.  The pledge SHOULD NOT use its
   Implicit Trust Anchor database for validating the local domain
   registrar identity.  The pledge SHOULD send a voucher request message
   via the local domain registrar.  When the pledge downloads a voucher,
   it can validate the TLS connection to the local domain registrar and
   continue with enrollment and bootstrap as per standard BRSKI
   operation.

3.3.2.  Voucher Response

   The cloud registrar returned a voucher to the pledge.  The pledge
   SHOULD perform voucher verification as per standard BRSKI operation.
   The pledge SHOULD verify the voucher signature using the
   manufacturer-installed trust anchor(s), SHOULD verify the serial
   number in the voucher, and SHOULD verify any nonce information in the
   voucher.

   The pledge SHOULD extract the "est-domain" field from the voucher,
   and SHOULD continue with EST enrollment as per standard BRSKI
   operation.

4.  Protocol Details

4.1.  Voucher Request Redirected to Local Domain Registrar

   This flow illustrates the Owner Registrar Discovery flow.  A pledge
   is bootstrapping in a remote location with no local domain registrar.
   The assumption is that the owner registrar domain is accessible and
   the pledge can establish a network connection with the owner
   registrar.  This may require that the owner network firewall exposes
   the registrar on the public internet.

Friel, et al.           Expires 18 November 2023               [Page 11]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   +--------+                                       +----------+
   | Pledge |                                       | Cloud RA |
   |        |                                       |          |
   +--------+                                       +----------+
       |                                                 |
       | 1. Mutual-authenticated TLS                     |
       |<----------------------------------------------->|
       |                                                 |
       | 2. Voucher Request                              |
       |------------------------------------------------>|
       |                                                 |
       | 3. 307 Location: owner-ra.example.com           |
       |<------------------------------------------------|
       |
       |                  +-----------+             +---------+
       |                  | Owner     |             |  MASA   |
       |                  | Registrar |             |         |
       |                  +-----------+             +---------+
       | 4. Provisional TLS   |                          |
       |<-------------------->|                          |
       |                      |                          |
       | 5. Voucher Request   |                          |
       |--------------------->| 6. Voucher Request       |
       |                      |------------------------->|
       |                      |                          |
       |                      | 7. Voucher Response      |
       |                      |<-------------------------|
       | 8. Voucher Response  |                          |
       |<---------------------|                          |
       |                      |                          |
       | 9. Validate TLS      |                          |
       |<-------------------->|                          |
       |                      |                          |
       | 10. etc.             |                          |
       |--------------------->|                          |

   The process starts, in step 1, when the Pledge establishes a Mutual
   TLS channel with the Cloud RA using artifacts created during the
   manufacturing process of the Pledge.

   In step 2, the Pledge sends a voucher request to the Cloud RA.

   The Cloud RA completes pledge ownership lookup as outlined in
   Section 3.2.1, and determines the owner registrar domain.  In step 3,
   the Cloud RA redirects the pledge to the owner registrar domain.

Friel, et al.           Expires 18 November 2023               [Page 12]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   Steps 4 and onwards follow the standard BRSKI flow.  The pledge
   establishes a provisional TLS connection with the owner registrar,
   and sends a voucher request to the owner registrar.  The registrar
   forwards the voucher request to the MASA.  Assuming the MASA issues a
   voucher, then the pledge validates the TLS connection with the
   registrar using the pinned-domain-cert from the voucher and completes
   the BRSKI flow.

4.2.  Voucher Request Handled by Cloud Registrar

   The Voucher includes the EST domain to use for EST enroll.  It is
   assumed services are accessed at that domain too.  As trust is
   already established via the Voucher, the pledge does a full TLS
   handshake against the local RA indicated by the voucher response.

   The returned voucher contains an attribute, "est-domain", defined in
   Section 5 below.  The pledge is directed to continue enrollment using
   the EST server found at that URI.  The pledge uses the pinned-domain-
   cert from the voucher to authenticate the EST server.

Friel, et al.           Expires 18 November 2023               [Page 13]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   +--------+                                       +----------+
   | Pledge |                                       | Cloud RA |
   |        |                                       | / MASA   |
   +--------+                                       +----------+
       |                                                 |
       | 1. Mutual TLS                                   |
       |<----------------------------------------------->|
       |                                                 |
       | 2. Voucher Request                              |
       |------------------------------------------------>|
       |                                                 |
       | 3. Voucher Response  {est-domain:fqdn}          |
       |<------------------------------------------------|
       |                                                 |
       |                 +----------+                    |
       |                 | RFC7030  |                    |
       |                 | EST      |                    |
       |                 | Server   |                    |
       |                 +----------+                    |
       |                      |                          |
       | 4. Full TLS          |                          |
       |<-------------------->|                          |
       |                                                 |
       |     3a. /voucher_status POST  success           |
       |------------------------------------------------>|
       |     ON FAILURE 3b. /voucher_status POST         |
       |                                                 |
       | 5. EST Enrol         |                          |
       |--------------------->|                          |
       |                      |                          |
       | 6. Certificate       |                          |
       |<---------------------|                          |
       |                      |                          |
       | 7. /enrollstatus     |                          |
       |--------------------->|                          |

   The process starts, in step 1, when the Pledge establishes a Mutual
   TLS channel with the Cloud RA/MASA using artifacts created during the
   manufacturing process of the Pledge.  In step 2, the Pledge sends a
   voucher request to the Cloud RA/MASA, and in response the Pledge
   receives an [RFC8366] format voucher from the Cloud RA/MASA that
   includes its assigned EST domain in the est-domain attribute.

   At this stage, the Pledge should be able to establish a TLS channel
   with the EST server.  The connection may involve crossing the
   Internet requiring a DNS lookup on the provided name.  It may also be
   a local address that includes an IP address literal including both
   [RFC1918] and IPv6 Unique Local Address.  The EST server is validated

Friel, et al.           Expires 18 November 2023               [Page 14]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   using the pinned-domain-cert value provided in the voucher as
   described in [BRSKI] section 5.6.2.  This involves treating the
   artifact provided in the pinned-domain-cert as a trust anchor, and
   attempting to validate the EST server from this anchor only.

   There is a case where the pinned-domain-cert is the identical End-
   Entity (EE) Certificate as the EST server.  It also explicitly
   includes the case where the EST server has a self-signed EE
   Certificate, but it may also be an EE certificate that is part of a
   larger PKI.  If the certificate is not a self-signed or EE
   certificate, then the Pledge SHOULD apply [RFC6125] DNS-ID validation
   on the certificate against the URL provided in the est-domain
   attribute.  If the est-domain was provided by with an IP address
   literal, then it is unlikely that it can be validated, and in that
   case, it is expected that either a self-signed certificate or an EE
   certificate will be pinned.

   The Pledge also has the details it needs to be able to create the CSR
   request to send to the RA based on the details provided in the
   voucher.

   In step 4, the Pledge establishes a TLS channel with the Cloud RA/
   MASA, and optionally the pledge should send a request, steps 3.a and
   3.b, to the Cloud RA/MASA to inform it that the Pledge was able to
   establish a secure TLS channel with the EST server.

   The Pledge then follows that, in step 5, with an EST Enroll request
   with the CSR and obtains the requested certificate.  The Pledge must
   validate that the issued certificate has the expected identifier
   obtained from the Cloud RA/MASA in step 3.

5.  YANG extension for Voucher based redirect

   [RFC8366bis] contains the two needed voucher extensions: est-domain
   and additional-configuration which are needed when a client is
   redirected to a local EST server.

6.  IANA Considerations

   This document makes no IANA requests.

7.  Security Considerations

   The Cloud-Registrar described in this document inherits all of the
   issues that are described in [BRSKI].  This includes dependency upon
   continued operation of the manufacturer provided MASA, as well as
   potential complications where a manufacturer might interfere with
   resale of a device.

Friel, et al.           Expires 18 November 2023               [Page 15]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   In addition to the dependency upon the MASA, the successful
   enrollment of a device using a Cloud Registrar depends upon the
   correct and continued operation of this new service.  This internet
   accessible service may be operated by the manufacturer and/or by one
   or more value-added-resellers.  All of the considerations for
   operation of the MASA also apply to operation of the Cloud Registrar.

7.1.  Issues with Security of HTTP Redirect

   If the Redirect to Registrar method is used, as described in
   Section 4.1, there may be a series of 307 redirects.  An example of
   why this might occur is that the manufacturer only knows that it
   resold the device to a particular value added reseller (VAR), and
   there may be a chain of such VARs.  It is important the pledge avoid
   being drawn into a loop of redirects.  This could happen if a VAR
   does not think they are authoritative for a particular device.  A
   "helpful" programmer might instead decide to redirect back to the
   manufacturer in an attempt to restart at the top: perhaps there is
   another process that updates the manufacturer's database and this
   process is underway.  Instead, the VAR MUST return a 404 error if it
   cannot process the device.  This will force the device to stop,
   timeout, and then try all mechanisms again.

   There is another case where a connection problem may occur: when the
   pledge is behind a captive portal or an intelligent home gateway that
   provides access control on all connections.  Captive portals that do
   not follow the requirements of [RFC8952] section 1 may forcibly
   redirect HTTPS connections.  While this is a deprecated practice as
   it breaks TLS in a way that most users can not deal with, it is still
   common in many networks.

   On the first connection, the incorrect connection will be discovered
   because the Pledge will be unable to validate the connection to its
   cloud registrar via DNS-ID.  That is, the certificate returned from
   the captive portal will not match.

   At this point a network operator who controls the captive portal,
   noticing the connection to what seems a legitimate destination (the
   cloud registrar), may then permit that connection.  This enables the
   first connection to go through.

Friel, et al.           Expires 18 November 2023               [Page 16]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   The connection is then redirected to the Registrar, either via 307,
   or via est-domain in a voucher.  If it is a 307 redirect, then a
   provisional TLS connection will be initiated, and it will succeed.
   The provisional TLS connection does not do [RFC6125] DNS-ID
   validation at the beginning of the connection, so a forced
   redirection to a captive portal system will not be detected.  The
   subsequent BRSKI POST of a voucher will most likely be met by a 404
   or 500 HTTP code.  As the connection is provisional, the pledge will
   be unable to determine this.

   It is RECOMMENDED therefore that the pledge look for [RFC8910]
   attributes in DHCP, and if present, use the [RFC8908] API to learn if
   it is captive.

7.2.  Security Updates for the Pledge

   Unlike many other uses of BRSKI, in the Cloud Registrar case it is
   assumed that the Pledge has connected to a network on which there is
   addressing and connectivity, but there is no other local
   configuration available.

   There is another advantage to being online: the pledge may be able to
   contact the manufacturer before onboarding in order to apply the
   latest firmware updates.  This may also include updates to the
   Implicit list of Trust Anchors.  In this way, a Pledge that may have
   been in a dusty box in a warehouse for a long time can be updated to
   the latest (exploit-free) firmware before attempting onboarding.

7.3.  Trust Anchors for Cloud Registrar

   The Implicit TA database is used to authenticate the Cloud Registrar.
   This list is built-in by the manufacturer along with a DNS name to
   which to connect.  (The manufacturer could even build in IP addresses
   as a last resort)

   The Cloud Registrar does not have a certificate that can be validated
   using a public (WebPKI) anchor.  The pledge may have any kind of
   Trust Anchor built in: from full multi-level WebPKI to the single
   self-signed certificate used by the Cloud Registrar.  There are many
   tradeoffs to having more or less of the PKI present in the Pledge,
   which is addresses in part in
   [I-D.irtf-t2trg-taxonomy-manufacturer-anchors] in sections 3 and 5.

Friel, et al.           Expires 18 November 2023               [Page 17]
Internet-Draft                 BRSKI-CLOUD                      May 2023

7.4.  Issues with Redirect via Voucher

   The second redirect case is handled by returning a special extension
   in the voucher.  The Cloud Registrar actually does all of the voucher
   processing as specified in [BRSKI].  In this case, the Cloud
   Registrar may be operated by the same entity as the MASA, and it
   might even be combined into a single server.  Whether or not this is
   the case, it behaves as if it was separate.

   It may be the case that one or more 307-Redirects have taken the
   Pledge from the built-in Cloud Registrar to one operated by a VAR.

   When the Pledge is directed to the Owner's EST [RFC7030] Registrar,
   the Pledge validates the TLS connection with this server using the
   "pinned-domain-cert" attribute in the voucher.  There is no
   provisional TLS connection, and therefore there are no risks
   associated with being behind a captive portal.

8.  References

8.1.  Normative References

   [BRSKI]    Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/info/rfc8995>.

   [I-D.ietf-lamps-rfc7030-csrattrs]
              Richardson, M., Friel, O., von Oheimb, D., and D. Harkins,
              "Clarification of RFC7030 CSR Attributes definition", Work
              in Progress, Internet-Draft, draft-ietf-lamps-rfc7030-
              csrattrs-02, 8 April 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              rfc7030-csrattrs-02>.

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

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

Friel, et al.           Expires 18 November 2023               [Page 18]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "A Voucher Artifact for Bootstrapping Protocols",
              RFC 8366, DOI 10.17487/RFC8366, May 2018,
              <https://www.rfc-editor.org/info/rfc8366>.

   [RFC8366bis]
              Watsen, K., Richardson, M., Pritikin, M., Eckert, T. T.,
              and Q. Ma, "A Voucher Artifact for Bootstrapping
              Protocols", Work in Progress, Internet-Draft, draft-ietf-
              anima-rfc8366bis-07, 7 February 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
              rfc8366bis-07>.

8.2.  Informative References

   [I-D.irtf-t2trg-taxonomy-manufacturer-anchors]
              Richardson, M., "A Taxonomy of operational security
              considerations for manufacturer installed keys and Trust
              Anchors", Work in Progress, Internet-Draft, draft-irtf-
              t2trg-taxonomy-manufacturer-anchors-00, 22 January 2023,
              <https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-
              taxonomy-manufacturer-anchors-00>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/info/rfc1918>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <https://www.rfc-editor.org/info/rfc6125>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <https://www.rfc-editor.org/info/rfc7250>.

   [RFC8572]  Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
              Touch Provisioning (SZTP)", RFC 8572,
              DOI 10.17487/RFC8572, April 2019,
              <https://www.rfc-editor.org/info/rfc8572>.

Friel, et al.           Expires 18 November 2023               [Page 19]
Internet-Draft                 BRSKI-CLOUD                      May 2023

   [RFC8908]  Pauly, T., Ed. and D. Thakore, Ed., "Captive Portal API",
              RFC 8908, DOI 10.17487/RFC8908, September 2020,
              <https://www.rfc-editor.org/info/rfc8908>.

   [RFC8910]  Kumari, W. and E. Kline, "Captive-Portal Identification in
              DHCP and Router Advertisements (RAs)", RFC 8910,
              DOI 10.17487/RFC8910, September 2020,
              <https://www.rfc-editor.org/info/rfc8910>.

   [RFC8952]  Larose, K., Dolson, D., and H. Liu, "Captive Portal
              Architecture", RFC 8952, DOI 10.17487/RFC8952, November
              2020, <https://www.rfc-editor.org/info/rfc8952>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/info/rfc8994>.

Authors' Addresses

   Owen Friel
   Cisco
   Email: ofriel@cisco.com

   Rifaat Shekh-Yusef
   Auth0
   Email: rifaat.s.ietf@gmail.com

   Michael Richardson
   Sandelman Software Works
   Email: mcr+ietf@sandelman.ca

Friel, et al.           Expires 18 November 2023               [Page 20]