Hi Toerless,
On 10.07.18 10:35, Toerless Eckert wrote: > Thanks Eliot > > Very interesting, but can you explain why you think this is in the > same ballpark as the issue Anoop raised ? Yes, the reason I mentioned this is that it seems like we may want some additional authentication mechanism, such as proof of knowledge *on top* of the voucher model – in some cases. This might involve labeling/BoM aspects. Also, where the MASA lives is an interesting question. From the AN perspective, at least to me, what is important is that the mechanism be tightly bound in terms of what code needs to be written, maybe with a few compile-time options. > > More inline. > > On Tue, Jul 10, 2018 at 08:43:30AM +0200, Eliot Lear wrote: >> Hi Toerless, >> >> When we look at this scenario, we should consider several factors: >> >> * The manufacturer is in a position to control both the MASA and the >> pledge. That's useful because it means that there is less >> interoperability friction if the manufacturer wants to pass >> additional parameters between the pledge and the manufacturer, so >> long as the registrar doesn't interfere. > Haha. I am not sure you want to mention "interoperability friction" > in a venue whose purpose in life is interoperability (IETF). > We discussed during BRSKI design this aspect, and i think > we can all see good flexiblity reasons for this side-channel, even > without having to blame ineroperability. > > The main issue is that it is a side-channel, and if there is any concerns > about BRKI it is the mistrust against manufacturers. SO i would hope that > any use of the side-channel would allow to establish the ability on > the registrar to passively analyze/observe that side-channel. Yes, that is an argument for documentation, and maybe some authorization. > >> * In WiFi we have two additional issues: a device needs to do ANIMA, >> but it needs to be authorized in some manner to do so. > You mean we have the issue of getting initial 802.11 credentials to the > pledge ? If not, then i didn't understand this bullet point. Yes. > >> * The second issue is one of network selection. There is a need for >> the pledge to really *know* that this is The network when 802.11 is >> involved. What a manufacturer wants to avoid is a pledge joining a >> network where the MASA just does the logging and does no validation, >> without any other means to determine that the device is on the >> correct network. Otherwise, the pledge (we could call it the >> "station" in this context) could simply home to the wrong network, >> and even resetting the device won't get you to the right network. > Right. BRSKI is called zero-touch, but there is really one touch left: > plugging a network cable into a right network port. With WiFi this can > be automated because selecting the right SSID can be done without > a human touch. I just wonder how we call it when we take one more touch > away. BRSKI double zero (with a license to kill) ? ;-)) Well, that is the work to be done. Someone else should name the solution, given how good I am at naming. > >> Owen will present something in Montreal that begins the discussion of >> these issues. > Great. > Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
