Hi, I have processed the complete review from Toerless. (Making it a file attach is a bit hostile to the archives, btw)
I have opened 40 issues at: https://github.com/anima-wg/brski-cloud/issues A few have text fixes on the branch https://github.com/anima-wg/brski-cloud/pull/88 A few will require some discussion, and I've marked them for Toerless' attention. Most can be handled by authors, however, and I'll endeavour to get that posted by Jan. 2. Here is my comments/issues for the comments that Toerless made. (In two parts) Some comments inline as well. 1) many typos are at: https://github.com/anima-wg/brski-cloud/pull/88 > 10 BRSKI Cloud Registrar 11 draft-ietf-anima-brski-cloud-05 > 13 Abstract > 15 This document specifies the behavior of a BRSKI Cloud Registrar, and > 16 how a pledge can interact with a BRSKI Cloud Registrar when 17 > bootstrapping. > If you can, add an explanation what the core aspects of a Cloud > Registrar are for tthe purpose of this document... discovery ? > untrusted connection,.... ? https://github.com/anima-wg/brski-cloud/issues/48 > 95 1. Introduction > 97 Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies 98 > automated bootstrapping of an Autonomic Control Plane. BRSKI > Suggest to replace after BRSKI with: > ... BRSKI specifies automated and secure provisioning of nodes (which > are called pledges) with cryptographic keying material (trust anchors > and certificates) to enable authenticated and confidential > communication with other similarily enrolled nodes. This is also called > enrolment. > No need to mention Autonomic Control Plane here IMHO (just sounds like > limiting scope of BRSKI Cloud). > If you really want folks to understand what is happening here, i > suggest to include explanations such as the following. > In BRSKI, the pledge performs enrolment by communicating with a BRSKI > Registrar belonging to the domain that provides the cryptopgraphic > keying material and usually is or acts upon the owner of the > pledge. The pledge does not know who its owner is. Insted, in BRSKI it > is assumed that the network to which the pledge connects belongs to the > owner of the pledge and therefore network-supported discovery > mechanisms can resolve generic, non-owner specific names to the owners > Registrar. 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 Registar. https://github.com/anima-wg/brski-cloud/issues/49 > 99 Section 2.7 describes how a pledge "MAY contact a well-known URI of > a 100 cloud registrar if a local registrar cannot be discovered or if > the 101 pledge's target use cases do not include a local registrar". > I would remove parenthesis and lowercase the MAY. No need for this > formalism to expose your internal repetition of sentence. This is still > introduction, repetition is perfectly fine. https://github.com/anima-wg/brski-cloud/issues/50 > 131 * Local Domain Registrar: The Registrar discovered on the Local 132 > Domain. There may not be a Local Domain Registrar in all 133 > deployment scenarios. > Isn't one core aspect of interest (which should be discussed in the > text), that the pledge does discover a Registar locally, but its not of > its owner ? https://github.com/anima-wg/brski-cloud/issues/51 > 135 1.2. Target Use Cases > 137 Two high level use cases are documented here. There are more > details > This document specifies and standardizes procedures for two high level > use cases. > (use case documentation is fine, but the beef of standard tracks RFCs > is the specification of standardized procedures). https://github.com/anima-wg/brski-cloud/issues/52 > 152 or vertically (more equipment at one site) scaled. It is also 153 > entirely possible that all devices sold by through a particular VAR > ^^^^^^^^^^ 154 might be preloaded with a configuration that changes the > Cloud 155 Registrar URL to point to a VAR. Such an effort would > require 156 unboxing each device in a controlled environment, but the > 157 provisioning could occur using a regular BRSKI or SZTP [RFC8572] > 158 process. > I think VAR is an unnecessary term and the whole paragraph is somewhat > confusing. > If i understand it correctly, the core argument is like this: > The procedures specified in this document are an alternative to > mechanisms possible with just BRSKI to reduce operational cost. > Consider pledges are to be enrolled when being connected solely to the > Internet, but no owner based network. Likewise, the Registar is assumed > to be only connected to the Internet. The challenge in this case is for > the pledge to discover a URI for the Oners Registar. In the absence of > the procdures described in this doument, BRSKI could be used, but the > pledge would need to be pre-staged with that URI. In one instance, the > seller of the pledge could attach to the shipment of the pledge a USB > stick pre-populated with a file containing that Owner Registar URI, and > that USB stick would need to be inserted into the pledge to enavble > enrolment. This is but one option, and compared to similar > alternatives, it does not require unpacking/configuration/repackaging > of the pledge at the sellers site, but only configuration of a USB > stick > Yada yada... i really don't know how to make this shorter without > looking readers who do not live & breathe this stuff, so it probably is > all better suited to be put later into the document and only put a > pointer to such a chapter here into the Introduction. https://github.com/anima-wg/brski-cloud/issues/53 > 160 1.2.1. Owner Registrar Discovery ... > This option can be used to introduce the benefits of BRSKI for an > initial period when BRSKI is not available in existing EST-Servers. But > it can also be used long-term as an security-equivalent solution in > which BRSKI and EST-Server are set up in a modular fashion. > Would also suggest to add: > The use of an EST-Server instead of a BRSKI Registrar may mean thatno t > all the EST options required by [BRSKI] may be available and hence this > option may not support all BRSKI deployment cases. For example, > certificates to enroll into an ACP [RFC8994] needs to include an > AcpNodeName (see [RFC8994], Section 6.2.2), which non-BRSKI capable > EST-Servers ma not support. > At this point in the doc you need to insert 1.2.3 Summary https://github.com/anima-wg/brski-cloud/issues/54 > 204 If the cloud registrar issues a voucher itself without redirecting > 205 the pledge to an owner registrar, the cloud registrar will inform > the 206 pledge what domain to use for accessing EST services in the > voucher 207 response. > These two paragrapsh need to be specifically referring to which of the > section 1 mentioned use cases they are. Aka: in case of 1.2.2 ..., In > case of 1.2.2... https://github.com/anima-wg/brski-cloud/issues/55 > 209 Finally, when bootstrapping against an owner registrar, this 210 > registrar may interact with a backend CA to assist in issuing 211 > certificates to the pledge. The mechanisms and protocols by which 212 > the registrar interacts with the CA are transparent to the pledge and > 213 are out-of-scope of this document. > "will interact with a CA" (aka: i don't think we hacve a case where a > CA is not involved, but no need to express opinion about where it's > located "backend..." superflous). > More importantly: This paragraph applies to both owner registar and > owner EST-Server, rewrite all occurrances within paragraph to cover > both cases. (i think...!) https://github.com/anima-wg/brski-cloud/issues/56 > 219 TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2. > 220 Cloud Registrar returns VOUCHER pinning Owner Register. > This paragraph comes totall unexpected without context. Pinning is > unexplained. Maybe less ternse explanation here. https://github.com/anima-wg/brski-cloud/issues/57 > 242 Figure 1: High Level Architecture https://github.com/anima-wg/brski-cloud/issues/58 > 246 1. OEM - Equipment manufacturer. Operate the MASA. > The rest of the document does not use the term OEM. Delete https://github.com/anima-wg/brski-cloud/issues/59 I think we need this term. > 248 2. Network operator. Operate the Owner Registrar. Often operated > 249 by end owner (company), or by outsourced IT entity. > This is only used twice below and the second time its not clear its the > same operator. > 251 3. Network integrator. They operate a Cloud Registrar. https://github.com/anima-wg/brski-cloud/issues/60 > 253 2.2. Network Connectivity > 255 The assumption is that the pledge already has network connectivity > 256 prior to connecting to the cloud registrar. The pledge must have > an 257 IP address, must be able to make DNS queries, and must be able > to 258 send HTTP requests to the cloud registrar. The pledge operator > has > I would remove the "able to send HTTP requests" as this opens a rathole > of questions re. HTTP and mutual authentication, which are just > resolved later in the doc. https://github.com/anima-wg/brski-cloud/issues/61 > 262 2.3. Pledge Certificate Identity Considerations > 264 BRSKI section 5.9.2 specifies that the pledge MUST send an EST 265 > [RFC7030] CSR Attributes request to the registrar. The registrar MAY > which registrar - cloud or owner ? https://github.com/anima-wg/brski-cloud/issues/62 > 266 use this mechanism to instruct the pledge about the identities it > 267 should include in the CSR request it sends as part of enrollment. > 268 The registrar may use this mechanism to tell the pledge what > Subject 269 or Subject Alternative Name identity information to include > in its 270 CSR request. This can be useful if the Subject must have a > specific 271 value in order to complete enrollment with the CA. > So... In case of using an owner EST-Server instead of the Owner BRSKI > Registrar, this paragraph seems to hint at the option that the pledge > does the CSR Attribute request so that the Cloud registrar provides > this information because the EST-Server may not ? That should be said > more explicitly. > For the case of Cloud and Owner Registrar it seems that the CSR attr > request could also be sent to the cloud registrar, but also to owner > registrar. Should both be sent ?? Be more explicit please. https://github.com/anima-wg/brski-cloud/issues/63 > 280 For example, the pledge may only be aware of its IDevID Subject > which 281 includes a manufacturer serial number, but must include a > specific 282 fully qualified domain name in the CSR in order to > complete domain 283 ownership proofs required by the CA. > puuh... interesting, but bring up security challenge if i understand it > correctly: > So the pledge would learn attributes from the cloud registrar via > CSRattr request/reply and later on uses them in the cert enrolment step > with the EST-Server/Owner-Registrar. > Yes ? ... https://github.com/anima-wg/brski-cloud/issues/64 > 294 3.1.1. Cloud Registrar Discovery > 296 BRSKI defines how a pledge MAY contact a well-known URI of a cloud > 297 registrar if a local domain registrar cannot be discovered. > Actually, it would really be good if some text in the introduction of > brski cloud would discus/refer to RFC8995 section 2.7 "Cloud Registar", > such as: https://github.com/anima-wg/brski-cloud/issues/65 > 298 Additionally, certain pledge types may never attempt to discover a > 299 local domain registrar and may automatically bootstrap against a > 300 cloud registrar. > 302 The details of the URI are manufacturer specific, with BRSKI giving > 303 the example "brski-registrar.manufacturer.example.com". > Hmm. RFC8995 says: > performing a DNS lookup using a well-known URI such as > "brski-registrar.manufacturer.example.com" > but i think thats wrong text because "brski-..." is not a URI given how > it has no scheme. Sentence should have been "DNS lookup using the host > of the well-known URI". https://github.com/anima-wg/brski-cloud/issues/66 > 313 with pre-loaded trust-anchors that are used to validate the TLS 314 > connection. This can be using a public Web PKI trust anchors using 315 > [RFC6125] DNS-ID mechanisms, a pinned certification authority, or 316 > even a pinned raw public key. This is a local implementation 317 > decision. > I am mostly worried of this being mis-read such that it could be > appropriate to include the teirrbly long list of WebPKI Trust Anchors > and think thats good security. If we sa WebPKI it would certainlt be > good to suggest limiting WebPKI Trust anchros to only the ones known to > be required for the Cloud Registar. https://github.com/anima-wg/brski-cloud/issues/67 > 319 The pledge MUST NOT establish a provisional TLS connection (see > BRSKI 320 section 5.1) with the cloud registrar. > Reads confusingly here. Suggest to remove paragraph here and explain > after the following paragraph that compared to BRSKI, the TLS > connection is immediately mutually authenticated and not first a > provisional TLS connection as in BRSKI. https://github.com/anima-wg/brski-cloud/issues/68 > 322 The cloud registrar MUST validate the identity of the pledge by 323 > sending a TLS CertificateRequest message to the pledge during TLS 324 > session establishment. The cloud registrar MAY include a 325 > certificate_authorities field in the message to specify the set of 326 > allowed IDevID issuing CAs that pledges may use when establishing 327 > connections with the cloud registrar. > 329 The cloud registrar MAY only allow connections from pledges that > have 330 an IDevID that is signed by one of a specific set of CAs, e.g. > 331 IDevIDs issued by certain manufacturers. > How about we upgrade this ? > To protect itself against DoS attacks, the cloud registrar SHOULD > reject TLS connections when it can determine during TLS authentication > that it can not support the pledge, for example because the plege can > not provide an IDevID signed by a CA recognized/supported by the cloud > registrar. https://github.com/anima-wg/brski-cloud/issues/69 > 334 identity certificates or using Raw Public Key [RFC7250] > certificates. > I think you're mention this because you have a good business case, such > as reduction in manufacturing cost by doing self enrolment or raw > public keys during manufacturing and capturing those into MASA and > manufacturing databases - instead of also having to bother about a > CA. It might be useful to add a paragraph about this benefit, although > it is AFAIK not really BRSKI Cloud specific - but it seems like this > could be even a more common case as peldges with non-self-signed certs. https://github.com/anima-wg/brski-cloud/issues/70 > 339 registrar and has verified the cloud registrar PKI identity, the > s/and has verified the cloud registrar PKI identity,// ?? https://github.com/anima-wg/brski-cloud/issues/71 (I disagree) > 350 * return a suitable 4xx or 5xx error response to the pledge if the > 351 registrar is unwilling or unable to handle the voucher request > call this " * error: " ? https://github.com/anima-wg/brski-cloud/issues/72 -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
