On 15/07/2018 02:47, Eliot Lear wrote: > Brian, is it your contention that 802.11 is beyond the scope of > autonomic computing?
No, of course not. But autonomic nodes aren't supposed to connect to any old WiFi they happen to find; that's exactly the case where secure bootstrap needs to fail. If they connect to a network on which there's a registrar that knows nothing about them, it won't authorize them to join the ACP. "The domain registrar authenticates the pledge, makes authorization decisions,..." In Figure 3, I guess authorization is the tiny item "[accept device?]". BRSKI is defined in a nicely general way, but in an AN it's the domain registrar's job to decide who's allowed in. Actually there seems to be a glitch in the text on this. We find: > 5.2. Pledge Requests Voucher from the Registrar > ... > ...The registrar performs authorization as > detailed in [[EDNOTE: UNRESOLVED. See Appendix D "Pledge > Authorization"]]. but that leads nowhere that I can find. BRSKI authors, please comment. Brian > > > On 14.07.18 01:34, Brian E Carpenter wrote: >> On 13/07/2018 21:26, Owen Friel (ofriel) wrote: >>> I think its more accurate to state: >>> >>> “What a CUSTOMER 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.” E.g. I plug in a >>> wi-fi device and it connects to the SSID of the company on the floor below >>> me. >> That is so far outside the scope of the autonomic networking infrastructure >> application of BRSKI that I don't see why we'd even mention it. It's a case >> that definitely needs to fail hard in the autonomic context. >> >> If we want to extend the scope of BRSKI to cover BYOD on insecure WiFi, I >> think that's for some other WG. >> >> Brian >> >>> The MASA cannot help with this unless there is complex sales channel >>> integration and the MASA explicitly knows in advance exactly what network >>> each pledge will be connecting to. A potential option is to also require >>> the registrar to provide some proof of ownership to the MASA in the >>> VoucherRequest. >>> >>> From: Anima <[email protected]> On Behalf Of Eliot Lear >>> Sent: Thursday 12 July 2018 17:38 >>> To: Michael Richardson <[email protected]>; [email protected] >>> Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg >>> >>> >>> The problem is that the manufacturer doesn't have enough context to make >>> decisions as to which network to join. That is the challenge. >>> >>> On 12.07.18 17:12, Michael Richardson wrote: >>> >>> >>> >>> Eliot Lear <[email protected]><mailto:[email protected]> wrote: >>> >>> > 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. >>> >>> >>> >>> I don't understand how the "manufacturer" can have a desire ("the pledge >>> >>> avoid joining a network ...") that is different from the MASA's desire. >>> >>> >>> >>> The MASA *is* the expression manufacturer's desire. >>> >>> If the manufacturer has sales channel information that indicates the Pledge >>> >>> is on the wrong network, it should not issue a voucher. >>> >>> >>> >>> So the situation you describe makes no sense to me. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Anima mailing list >>> >>> [email protected]<mailto:[email protected]> >>> >>> https://www.ietf.org/mailman/listinfo/anima >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/anima >>> >> _______________________________________________ >> Anima mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
