WG-chair:
I would prefer for any work in this space to happen in
followup document(s), not in BRSKI itself.
I think anything done in ANIMA should purely be describing mechanisms
to leverage unmodified existing 802.11 mechanisms and ideally we find
some existing work that also built some form of layered standards
on top of 802.11.
The issue we IMHO need to overcome is that there
are ways how this could also be done by extending 802.11 and we
need to have an argument why that may be an option but it is
nonwithstanding for us to do it NOT that way. We had for example
also a long discussion in the beginning of ANIMA why not to use EAP
in BRSKI.
Nancy mentioned other 802.11 options beside SSID, so maybe we should
gate a decision to adopt any such work to the WG having sufficient
understanding of what the existing options in 802.11 are that
we could leverage without having to extend 802.11. Maybe we could
draft Nancy or some other 802.11 expert to give a summary to the WG
(802.11u eg.).
Contributor:
An ANIMA standardized method of BRSKI via 802.11 would be great.
A single AP may already provide SSIDs under different logical
administtrative domains. For example in SP-Wifi, where the AP
is logically paid for by a subscriber and residing in the subscribers
residence but also providing a managed "community" SSID from the
SP. For example with comcast that second SSID is called "xfinity"
and if you want to have access to that SSID on any of the other
subscribers AP, you also have to permit for xfinity SSID to be
enabled on your device (if you have one).
Note: all the following is only taking my limited knowledge of 802.11
into account, aka: might change when i learn about 802.11 or other
options. But the principles expressed below should stay the same.
And of course the impliciation is that you should be able to
have multiple SSIDs for BRSKI, one for each administrative
domain, because otherwise we would have to figure out how to set
up a multi-registrar / multi-operator BRSKI proxy/registrar
infra.
Aka: I would propose that the SSID (ESSID ?) scheme is something like:
BRSKI<char><existing-ssid>
<char> should be choosen to be least likely already used,
e.g.: "-" would be bad, but i am not sure what the most
obfuscated, 802.11 permitted char is. "%" ?
BRSKI%xfinity
BRSKI%tte-home-network
The selection rules for equipment would say to just try
all the BRSKI%... SSIDs. If we wanted to be fancy, we should
try to find a method to signal priority to pledges. Not sure
if there are any nicer attributed, but if not, wee could (yuck yuck)
do something like BRSKI%1%tte-homenet to indicate first
priority for that SSID.
We should also have
BRSKI<char><char><well-known-service>
The well-known-ssid would be requiring a specification how
pledges would select those. For example we could consider
some standardized cloud-service offered by multiple SPs
for home-automation - acme-aut. Equipment from various
vendors (sensors/actors) built against that standardized
cloud service would prefer BRSKI%%acme-aut over other
SSIDs to enroll. And the service would also hopefully
define a mechanism to allow such equipment to be enrolled
into the SSID of the subscriber itself, e.g.: by also
recognizing any higher priority existing-ssid (BRSKI%1%tte-homenet).
Or use a redirect in BRSKI itself....
Ok, i hope i get highscore for overdesigning the solution (kidding).
Aka: selecting the best SSID in face of competing offers
multiple or single AP is the type of work i think we should
give some tthought to. Ideally something extensible
where we can in the first spec get away with a most simple
start but will have forward compatibility with later
updates/extensions.
Cheers
Toerless
On Tue, Feb 13, 2018 at 02:31:36AM +0000, Nancy Cam-Winget (ncamwing) wrote:
> 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
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
