On 2018-10-03 09:06, Joel M. Halpern wrote: > Off-list: > > It sounds from you rnote like either: > 1) Anima admission process is seriously underspecified in a way that > affects itneroperability, or
No, it's *intentionally* underspecified w.r.t. authorization. The registrar is part of a specific autonomic networking implementation, so I think it's OK that this is not standardized. Once there is established practice, it might be time to revisit this. > 2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and > advanced (if desired) by some other working group. I think BRSKI has the misfortune of being potentially quite general, but it is in fact required by Anima as the basis for the initial secure substrate. > I doubt either is your intention. Indeed not. > And statements such as Eliot's ill-formed comment that no one would do > that do not help the case for the Anima WG having thought this through. I think it's been thought through but badly articulated. In that sense, the Last Call is doing its job. Brian > > Yours, > Joel > > On 10/2/18 3:46 PM, Brian E Carpenter wrote: >> On 2018-10-03 08:00, Michael Richardson wrote: >>> >>> lear> I think we've lost sight of what we're talking about. We're >>> talking >>> lear> about a completely automated method for a local trust anchor to >>> be >>> lear> installed on a device, and a kick to EST for the device to >>> receive a >>> lear> local credential. For that to happen there needs to be a trusted >>> lear> introduction, and the device manufacturer or its agent is in the >>> best >>> lear> position to do that. >>> >>> Randy Bush <[email protected]> wrote: >>> > no. the owner's trust controller is. >>> >>> Cool. It's a relief to know that we've missed something obvious. >>> Could you please explain things more? >>> >>> We call the owner's trust controller the "Registrar", or sometimes the >>> Join-Registrar/Coordinator. I don't mind calling it a trust controller, but >>> maybe your term has a different meaning. >> >> There's a point that close followers of Anima may know and that others >> don't. There is a topic intentionally missed out of the BRSKI document, >> which is how the registrar decides whether a particular device, let's >> say device X12345, is allowed to join the secure domain in question. >> >> This point is skated over in the draft; in fact there is a text glitch >> in section 5.2 where it should be stated, already known to the authors. >> (Sorry, but we didn't find that text glitch soon enough to fix it before >> the IETF Last Call.) >> >> The actual authorization mechanism - "X12345 is allowed to join" - is >> not part of BRSKI. It is, as Randy rightly implies, not the business >> of the manufacturer. >> >> The MASA is used only to verify that X12345 is in fact X12345. It's >> part of the trust model, not the authorization model. >> >> If I had my wishes, the MASA would be optional, with a local voucher >> store in the registrar as the alternative. But that wasn't the WG >> consensus. >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima >> > . > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
