Hi Michael, Eliot and all, A clarification question: it sounds like there are two approaches proposed, not sure I understood it correctly:
Michael's proposal: there is a dedicated SSID, say "Anima", it is enabled by default, and there is no security. And that SSID can only do BRSKI, no other services permitted (just like the http portal authentication). After getting the certificate, then certificate-based EAP could be run to do the 802.1x authentication; or maybe they just negotiated a key for WPA2. In this case, the BRSKI just works as the bootstrap of WiFi. Eliot's proposal: we'll have a new EAP method, say "EAP-BRSKI", just treat BRSKI as an option encapsulated in EAP protocol, under the WiFi access framework. Michael and Eliot: did I get you correctly? B.R. Bing > -----Original Message----- > From: Anima [mailto:[email protected]] On Behalf Of Eliot Lear > Sent: Thursday, February 08, 2018 5:51 PM > To: Artur Hecker <[email protected]>; [email protected] > Subject: Re: [Anima] BRSKI over 802.11 > > Artur, > > I suspect much – but not all – of this could be addressed in EAP. > > Eliot > > > On 08.02.18 10:24, Artur Hecker wrote: > > Hi Michael > > > > > > Sorry, maybe I misunderstood the intention. Is your intention to make it > "standard" or just to make a demonstration? If the latter, then it's OK. It's > the > first that I simply doubt it will work. > > > > I am not claiming that there are better means to do that, let alone that > > what > you proposed makes no sense. I actually said that this makes sense. I just > think > that we enter the realms of 802.1 and 802.11 at the same time and have no > authority there. > > > > It has indeed nothing to do with Wireless access points. Any STA (802.11) > > and > any supplicant (802.1X) is subject to standardization and regulation of the > bodies > of IEEE, in any mode of operation. WPS should not be limited to any Access > Point presence, since it supports WiFi Direct. I agree, the supported methods > are > rudimentary. If I remember correctly, something like PIN, the push button you > mentioned, NFC and USB. > > > > I guess, a possibility would be to specify an additional ANIMA/ACP/BRSKI > method for WPS, why not. All I am saying is that we probably need to do it > there, > as any try to do it in the ANIMA WG would require specific 802.11 modes and > specific 802.1X functions/behaviours, which I am not sure we can dictate to > have. > > > > > > Regards > > artur > > > > > > > >> -----Original Message----- > >> From: Michael Richardson [mailto:[email protected]] > >> Sent: 07 February 2018 20:07 > >> To: Artur Hecker <[email protected]> > >> Cc: [email protected] > >> Subject: Re: [Anima] BRSKI over 802.11 > >> > >> > >> Artur Hecker <[email protected]> wrote: > >> > Hi Michael, > >> > My opinion: > >> > >> I don't think understood the question :-) > >> > >> 1) It's not about Wireless Access Points, so all of the Wifi Alliance, > >> etc. talk makes no sense to me. There can be no access points until > >> they > >> have been configured. It's possible that there might NEVER been any > >> access points, because the operator actually doesn't want/need any > >> enabled. > >> Think about inside of a cage in a data center. > >> > >> 2) It's about *devices* that have 802.11 interfaces. > >> You can't use WPS or anything else involving 802.1x until you have > >> credentials, which is what BRSKI gets you. > >> So you can't use WPS to *bootstrap* WPS. > >> (and pushing buttons on the front of the AP is by definition not > >> "zero- > >> touch") > >> > >> > Q3: Sorry, I did not quite understand this one. If you meant the > >> ad-hoc > >> > essid based network, my first intuition would be to object, as I > >> > believe that we should not prescribe such modes for ACP, but rather > >> use > >> > the best available one. > >> > >> 3) The ACP is secured inside IPsec over Link-Layer IPv6 (or MACSEC, or > >> a bunch of other possible technologies in the ACP document). > >> It's not about the security of the ACP. > >> > >> Since the point of the ACP is that it's always available, it needs to > >> be available even when the Wifi Access Point is toast or not yet > >> configured. > >> Of course, once there is a non-adhoc/IBSS network available, the ACP > >> would see this as additional interfaces and make additional mesh > >> links across it for the ACP to use. But that's not bootstrap, that's > >> operation. > >> > >> > Q4: As I believe that Q2 is strongly biased, I believe that so is > >> > Q4. The WiFi Alliance already specifies several ways how to bootstrap > >> > wireless access points, including e.g. WPS. We would rather need to > >> > see, how to integrate with such means. And again, I don't believe we > >> > have authority on that. > >> > >> Maybe you could point to specific documents that would permit two > >> devices which have never been touched to communicate over 802.11 > >> without configuration. > >> > >> -- > >> Michael Richardson <[email protected]>, Sandelman Software Works > >> -= IPv6 IoT consulting =- > >> > >> > > _______________________________________________ > > Anima mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/anima > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
