Hi Bing, I think you've got it down, but I want to stress that these are early days, and I could, perhaps easily, be convinced to go another way. I think Michael is trying to do that ;-) I think the question is this: in a WiFi environment how can the device know which network to connect with in the first place, and how does it then send packets to complete the BRSKI flow?
As a difficult use case, consider a business in an office building on the 10th floor in New York City or London, where you might hear 2 dozen different networks. Eliot On 11.02.18 10:16, Liubing (Leo) wrote: > 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 >>>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
