On 11-Aug-20 13:22, Roman Danyliw wrote: > Hi Toerless! > > Thanks for your detailed follow-up both in the form of the -28 and the > helpful explanations below. I think everything is cleaned up but the last > discuss, I will update my ballot so it's easier to manage. > > Roman > >> -----Original Message----- >> From: Toerless Eckert <[email protected]> >> Sent: Tuesday, July 28, 2020 11:38 AM >> To: Roman Danyliw <[email protected]> >> Cc: The IESG <[email protected]>; draft-ietf-anima-autonomic-control- >> [email protected]; [email protected]; [email protected]; Sheng Jiang >> <[email protected]> >> Subject: Re: Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control- >> plane-27: (with DISCUSS and COMMENT)
.... > >>> ** Section 11. Per the list of factors on which ACP depends, it seems >>> like the following are missing: >>> >>> -- the security properties of the enrollment protocol >>> >>> -- that the security considerations of EST and BRSKI apply (or if not, >>> why not) >> >> Resolution: >> >> No change, but the following explanations: >> >> The ACP is explicitly defined to be a set of nodes with ACP domain >> certificates, >> enrollment/BRSKI is really out of scope. Normative ACP nodes start their >> existance with an ACP cert. How they got it is part of a prior life. BRSKI >> security >> properties are covered in BRSKI draft. >> >> I struggled long how to well define registrars given that ACP does not >> mandate/ >> specify any specific protocol. The solution in the document is that there >> is only >> a very abstract definition of the normative requirements against registrars >> in >> 6.10.7, pretty much simple requirements against the resulting certificates >> such >> as registrar MUST NOT assign same addresses to multiple nodes for example. >> >> Think of a registrar abstractely as this: >> >> https://datatracker.ietf.org/meeting/102/materials/slides-102-dinrg-dinrg- >> anima-toerless-eckert-00 >> Slide 10 >> >> While funny, its not far away from a possible reality of a network operator >> being a registrar, provisioning ACP certificates manually into ACP nodes, and >> performing all the backend operations (CA, MASA, adressing database). >> >> BRSKI is of course the ANIMA preferred enrollment protocol, and if it is >> used, >> an ACP node is called an ANI node (ACP+BRSKI). Section 3.2 makes the security >> property of the ACP for any such bootstrap protocol. For example in >> communities outside of ANIMA, NetConf ZeroTouch might be preferred over >> BRSKI. >> >> The only mandatory ACP part of your above list is EST ONLY for renewal of >> certificates, an that of course is specified in the normative section. >> >> The BRSKI draft itself defines how it integrates with ACP (GRASP objective >> etc.). >> >> Hope this answers satisfactory the concern. > > I reread the Section 11 with your explanation in mind and see your > perspective -- it's difficult to be specific without mandating a specific > protocol. However, there seems to be two concrete, normative elements of > this architecture -- EST and GRASP. The latter for bootstrapping and the > formal for renewal. It isn't clear then why their Sec Considerations don't > apply. Furthermore, the protocols and practices of the bootstrapping process > are out of scope of this document but seem like a security building block on > which ACP is being built. The use of GRASP for adding a node to the ACP must not rely on the ACP for security, but in "normal life" GRASP must rely on the ACP for security. Although GRASP has been sitting in the RFC queue for >2 years, I think it does cover this fairly clearly: 2.5. GRASP Protocol Basic Properties and Mechanisms . . . . . 12 2.5.1. Required External Security Mechanism . . . . . . . . 12 [that's the ACP] 2.5.2. Discovery Unsolicited Link-Local (DULL) GRASP . . . . 13 [that's for booting the ACP] In other words, GRASP section 2.5.1 depends on ACP security, and ACP security depends on GRASP section 2.5.2. Would a cross reference from ACP to GRASP in the last paragraph of ACP section 11 help? Also, three paragraphs above, there is this: In combination with BRSKI, ACP enables a resilient, fully zero-touch network solution... Would another reference to draft-ietf-anima-bootstrapping-keyinfra there help? The three documents (ACP, BRSKI, GRASP) really do chase each other's tails. Regards Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
