Bootstrapping Remote Secure Key Infrastructure (BRSKI) Cloud Registrar
draft-ietf-anima-brski-cloud-19

[Edit on 4 Sep:  Thanks for addressing my discuss.  I appreciate the all the hard work.]


Thanks to Mike Ounsworth for their (multiple) secdir reviews.

Section 4.2, step 6:  What/where is this:   {pledge-certificate-identity-considerations} ?

Section 8.4:  What/where is this: {bootstrap-via-cloud-registrar-and-owner-est-service} ?

Thanks for addressing my previous blocking DISCUSS issue (I told you that it was trivial to fix).

Alas, I have noticed that some of my original non-blocking COMMENTS below are not addressed in -17 (notably having references *only* to DHCPv4 rather than DHCPv6).


## COMMENTS (non-blocking)

### Missing privacy / operational considerations ?

As the Cloud and Owner are different organisation, I was expected to read some privacy considerations:
- the Cloud Registrar will see the addresses (i.e., location) and devices count per Owner
- the Owner relies on the Cloud Registrar availability, i.e., it is a single point of failure (the draft discusses briefly about bankruptcy but this could be censorship as well)

### Nice use of SVG

Thanks for using SVG graphics, so much more readable :-)

### Section 1.1

The OEM definition is not really the usual one, but this is OK I guess in this I-D even if the word 'created' looks weird in this context (why not 'manufactured').

Missing "owner", does it mean the guy buying the phone (or...) or the company operating it ? It is really an ambiguous and overloaded term.

The word 'domain' is also under-specified as it can means several things.

### Section 1.2

s/target use cases/use cases/ ?

More important, as we are in 2025, why using DHCPv4 and no DHCPv6 ? One author is even a RFC 8415 author... Please update the draft with DHCPv6 reference. It is informational use of DHCPv4 as an example, therefore this point is sadly not DISCUSS worthy.

Add an informative reference to `LDevID`.

### Section 2

Please expand `MASA` and provide a reference.

### Section 2.1

Please add "Pledge operator" to the terminology as it is a little unclear.

It is not enough to state `The Pledge must have an IP address so that it is able to make DNS queries` suggest "The Pledge must have an IP address and be capable to reach a recursive DNS server".

### Section 2.2

Suggest expanding `CSR` at first use.

Should a reference be added to `IDevID` ?

### Section 3

I find the flow of steps then ventilate by use case somehow difficult to read. Probably too late to change but a flow by use case then steps would have been easier to read.

### Section 3.1.1

`which are typically` or "which MUST be" ?

## NITS (non-blocking / cosmetic)

### Section 3.1.2

s/link local IPv6 address/link-local IPv6 address/

### Section 3.2

Add a reference to RFC 7231 for "Retry-After".

### Section 3.2.3

Like in section 1.2, we are still in 2025, so how does the proposed solution compare to DHCPv6 ?

### Section 3.3.1

Should there be a bound to the number of redirects ?

### Section 4.2

Is it a little unclear whether global/routable IP addresses are included in `It MAY also be a local address that includes an IP address literal including both IPv4 [RFC1918] and IPv6 Unique Local Addresses [RFC4193]. `.

### Section 8.1

Isn't it a little scary/unsafe if a pledge upgrades its firmware (potentially in a non secure way) and its trust anchors ?

Thank you for the work put into this document.

I support the DISCUSS provided by Mike Bishop.

It would really be super-helpful to expand MASA and EST when first used, it was not good to have to research to check exactly what these were intended to expand to! (Presumably: Manufacturer Authorized Signing Authority, Enrollment over Secure Transport).

# Gunter Van de Velde, RTG AD, comments for draft-ietf-anima-brski-cloud-16

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-cloud-16.txt

# nice writeup and well written. Thanks for the great work

# Detailed Review
# ===============

163	1.1.  Terminology

GV> Many goodies in this section. I see "Owner Domain" and "Owner registrar" but no definition of "Owner" or "Owner delegate"  

Many thanks for this document,
Gunter Van de Velde,
Routing AD

Thank you for your updates to address my previous DISCUSS and COMMENTs.

Hi Owen, Rifaat, and Michael,

Thank you for the effort put into this specification. 

Also, thanks to Tim Wicinski for the DNSDIR review and to the authors for engaging and proposing changes. 

# Overall

The document is well-written with a clear applicability scope. The description is repetitive in some places (e.g., all the details about “SIP phones” is repeated several times, redundant text in 1.2.1, etc.); some less words would be appropriate to help readers better focus on the core specification.

Please find below more detailed comments. Major comments are marked with (*). 

# Operationalizing the solution (*)

