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.


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:anima-boun...@ietf.org] On Behalf Of Eliot Lear
>> Sent: Thursday, February 08, 2018 5:51 PM
>> To: Artur Hecker <artur.hec...@huawei.com>; anima@ietf.org
>> 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:mcr+i...@sandelman.ca]
>>>> Sent: 07 February 2018 20:07
>>>> To: Artur Hecker <artur.hec...@huawei.com>
>>>> Cc: anima@ietf.org
>>>> Subject: Re: [Anima] BRSKI over 802.11
>>>> Artur Hecker <artur.hec...@huawei.com> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
>>>> -= IPv6 IoT consulting =-
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima

Attachment: signature.asc
Description: OpenPGP digital signature

Anima mailing list

Reply via email to