Hi,
Catching up on this thread....it is not clear to me that we can prescribe an
"SSID" as there can be a couple of solutions....
And for that level, I believe is out of scope for IETF; that said, there are a
couple of means to do this w/in 802.11 the cleanest one is using the
service/capability advertisements from 802.11u. The SSID is really not
sufficient on the 802.11 as we've build agility there as well to denote the
types of authentication and key management that we would also want to retain
(agility to) as we do this ala BRSKI. But, I break it down to "discovery" as
perhaps being an 802.11 scope and thereafter we can discuss work relevant here.
That said, for the actual enrollment would very well be suited to be in the EAP
realm as 802.11 already prescribes to using that model within 802.1X.
Hopefully that makes sense,
Nancy
On 2/12/18, 1:56 AM, "Anima on behalf of Eliot Lear" <anima-boun...@ietf.org
on behalf of l...@cisco.com> wrote:
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: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
>>>
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
