Max, please search for QUESTION. Toerless Eckert <t...@cs.fau.de> wrote: > 1.) Introduction > > a) The intro of 1. is somehat confusing to the uninitiated. > > Suggest the followinf replacement text for two paragraps: > > BRSKI provides a solution for secure zero-touch (automated) bootstrap of > virgin (untouched) devices that are called Pledges in this document. These > Pledges > need to discover (or be discovered by) an element of the network domain to > which the > Pledge belongs to perform the bootstrap. This element (device) is called the > (Domain Join) Registrar. Before any other operation, Pledge and Registrar > need to > establish mutual trust: > > Then the four existing bullet points, but number them. > > Then followed by th following paragraph to replace the existing paragraph > after > the four bullet poins.
All done, including: > b) It would be nice to have a paragraph mentioning the proxy as a mean to > provide easier connectivity for Pledges (no need for full network > connectivity). Also, we have tried to always say "PKIX" certificates, since the whole "X.509" space is decades old... Credit to IETF for keeping it alive. > 1.1) > > a) "other Bootstrapping Approaches": "other" -> "prior" or "existing" ? I'll take Prior, but I'm not crazy about the change. > b) "_or_ that domain-specific keying material". Is this not an _and_ ? It's an or. It's *insecure* *OR* there is a domain-specific key. > c) "in a costly and non-scaleable manner". "non-scaleable" may be hard to > argue. Whole economies where built on manual labor. Might rather use > qualifiers such as "little or not at all automated", "error-prone" and/or > referring to physical security (.e.g: trusted pre-staging location). Generally, any process that requires linear amount of labour (or capacity) to be added in order to grow linearly are consider non-scalable. Of course you can make pigs fly with enough rockets, but it does not work for arbitrarily sized pigs. > d) "existing mechanisms" -> "existing automated mechanisms". okay. > e) Paragraph 2 and following about EST: The first two sentences sound > contradictory/conflicting. "...minimize user action..." , "details a set of > non-autonomic bootstrapping methods". Suggest text like: > > "EST does reduce user actions during bootstrap but does not provide > solutions for how the following protocol steps can be made autonomic > (not involving user actions). okay, slightly adapted. > ----------------------------------------------------------------------------- > 1.3) > > a) The order of paragraphs is confusing. Even if the mayority of readers > (which i don't think) would primarily be interested in class 1 devices, > it is irritating in style and context to start with the first two > paragraphs. > > I would suggest to start with existing paragraph 3, change maybe the > sentence to "This solution (BRSKI) can support large router platforms..." > > Then insert the first two paragraphs after current paragraph 5. All the > text after paragraph 5 already discusses constrained situations so > it would nicely follow on to the first two paragraphs. okay. > b) paragraph 5 is confusing: What is a handoff, why would somebody > even think to apply BRSKI in a handoff, and why is there a normative, > capital letter SHOULD. Here is how i would write it more explanatory > (if i understand the implied use case correctly): > > BRSKI could be used by nomadic or mobile devices to aquire certificates > used as credentials to access the network at the new location. This > is usually called handoff. Nevertheless, BRSKI is not intended for low-latency > handoff which is usually a requirement in mobility solutions (e.g.: seamless > handover). For these solutions BRSKI could be used to aquire keying > material and re-use that during handover without re-initiating BRSKI > during handover later on. > > (which is also implying that re-using BRSKI in nomadic environments > is not off the table, but not saying so explicitly because we really > have not thought that trough a lot). I have adapted your paragraph replacing the one we had. > c) It would loosen up a very long section to create three subsection headings > > - supported environments > - constrained envionments > - network access control Done. > ----------------------------------------------------------------------------- > > Section 2 1) > > a) ..Each component is logical and may be combined with other components as > necessary.. > > Ok. I always want the pledge to live in the same device as the MASA. > > Would suggest deleting that sentence. More harm than benefit. Hmm. The Circuit Proxy, Domain Registrar and Certificate Authority could be done component. I think that we need to say something about that. > b) I suggest to move section 2.4 up to become section 2.1) directly after the > picture in section 2., because otherwise there is no explanaction following > the picture. > > c) "The a domain" (delete a) I think that you mean it becomes section 2.2, after the first state machine? (c) perhaps already done. > ----------------------------------------------------------------------------- > > Section 2.1 > > a) The term "Request Join" is only used here, and its IMHO not very logical > (disclaimer: toerless: en.wikipedia.org/wiki/ESL). It sounds to me like the > pledge says "i want to join". And also sounds as if the pledge could be > disappointed if rejected. I would rather call it "Domain membership inquiry". > Or if you're hooked up on the term "joining", then maybe "Join Inquiry". QUESTION? what do you think? Was "Request Voucher" one of the options you were thinking about? > Whatever best makes it clear that rejection is a perfect and important > outcome option. > > b) Please see my issue section 5.1 a). If you agree with that statement, then > there > should be no "rejected" arrow in Figure 2 coming out of the "Identify" > block. okay, I'll deal with this in that section. > I would also suggest that the "Bad Vendor response" arrow does not come out > of the "Imprint" block but out of the "Request Join" block. AFAIK, this is > an error reply to the Request Voucher, so it happens before imprinting > (imprinting happens only when there is a vocker reply. AFAIK). [It says, "Bad MASA response" now, just for the reader who is following] > I don't think "Bad Vendor reply" in Figure 2 is a good term. Most logical > to me would > be "Error or not member". In any case, the text in section 2 below should > mention the exact words used on the labels, the text is missing ll the > labels on the left: "Factory reset", "Enroll Failure", "Bad Vendor > response",... more discussion. > c) > > Point 1 nicely explains how this is done during TLS. > > Likewise, Point 2 should mention that this is the "Voucher Request", and > Point 3 should mention that it is the "Voucher Reply" - so readers can match > up section 2.1 with the rest of the document. > > remove the "e.g." from "protocol, e.g. Enrollment over". Otherwise some text > outlining when something else than EST is to be used. (see next comment). QUESTION: I couldn't figure out what text this applies to. > d) > > I am missing in the initial chapters a succinct summary how EST enrollment is > optional and > what can be achieved with/without it, there is only some side sentences > later in the > EST sections. I would suggest to insert such an explanation here. > > After point 4 insert (unnumbered) paragraph: > > | After step 4, the pledge has received and authenticated an explicit TA > (trust anchor) > | (pinned-domain-cert in the Voucher response). In some use cases this may be > sufficient > | and the bootstrap can be terminated here. The pledge can now use this TA to > securely > | trust domain members, but it can not securely identify itself to them as a > domain member. > | Therefore BRSKI usually proceeds with the following steps that support this > via EST > | enrollment (see also 5.5.1 for the limitations of the trust feasible > through the imprint). > > Also maybe insert some dotted line between imprint and enroll in Figure 2 to > highlight this distinction. Maybe with "mandatory" / "optional" (EST enroll > part) > on the right hand side QUESTION: Max? > ----------------------------------------------------------------------------- > Section 2.2 > > a) > > The core sentence is hard to understand because it does not spell out the > implication of the alternatives: > > At the > lowest security levels the MASA server can indiscriminately issue > vouchers. At the highest security levels issuance of vouchers can be > integrated with complex sales channel integrations that are beyond > the scope of this document. > > Would suggest amending like this: > > At the lowest security levels the MASA server can indiscriminately issue > vouchers AND LOG CLAIMS OF OWNERSHIP BY DOMAINS. At the highest security > levels issuance of vouchers can be integrated with complex sales channel > integrations that are beyond the scope of this document BUT THAT WOULD > INTENT TO VERIFY ACTUAL (LEGAL) OWNERSHIP OF THE PLEDGE BY THE DOMAIN. I split it into more sentences, but took the intent. > b) > > "Vouchers provide a signed but non-encrypted communication channel > between the Pledge, the MASA, and the Registrar." > > Why is this mentioned ? If there is a conclusion of this statement that > is relevant to BRSKI it should be spelled out, otherwise its a detail > belonging into voucher. I do not see how the following sentence is that > relevant conclusion. But maybe i am too confused by the sentence structure. I think that it explains why the voucher exists. > Do you mean something like this: > > | Vouchers are signed but not encrypted. This allows registars to maintain > | better control over pledges attached to the domains network by examining > | and filtering Vouchers received from a MASA before sending them to the > pledge. > > If thats the idea, i suggest to use language like i suggested because it's > more explicit and simpler (not having to think what the relevance of > "communication channel" is etc..). QUESTION: I'm not sure that's the essence of the point. > Also may warrant a note that this control does not necessarily apply to the > case of a Cloud Registrar (see section 2.6). The could registrar is not a BRSKI interaction. Stopping here today. here is a diff against -11 https://goo.gl/CpZHqd -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
