BRSKI Cloud Registrar

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.¶
• 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.¶

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 are 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.¶

While a Cloud Registrar will typically handle all the devices of a particular product line from a particular manufacturer there are no restrictions on how the Cloud Registrar is horizontally (many sites) or vertically (more equipment at one site) scaled. It is also entirely possible that all devices sold by through a particular 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.¶

2.1. Interested Parties

1. OEM - Equipment manufacturer. Operate the MASA.¶
2. Network operator. Operate the Owner Registrar. Often operated by end owner (company), or by outsourced IT entity.¶
3. Network integrator. They operate a Cloud Registrar.¶

2.2. 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, must be able to make DNS queries, and must be able to send HTTP requests to the cloud registrar. 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.¶

2.3. 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.richardson-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.¶

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.1. Pledge Requests Voucher from Cloud Registrar

3.2. Cloud Registrar Handles Voucher Request

The cloud registrar must determine pledge ownership. Once ownership is determined, or if no owner can be determined, then the registrar may:¶

• return a suitable 4xx or 5xx error response to the pledge if the registrar is unwilling or unable to handle the voucher request¶
• redirect the pledge to an owner register via 307 response code¶
• issue a voucher and return a 200 response code¶

3.3. Pledge Handles Cloud Registrar Response

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

+--------+                                       +----------+
| 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.¶

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 registrar found at that URI. The pledge uses the pinned-domain-cert from the voucher to authenticate the EST registrar.¶

+--------+                                       +----------+
| Pledge |                                       | Cloud RA |
|        |                                       | / MASA   |
+--------+                                       +----------+
    |                                                 |
    | 1. Mutual TLS                                   |
    |<----------------------------------------------->|
    |                                                 |
    | 2. Voucher Request                              |
    |------------------------------------------------>|
    |                                                 |
    | 3. Voucher Response  {est-domain:fqdn}          |
    |<------------------------------------------------|
    |                                                 |
    |                 +----------+                    |
    |                 | RFC7030  |                    |
    |                 |  EST     |                    |
    |                 | Registrar|                    |
    |                 +----------+                    |
    |                      |                          |
    | 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 Registrar. 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 Registrar is validated 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 Registrar from this anchor only.¶

There is a case where the pinned-domain-cert is the identical End-Entity (EE) Certificate as the EST Registrar. It also explicitly includes the case where the EST Registrar 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 Registrar.¶

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.1. YANG Tree

module: ietf-voucher-redirected

  grouping voucher-redirected-grouping
    +-- voucher
       +-- created-on                       yang:date-and-time
       +-- expires-on?                      yang:date-and-time
       +-- assertion                        enumeration
       +-- serial-number                    string
       +-- idevid-issuer?                   binary
       +-- pinned-domain-cert               binary
       +-- domain-cert-revocation-checks?   boolean
       +-- nonce?                           binary
       +-- last-renewal-date?               yang:date-and-time
       +-- est-domain?                      ietf:uri
       +-- additional-configuration?        ietf:uri

5.2. YANG Voucher

<CODE BEGINS> file "ietf-voucher-redirected@2020-09-23.yang"

module ietf-voucher-redirected {
  yang-version 1.1;

  namespace
    "urn:ietf:params:xml:ns:yang:ietf-voucher-redirected";
  prefix "redirected";

  import ietf-restconf {
    prefix rc;
    description
      "This import statement is only present to access
       the yang-data extension defined in RFC 8040.";
    reference "RFC 8040: RESTCONF Protocol";
  }

  import ietf-inet-types {
    prefix ietf;
    reference "RFC 6991: Common YANG Data Types";
  }

  import ietf-voucher {
    prefix "v";
  }

  organization
   "IETF ANIMA Working Group";

  contact
   "WG Web:   <http://tools.ietf.org/wg/anima/>
    WG List:  <mailto:anima@ietf.org>
    Author:   Michael Richardson
              <mailto:mcr+ietf@sandelman.ca>
    Author:   Owen Friel
              <mailto: ofriel@cisco.com>
    Author:   Rifaat Shekh-Yusef
              <mailto: rifaat.ietf@gmail.com>";
description
  "This module extendes the base RFC8366 voucher format to
   include a redirect to an EST server to which enrollment
   should continue.

   The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
   'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
   and 'OPTIONAL' in the module text are to be interpreted as
   described in BCP14, RFC 2119, and RFC8174.";

  revision "2020-09-23" {
    description
     "Initial version";
    reference
     "RFC XXXX: Voucher Profile for Cloud redirected Devices";
  }

  rc:yang-data voucher-redirected-artifact {
    // YANG data template for a voucher.
    uses voucher-redirected-grouping;
  }

  // Grouping defined for future usage
  grouping voucher-redirected-grouping {
    description
      "Grouping to allow reuse/extensions in future work.";

    uses v:voucher-artifact-grouping {

      augment "voucher" {
        description "Base the constrained voucher
                     upon the regular one";
        leaf est-domain {
          type ietf:uri;
          description
            "The est-domain is a URL to which the Pledge should
             continue doing enrollment rather than with the
             Cloud Registrar.
             The pinned-domain-cert contains a trust-anchor
             which is to be used to authenticate the server
             found at this URI.
            ";
        }
        leaf additional-configuration {
          type ietf:uri;
          description
            "The additional-configuration attribute contains a
             URL to which the Pledge can retrieve additional
             configuration information.
             The contents of this URL are vendor specific.
             This is intended to do things like configure
             a VoIP phone to point to the correct hosted
             PBX, for example.";
        }
      }
    }
  }
}

<CODE ENDS>

6.1. The IETF XML Registry

This document registers one URI in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested:¶

{: newline="true"}
URI:
: urn:ietf:params:xml:ns:yang:ietf-voucher-redirected

Registrant Contact:
: The ANIMA WG of the IETF.

XML:
: N/A, the requested URI is an XML namespace.

6.2. The YANG Module Names Registry

This document registers two YANG modules in the YANG Module Names registry [RFC6020]. Following the format defined in [RFC6020], the the following registration is requested:¶

{: newline="true"}
name:
: ietf-voucher-redirected

namespace:
: urn:ietf:params:xml:ns:yang:ietf-voucher-redirected

prefix:
: vch

reference:
: THIS DOCUMENT

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

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.richardson-t2trg-idevid-considerations] in sections 3 and 5.¶

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] 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.¶