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
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
