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,

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.
    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 
    > 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 
    >> 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 
    >> specific 802.1X functions/behaviours, which I am not sure we can dictate 
    >> 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 
    >>>>     > 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 
    >>>> 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 
    >>>>     > Q4: As I believe that Q2 is strongly biased, I believe that so is
    >>>>     > Q4. The WiFi Alliance already specifies several ways how to 
    >>>>     > wireless access points, including e.g. WPS. We would rather need 
    >>>>     > 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

Reply via email to