[Anima] AD review of draft-ietf-anima-brski-cloud-08

["Rob Wilton (rwilton)" <[e-mail]>]

Hi,

Here is my AD review of draft-ietf-anima-brski-cloud-08.

I confess that I’m not an expert on BRSKI and EST which has limited my ability to do a technical review, but which may be the reason that I found that document to be somewhat harder to understand.

Anyway, I have the following comments:

Moderate level comments:

(1) p 11, sec 4.  Protocol Details

It wasn't entirely clear to me how what the split between Protocol Operation and Protocol Details is.  Possibly adding a sentence or two to the beginning of each of these sections may help guide the reader.



Minor level comments:

(2) p 3, sec 1.2.  Target Use Cases

   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.

Rather than "which of these two situations", perhaps it would be clearer as "which of the two situatations described in sections 1.2.1 and 1.2.2 below"


(3) p 4, sec 2.  Architecture

   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.

Possibly this paragraph and the previous one would be better in the reverse order.  In particular, it is unclear to me whether using ESP services constitutes "bootstrapping against an owner Registrar", or wheher the third paragraph ony covers the "Cloud Registrar may redirect the pledge to an owner Registrar" case.


(4) p 8, sec 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.

What is meant by a "full TLS connection"?


(5) p 8, sec 3.2.  Cloud Registrar Handles Voucher Request

   If the request is correct and the Registrar is able to handle it, but
   unable to determine ownership, then it MUST return a 401 Unauthorized
   response to the pledge.  This signals to the Pledge that there is
   currently no known owner domain for it, but that retrying later might
   resolve this situation.  The Registrar MAY also include a Retry-After
   header that includes a time to defer.  A pledge with some kind of
   indicator (such as a screen or LED) SHOULD consider this an
   onboarding failure, and indicate this to the operator.

I'm slightly surprised that it is only a MAY for including the Retry-After header rather than SHOULD.


(6) p 10, sec 3.3.1.  Redirect Response

   The pledge MUST establish a provisional TLS connection with specified
   local domain Registrar.  The pledge MUST NOT use its Implicit Trust
   Anchor database for validating the local domain Registrar identity.
   The pledge MUST send a voucher request message via the local domain
   Registrar.

It wasn't obvious to me why the pledge MUST NOT use it's implicit trust anchor database, and whether providing justification (or an explanation) would be helpful.  Is this because it is just following the standard BRSKI flow from this point?



Nit level comments:

(7) p 0, sec

   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.

Perhaps "and help the device".


(8) p 4, sec 1.2.1.  Owner Registrar Discovery

   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.

Perhaps "in their headquarters." or "within the employer's network."


(9) p 5, sec 2.  Architecture

   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
   Registrar.  When returning a voucher, additional bootstrapping
   information embedded in the voucher.  Both mechanisms are described
   in detail later in this document.

to the Owner Registrar


(10) p 5, sec 2.  Architecture

   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
   Registrar.  When returning a voucher, additional bootstrapping
   information embedded in the voucher.  Both mechanisms are described
   in detail later in this document.

information embedded => 'information is embedded', or 'information can be embedded'.


(11) p 5, sec 2.  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.

involve => involved


(12) p 8, sec 3.2.  Cloud Registrar Handles Voucher Request

   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
   defined by [BRSKI] and HTTP.  In the case of an unknown pledge a 404
   is returned, for a malformed request 400 is returned, or in case of
   server overload 503.

Suggest "503 is returned".


(13) p 10, sec 3.3.1.  Redirect Response

   The pledge MUST establish a provisional TLS connection with specified
   local domain Registrar.  The pledge MUST NOT use its Implicit Trust
   Anchor database for validating the local domain Registrar identity.
   The pledge MUST send a voucher request message via the local domain
   Registrar.

Should that be with a specified ..., or with the specified ...

In additional, I also ran a grammar checker on the draft.  It can sometimes be a bit hit and miss, but you may want to check them anyway.

Spellings to check:
CertificateRequest,
enduser,
pledgeOwnershipLookup,
registar,
requestvoucher,

Grammar Warnings:
Section: abstract, draft text:
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.
Warning:  This word is normally spelled with a hyphen.
Suggested change:  "well-defined"

Section: 2.1, draft text:
There are are DHCP options that a network operator can configure to accomplish any of these options.
Warning:  Possible typo: you repeated a word
Suggested change:  "are"

Section: 2.1, draft text:
For wireless use cases, some kind of existing WiFi onboarding mechanism such as WPS.
Warning:  Did you mean Wi-Fi? (This is the officially approved term by the Wi-Fi Alliance.)
Suggested change:  "Wi-Fi"

Section: 3.1.2, draft text:
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.
Warning:  This word is normally spelled as one.
Suggested change:  "preloaded"

Section: 3.2.1, draft text:
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.
Warning:  The word "lookup" is a noun. The verb is spelled with a white space.
Suggested change:  "look up"

Section: 3.2.2, draft text:
In case of redirection, the Cloud Registrar replies to the voucher request with a HTTP 307 Temporary Redirect response code, including the owner's local domain in the HTTP Location header.
Warning:  Use an instead of 'a' if the following word starts with a vowel sound, e.g. 'an article', 'an hour'.
Suggested change:  "an"

Section: 3.2.3, draft text:
If the Cloud Registrar issues a voucher, it returns the voucher in a HTTP response with a 200 response code.
Warning:  Use an instead of 'a' if the following word starts with a vowel sound, e.g. 'an article', 'an hour'.
Suggested change:  "an"

Section: 4.1, draft text:
The assumption is that the owner Registrar domain is accessible and the pledge can establish a network connection with the owner Registrar.
Warning:  Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short).
Suggested change:  ", and"

Section: 7, draft text:
The Cloud Registrar described in this document inherits all of the issues that are described in [BRSKI].
Warning:  Consider using all the.
Suggested change:  "all the"

Section: 7, draft text:
All of the considerations for operation of the MASA also apply to operation of the Cloud Registrar.
Warning:  Consider using All the.
Suggested change:  "All the"

Section: 7.4, draft text:
The Cloud Registrar actually does all of the voucher processing as specified in [BRSKI].
Warning:  Consider using all the.
Suggested change:  "all the"


Regards,
Rob