The approach requires some coordination and provisioning that involve several entities. The document includes some useful discussion but those are really scattered in the document. I suggest to group these matters under a new “Operational Considerations” section. That section can include, e.g., required out of band configuration, discovery consideration, scalability discussion, service stability requirements and migration considerations, current Sections 5 and 7 as subsections.

# Inappropriate use of normative language  (*)

Several uses of the normative language in the document are not justified. Also, many of those are redundant with other statements in the document. For example:

(1) Introduction
   This work is in support of [BRSKI], Section 2.7, which 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 updates [BRSKI] by clarifying operations that are left
   out of scope in [BRSKI].  Two modes of operation are specified in
   this document.  The Cloud Registrar MAY redirect the Pledge to the^
                                       ^^^^
   owner's Registrar, or the Cloud Registrar MAY issue a voucher to the
                                             ^^^
   Pledge that includes the domain of the owner's Enrollment over Secure
   Transport [RFC7030] (EST) server.

(2) Section 2
   It is also possible that the Cloud Registrar MAY redirect the Pledge
                                                ^^^^
   to another Cloud Registrar operated by a VAR, with that VAR's Cloud
   Registrar then redirecting the Pledge to the Owner Registrar.  This
   scenario is discussed further in Sections Section 7.2 and 8.3.

(3) Section 3.1.1
   BRSKI defines how a Pledge MAY contact a well-known URI of a Cloud

I suggest s/MAY/may at least in these excerpts and similar ones.

# Internal inconsistency (*)

CURRENT:
   … and MUST
   NOT send the CSR Attributes request to the Cloud Registrar, because
   the Cloud Registrar does not have authority to issue a certificate
   for the customer domain.  (The Cloud Registrar is not a full EST
   server) If a Pledge sends a CSR Attributes request to the Cloud
   Registrar, then the Cloud Registrar MUST reply with 404 response
   code.

There is a conflict between the first MUST NOT and “if … sends”.

# Compliancy with BCP 56  (*)

There are several statements in the document that are not consistent with this reco:

   Applications using HTTP MUST NOT re-specify the semantics of HTTP
   status codes, even if it is only by copying their definition.  It is
   NOT RECOMMENDED they require specific reason phrases to be used; the
   reason phrase has no function in HTTP, is not guaranteed to be
   preserved by implementations, and is not carried at all in the HTTP/2
   [HTTP/2] message format.

Examples of such statements are

   Registrar, then the Cloud Registrar MUST reply with 404 response
   code.

Or

   The Cloud Registrar MUST determine Pledge ownership.  Prior to
   ownership determination, the Registrar checks the request for
   correctness and if it is unwilling or unable to handle the request,
   it MUST return a suitable 4xx or 5xx error response to the Pledge as

Or

   If the request is correct and the Registrar is able to handle it, but
   unable to determine ownership at that time, then it MUST return a 401

and similar statements in the document. Please check and revise accordingly. Typically, s/MUST return/returns

# Deviation vs. RFC8366bis  (*)

The document says: 

