Hi Mahesh, All these issues have been addressed in the github repo. We raised individual issues 156-166 for each of your comments below if you want to check the specific text:
https://github.com/anima-wg/brski-cloud/issues?q=is%3Aissue+is%3Aclosed You can expect a draft-10 shortly. Thanks, Owen From: Mahesh Jethanandani <mjethanand...@gmail.com> Sent: Wednesday, August 21, 2024 1:41 AM To: draft-ietf-anima-brski-cloud....@ietf.org Cc: anima@ietf.org; anima-cha...@ietf.org Subject: Additional AD review Hi Authors, Thanks for posting an update for the draft, and addressing the AD review comments of Rob Wilton. Since the changes were extensive, a second review was warranted. I expect some responses for the COMMENTs but it would be nice if you addressed the NITs also. ------------------------------------------------------------------------------- COMMENT ------------------------------------------------------------------------------- Overall comments: Please run a spell checker of choice to fix all the spelling errors in the document, which there are plenty. The second has to with inconsistent use of terms. Examples include "Owner Registrar" and "owner Registrar”, “pledge” and “Pledge”, “bootstrap” and “Bootstrap". It helps to be consistent in your use of the terms. Specific comments: Section 1, paragraph 3 > To support enrolment of pledges without such an owner based access > network, the mechanisms of BRSKI Cloud are required which assume that > Pledge and Registrar simply connect to the Internet. The Internet > ("Cloud") connected Registrar will then determine ownership of the > Pledge and redirect the Plege to its owners Registrar. I will admit I have not gone through the BRSKI specification. What happens if the URI of the Cloud Registrar is shutdown or moved? Is that covered by BRSKI, or is that outlined somewhere in this document? Section 1.2.1, paragraph 1 > A pledge is bootstrapping from a location with no local domain > Registrar (for example, the small site or teleworker use case with no > local infrastructure to provide for automated discovery), and needs > to discover its owner Registrar. The Cloud Registrar is used by the > pledge to discover the owner Registrar. The Cloud Registrar > redirects the pledge to the owner Registrar, and the pledge completes > bootstrap against the owner Registrar. Covered in the overall comments, but repeated here. What is the difference between "Owner Registrar" and "owner Registrar"? If they are the same, can we be consistent in its usage? Same for pledge and Pledge. Section 2, paragraph 3 > For use case one, as described in Section 1.2.1, the Cloud Registrar > redirects the pledge to an owner Registrar in order to complete > bootstrap with the owner Registrar. When bootstrapping against an > owner Registrar, this Registrar will interact with a CA to assist in > issuing certificates to the pledge. This is illustrated in Figure 1. It is not clear which registrar is "this Registrar". Is it the Cloud Registrar or the owner Registrar? Section 2, paragraph 3 > For use case two, as described Section 1.2.2, the Cloud Registrar > issues a voucher itself without redirecting the pledge to an owner > Registrar, the Cloud Registrar will inform the pledge what domain to > use for accessing EST services in the voucher response. In this > model, the pledge interacts directly with the EST service to enrol. > The EST service will interact with a CA to assist in issuing > certificated to the pledge. This is illustrated in Figure 2. s/cerfificated/a cerficate/ Section 3.1.2, paragraph 1 > According to [BRSKI], Section 2.7, the pledge MUST use an Implicit > Trust Anchor database (see EST [RFC7030]) to authenticate the Cloud > Registrar service. The pledge MUST establish a mutually > authenticated TLS connection with the Cloud Registrar. Unlike the > procedures documented in BRSKI section 5.1, the pledge MUST NOT > establish a provisional TLS connection with the Cloud Registrar. Please add a definition or a reference to "provisional TLS connection"? Section 3.2, paragraph 2 > 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. In this scenario, the Registrar SHOULD > 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 a bootstrapping failure, and indicate this to the operator. Thanks for addressing Rob's comment and changing the MAY to a SHOULD. But you left the rest of the paragraph as is, and now the following sentence does not make sense. What failure condition are you referring to? Also, wnen you do add a SHOULD, the follow-on question is, what happens if the Retry-After header is not included? Section 3.3.1, paragraph 2 > The pledge MUST restart its bootstrapping process by sending a new > voucher request message (with a fresh nonce) using the location > provided in the HTTP redirect. The pledge SHOULD attempt to validate > the identity of the Cloud Registrar specified in the 307 response > using its Implicit Trust Anchor Database. If validation of this > identity succeeds using the Implicit Trust Anchor Database, then the > pledge MAY accept a subsequent 307 response from this Cloud > Registrar. The pledge MAY continue to follow a number of 307 > redirects provided that each 307 redirect target Registrar identity > is validated using the Implicit Trust Anchor Database. However, if > validation of a 307 redirect target Registrar identity using the > Implicit Trust Anchor Database fails, then the pledge MUST NOT accept > any further 307 responses from the Registrar, MUST establish a > provisional TLS connection with the Registar, and MUST validate the > identity of the Registrar using standard BRSKI mechanisms. In case of validation failure, it is not clear which Registrar it MUST establish a provisional TLS connection with. The original Cloud Registrar, one of the intermediate Cloud Registrar, or the last Cloud Registrar it was able to validate? Section 4.1, paragraph 1 > This flow illustrates the Bootstrap via Cloud Registrar and Owner > Registrar use case. 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 owner Registrar on the public > internet. What is "Bootstrap", and how is it different from bootstrap? No reference entries found for these items, which were mentioned in the text: [RFC6066] and [RFC8994]. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. "Abstract", paragraph 1 > To this, 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 Cloud Registrar > enables discovery of the operator maintained infrastructure, and may > enable establishment of trust with operator maintained infrastructure > that does not support BRSKI mechanisms. s/To this, this document/This document/ Section 1, paragraph 4 > 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. Why the EOL or break in the sentence? Section 1.1, paragraph 3 > Local Domain: The domain where the pledge is physically located and > bootstrapping from. This may be different to the pledge owner's > domain. s/different to/different from/ Reference [RFC6125] to RFC6125, which was obsoleted by RFC9525 (this may be on purpose). Section 1.2.2, paragraph 1 > ly, it can also be used long-term as an security-equivalent solution in whic > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". Section 2, paragraph 2 > s/cerfificated/a cerficiate/ It also also possible that the Cloud Registrar > ^^^^^^^^^ Consider adding a comma between these intensifiers. Section 2, paragraph 3 > f this document. The architectures shows the Cloud Registrar and MASA as bei > ^^^^^ You should probably use "show". Section 2.2, paragraph 1 > d operations that take place. Section Section 4 outlines the exact sequence > ^^^^^^^^^^^^^^^ Possible typo: you repeated a word. Section 8, paragraph 1 > strar that is operated by a VAR, or it it has been redirected to an Owner Reg > ^^^^^ It seems you either mean "it is", "if it", "it" or there is a comma missing. Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
