Internet-Draft BRSKI-CLOUD May 2020
Friel, et al. Expires 3 November 2020 [Page]
Network Working Group
Intended Status:
Standards Track
O. Friel
R. Shekh-Yusef
M. Richardson
Sandelman Software Works

BRSKI Cloud Registrar


This document specifies the behaviour of a BRSKI Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping.

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

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 3 November 2020.

Table of Contents

1. Introduction

Bootstrapping Remote Secure Key Infrastructures (BRSKI) [I-D.ietf-anima-bootstrapping-keyinfra] specifies automated bootstrapping of an Autonomic Control Plane. 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.

Two high level deployment models are documented here:

These deployment models facilitate multiple use cases including:

1.1. Target use cases

An end user unboxes a device, and connects it to a local network (using a cable). The device should join a (owner domain) Registrar operated by the end user's organization, which is not physically present on the local network.

The end user is at their home office, while the device belongs to their work. Or the end user is at a small satellite office which lacks correctly trained IT personnel.

The end user's organization operates an (owner domain) Registrar at their head-quarters, or in a hosted data center. A registrar may also be operated on behalf of the owner through an outsourced IT arrangement.

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 a local/owner registrar in order to complete bootstrap against the local registrar.

If the cloud registrar handles the bootstrap process itself without redirecting the pledge to a local registrar, the cloud registrar may need to inform the pledge what domain to use for accessing services once bootstrap is complete.

Finally, when bootstrapping against a local/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 illustrates shows the cloud registrar and MASA as being logically separate entities. The two functions could of course be integrated into a single service.

XXX NONCE-less voucher. If the Cloud Registrar issues a voucher directly, while it may include a nonce, because that nonce does not go through the Owner, which means that the MASA has no audit trail that the pledge really connected to the Owner Registrar.

TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2. Cloud Registrar returns VOUCHER pinning Owner Register.

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

2.1. Interested Parties

  1. OEM - Equipment manufacturer. Operate the MASA.
  2. Network operator. Operate the Local Registrar. Often operated by end owner (company), or by outsourced IT entity.
  3. Network integrator. They operate ?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 DNBS 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.

3. Initial Voucher Request

3.1. Cloud Registrar Discovery

BRSKI defines how a pledge MAY contact a well known URI of a cloud registrar if a local registrar cannot be discovered. Additionally, certain pledge types may never attempt to discover a local registrar and may automatically bootstrap against a cloud registrar. The details of the URI are manufacturer specific, with BRSKI giving the example "".

3.2. Pledge - Cloud Registrar TLS Establishment Details

The pledge MUST use an Implicit Trust Anchor database (see [RFC7030]) to authenticate the cloud registrar service as described in [RFC6125]. 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.

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

3.3. Pledge Requests Voucher from the Cloud Registrar

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.

4. Cloud Registrar Voucher Request Operation

When the cloud registrar has verified the identity of the pledge, determined the pledge ownership and has received the voucher request, there are two main options for handling the request.

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

5. Voucher Request Redirected to Local Domain Registrar

Once the cloud registar has determined pledge ownership, the cloud registrar may redirect the pledge to the owner's local domain 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 3xx response code as per [I-D.ietf-httpbis-bcp56bis], including the owner's local domain in the HTTP Location header.

5.1. Pledge handling of Redirect

The pledge should complete BRSKI bootstrap as per standard BRSKI operation after following the HTTP redirect. 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.

6. Voucher Request Handled by Cloud Registrar

If the cloud registrar issues a voucher, it returns the voucher in a HTTP response with a suitable 2xx response code as per [I-D.ietf-httpbis-bcp56bis].

Alternatively, it may redirect to the customers' Registration Authority (RA) with a 307 Temporary Redirect to locate the RA. The client MUST POST its voucher request to the new location.

7. Protocol Details

[[ TODO ]] Missing detailed BRSKI steps e.g. CSR attributes, logging, etc.

7.1. Voucher Request Redirected to Local Domain Registrar


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

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


+--------+                                       +----------+
| Pledge |                                       | Cloud RA |
|        |                                       | / MASA   |
+--------+                                       +----------+
    |                                                 |
    | 1. Full TLS                                     |
    |                                                 |
    | 2. Voucher Request                              |
    |                                                 |
    | 3. Voucher Response  {localra: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     |                          |
    |--------------------->|                          |

8. Pledge Certificate Identity Considerations

BRSKI section 5.9.2 specifies that the pledge MUST send a 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.

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.

9. IANA Considerations

[[ TODO ]]

10. Security Considerations

[[ TODO ]]

11. Informative References

IEEE, ., "Secure Device Identity", .
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Work in Progress, Internet-Draft, draft-ietf-anima-bootstrapping-keyinfra-41, , <>.
Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, , <>.
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, , <>.
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, , <>.
Nottingham, M., "Building Protocols with HTTP", Work in Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-09, , <>.

Authors' Addresses

Owen Friel
Rifaat Shekh-Yusef
Michael Richardson
Sandelman Software Works