(Section 2.3)
   [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.

(Section 3.2.3)
   The voucher MAY include the new "additional-configuration" field. 
   ..
   The exact Pledge and Registrar behavior for handling and specifying
   the "additional-configuration" field is outside the scope of this
   document.

## However, there is no “additional-configuration” in draft-ietf-anima-rfc8366bis. Do we meant “additional-configuration-url”? If so, please update accordingly

## BTW, s/extensions/parameters as “extensions” have a special meaning in YANG.
 
# Need for a concrete recommendation (*)

CURRENT:
   In order to avoid permanent bootstrap cycles, the Pledge MUST NOT
   revisit a prior location.  

How this is actually implemented? How the behavior is controlled? Should previous attempts be cached, time-outed? If so, what is the depth of cached failures?

# Incomplete behavior (*)

Section 3.1.1 has the following

CURRENT:
   The Pledge SHOULD be provided with the entire URI of the Cloud
   Registrar, including the protocol and path components, which are
   typically "https://" and "/.well-known/brski", respectively.

But, what is supposed to do if incomplete URI is provided?

# Please find below some additional minor comments

## Expand BRSKI in the title.

## Abstract

### Help the device

CURRENT:
   Bootstrapping Remote Secure Key Infrastructures (BRSKI) 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 help the device.  

I don’t parse what is meant by “help the device”.

## New device

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

The concept of “new” is not clear at this stage. Do we consider a device new when it contacts the registrar for the first time or do we also consider cases where a device first connect to a given network? 

## Introduction

### Nits

OLD:
   Bootstrapping Remote Secure Key Infrastructures [BRSKI] BRSKI
                                                           ^^^^^^
   specifies automated and secure provisioning of nodes (which are
                                                         ^^^^^^^^^^
   called Pledges) with cryptographic keying material (trust anchors and

NEW:
   Bootstrapping Remote Secure Key Infrastructures [BRSKI] (BRSKI)
   specifies automated and secure provisioning of nodes
   (called Pledges) with cryptographic keying material (trust anchors and

### Phone, a bit outdates and does not reflect actual uses

I suggest to use User Agent (UA), rather than “phone” in this part (and similar ones)

OLD:
   This kind of non-network onboarding is sometimes called "Application
   Onboarding", as the purpose is typically to deploy a credential that
   will be used by the device in its intended use.  For instance, a SIP
   [RFC3261] phone might have a client certificate to be used with a SIP
   proxy.

NEW:
   This kind of non-network onboarding is sometimes called "Application
   Onboarding", as the purpose is typically to deploy a credential that
   will be used by the device in its intended use.  For instance, a SIP
   [RFC3261] user agent (UA) might have a client certificate to be used with a SIP
   proxy.

## Terminology

The document says: 

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

But provides a copy/past of some other entries (e.g., Manufacturer). Any reason that entry is copy/pasted here rather than listing it similar to other BRSKI terms? 

## Applicability

This text is lost in the “target Use Cases”. I suggest to move this to a dedicated subsection or to the introduction.

CURRENT:
   A network with an operator that is able to
   provision these options would also be able to use BRSKI without
   changes.  Such a network has no need for the mechanisms described in
   this document!

## Typical, really?

CURRENT:
   A typical example is a VoIP phone manufacturer provides telephones to
   a local system integration company (a VAR).  

This may be “typical” in the past, but I don’t think this is “typical” nowadays.

## Missing LDevID reference

CURRENT:
   When the employee plugs in the device and turns it on,
   the device will be provisioned with a LDevID and configuration that
   connections the phone with the Enterprises' VoIP PBX.  

Consider adding a pointer to 802.1AR?


## “cloud” in Section 1.2.2

OLD:
   The voucher
   issued by the cloud includes domain information for the owner's EST
   service that the Pledge should use for certificate enrollment.

NEW:
   The voucher
   issued by the Cloud Registrar includes domain information for the owner's EST
   service that the Pledge should use for certificate enrollment.

## Architecture

### Cloud Registrars

The text seems to assume that there is one single Cloud Registrar instance, while this shouldn’t. I suggest to make this change (and also through the doc):

OLD:
   In both use cases, the Pledge connects to the Cloud Registrar during
   bootstrap.

NEW:
   In both use cases, the Pledge connects to a Cloud Registrar during
   bootstrap.

### Additional information 

CURRENT:
   When
   returning a voucher, additional bootstrapping information is embedded
   in the voucher.  

Can we cite examples of additional information?

Absent such example, not sure that sentence adds value.

### IP address and reachability

CURRENT:
   prior to connecting to the Cloud Registrar.  The Pledge must have an
   IP address so that it is able to make DNS queries, and be able to
   send requests to the Cloud Registrar.  

The first “must” does not guarantee that DNS queries can be successfully placed.

For example, a device can only have a link local address, but that does not help communicating more than one hop further.

### Internal setup

CURRENT:
   For many telephony applications, this is typically going to be a
   wired connection.  For wireless use cases, existing Wi-Fi onboarding
   mechanisms such as [WPS] can be used.

Do we really need to have this?

## Section 3.3.1

s/will a follow/will follow

## Section 4.2

* s/In step 3, the the Cloud Registrar/In step 3, the Cloud Registrar
* s/ authenticate/authenticate


## Section 7.1: nit

OLD:
   When the Pledge attempts to connect to any Cloud Registrar, an
   incorrect connection will be detected because the Pledge will be
   unable to verify the TLS connection to its Cloud Registrar via DNS-ID
   check Section 6.3 of [RFC9525].  

NEW:
   When the Pledge attempts to connect to any Cloud Registrar, an
   incorrect connection will be detected because the Pledge will be
   unable to verify the TLS connection to its Cloud Registrar via DNS-ID
   check (Section 6.3 of [RFC9525]).  

Cheers,
Med

I support the DISCUSS positions of Mike Bishop and Deb Cooley.

I am also somewhat skeptical of this method of bootstrapping a device. It requires a continuous infrastructure dependency on the Cloud Regstrar, VARs, subVARs and company. What I personally experience for deploying various internet devices that phone home, is that they offer a phone app with bluetooth and/or the device can go into a wifi hotspot mode for the phone to connect to for configuration/provisioning (and firmware updates)

Thank you to Russ Housley for the GENART review.

I support the DISCUSS positions of Mike Bishop and Deb Cooley.