(some context - I've been talking internally to Max and Eliot about this quite
a bit)
First, a high level summary of 802.11u-2011 (which is incorporated into
802.11-2016) capabilities.
STAs and APs advertise support for 802.11u by setting the Interworking bit in
the Extended Capabilities IE, and by including the Interworking IE in Beacon,
Probe Request and Probe Response frames.
The Interworking IE includes info on:
- Access Network Type (Private, Free public, Chargeable public, etc.)
- internet bit (yes/no)
- ASRA (Additional Step required for Access - e.g. this could mean EAP-TLS, or
a BRSKI flow)
802.11u introduced ANQP Access Network Query Protocol which enables STAs to
query APs for info not present in Beacons/Probe Reponses.
ANQP defines these key IEs for enabling the STA to determine which network to
connect to:
Roaming consortium IE: includes the OI(s) of the roaming consortium(s). The OI
is typically provisioned on cell phones by the SP, so the cell phone can
automatically detect wifi networks that provide access to its SP's consortium.
3GPP Cellular Network IE: includes the Mobile Country Code (MCC) and Mobile
Network Code (MNC) of the SP the AP provides access to.
Network Access Identifier Realm IE: includes RFC4282 realm names that the AP
provides access to (e.g. wifi.service-provider.com). The NAI Realm IE also
includes info on the EAP type required to access that realm e.g. EAP-TLS.
Domain name IE: the domain name(s) of the local AP operator. Its purpose is to
enable a STA to connect to a domain operator that may have a more favourable
pricing model for backhaul connections to the internet / SP.
STAs can use some or all of the above IEs to make a suitable decision on which
SSID to pick.
HotSpot 2.0 is an example of a spec built on top of 802.11u and defines 10
additional ANQP elements using the standard vendor extensions mechanisms
defined in 802.11.
It also defines a HS2.0 Indication element that is includes in Beacons and
Probe Responses so that STAs can immediately tell if an SSID supports HS2.0.
That's the end of the .11u intro, but I'll come back to NAI Realms in a bit.
I agree with Nancy below on splitting this into SSID discovery and
connection/authentication steps. There were a few discovery options proposed in
this thread, and I'll add to that:
1. define a well-known naming convention for BRSKI capable SSIDs e.g.
BRSKI%xfinity
This goes against the grain of .11u whose whole purpose is for STAs to make a
decision on which SSID to use based on advertised capabilities, rather than
SSID naming convention.
Additionally, operators will not want to deploy a new SSID just to enable BRSKI
flows as each SSID eats up air space and wifi channel capacity due to beacon
overheads, etc. It would be better to add the relevant bits to the AQNP for an
existing SSID. From the operator perspective, that's modifying the config of an
existing SSID rather than deploying a new one.
2. Leverage existing 802.11u
It appears as if NAI Realm could be a possible mechanism for advertising BRSKI
capability (and Roaming consortium, 3GPP cellular network are not). We could
possibly piggy back on top of NAI Realm and advertise a realm of simply
"_bootstrapks". WLCs certainly appear to allow this kind of configuration
(although today some WLCs tie .11u configuration to HS2.0 configuration i.e.
you cannot enable advertising 802.11u bits without also advertising HS2.0 in
Beacons - but thats a WLC implementation gap not a standards gap).
The key conceptual difference is that we are using this special realm name more
as a logical service advertisement rather than as a backhaul internet provider
advertisement. This would not require any 802.11 IEEE spec changes, but could
fall into the realm of IETF spec definition. i.e. if you configure your
existing wifi network using existing 802.11u mechanisms to advertise this NAI
Realm, then IoT devices will know that this SSID offers BRSKI services.
Additionally (or alternatively...) as NAI Realm includes advertising the EAP
mechanism required, if a new EAP-BRSKI were to be defined, then this could be
advertised. STAs could just scan for an NAI Realm that enforced EAP-BRSKI, and
ignore the realm name.
One big issue with this is Eliot's point about "a business in an office
building on the 10th floor in New York City or London, where you might hear 2
dozen different networks". The STA ends up scanning a lot of SSIDs, and it may
find multiple SSIDs that advertise EAP-BRSKI or NAI Realm "_bootstrapks". It
would have to attempt to join all of them in sequence, and rely on the operator
configuring their network such that the manufacturer IDevID CA or the specific
IDevID is not trusted and rejects the device. It could also result in the STA
joining the wrong SSID, which would not be ideal.
3. Define new 802.11u extensions
Similar to HS2.0, we define a new BRSKI Indication Element that is advertised
in Beacons, and then define any additional AQNP elements as are required. This
is likely a standards body quagmire (and would also requires significant
infrastructure / WLC development if that's a consideration...)
4. Use / Extend WPS
None of the existing WPS mechanism are really suitable (PIN, push button, NFC,
USB). Extending WPS, similar to defining new 802.11u extensions, seems like a
standards body quagmire. Defining a new EAP-BRSKI mechanism seems more
tractable.
5. Use WiFi Device Provisioning Protocol (Eliot suggested this one)
Some comments on briefly reviewing this. At a high level, if we have a
bootstrapping Thing trying to discover and connect to an AP (with no one doing
supervision/handholding via a mobile app or anything), then the Thing is the
DPP Enrolee and the AP is the DPP Configurator. Additionally, the AP must
initiate the DPP exchange and not the Thing (the Thing must be the DPP
responder) because as per DPP, the Initiator must know in advance and validate
the bootstrapping public key (which would be the public key of the IDevID I
guess)of the Responder. This means that the AP must be continuously polling for
Things that it wants to bootstrap (and the Thing must be cycling through all
channels listening for a DPP initiation request, similar to standard SSID
passive scanning) . It needs further thought if this has any channel capacity
implications. The DPP groupId is meant to help with this I think...
One big advantage of this is that the Thing is not attempting (and potentially
failing, or worse - succeeding to connect to the wrong SSID) to connect to a
large number of SSIDs unlike option 2 NAI Realm. It also means that an operator
should not inadvertently claim someone else's Thing as it should be unlikely
that two Things will have identical bootstrapping public keys.
Anyways, once the device somehow knows the SSID, it can begin connection and
authentication.
There have been comments that pre-completing BRSKI, the client must connect to
an unsecure network. That's not entirely true. The network could in fact
enforce 802.1x and EAP-TLS based on the manufacturer's cert / IDevID.
Similarly, if an EAP-BRSKI mechanism were to be defined, the network could deny
access and not even allow the client to send its /requestvoucher unless it
successfully completed the initial TLS and presented a trusted IDevID. So it
could be a bootstrapping network segment that allows devices from trusted
manufacturers. That seems like a better alternative to using WPA-PSK with a
known network key or WAP-802.1x with a known username/password (both of which
require somehow provisioning that key into the device).
And on defining a new EAP-BRSKI mechanism, it should be possible to achieve
today what EAP-BRSKI would enable, albeit with 2 x 802.1x, 2 x DHCP requests. A
flow could be:
1. device discovers SSID
2. network enforces 802.1x EAP-TLS and checks that device has an IDevID signed
by a trusted manufacturer CA; if not deny access
3. AAA instructs WLC to put device in a network segment that grants it access
to the Registrar and nothing else
4. device does DHCP, gets and IP, and does the BRSKI dance and uses its IDevID
to get an LDevID
5. Once device has an LDevID, it does DHCP Release and an EAPOL-Logoff
6. Device restarts 802.1x
7. network enforces 802.1x EAP-TLS and this time checks that device has a
trusted LDevID
8. AAA instructs WLC to put device in a network segment that grants it access
to all required services
9. device does DHCP and we are done
Not saying that that complex flow is desirable, the 2x 802.1x and 2x DHCP will
make constrained Things baulk, but its feasible. And if we were to say use the
NAI Realms "_bootstrapks" mechanism, we could in theory build that solution out
now with no infrastructure revs, and with minimal standardisations effort (rfc
to define the use of NAI Realm).
The EAP-BRSKI flow would be something like:
1. device discovers SSID
2. network enforces 802.1x EAP-BRSKI and checks that device has an IDevID
signed by a trusted manufacturer CA; if not deny access
3. BRSKI flow takes place at L2, with /requestvoucher being tunnelled inside
EAP, etc.
4. Once device has completed BRSKI and has an LDevID, it gets its EAP-Success
5. AAA instructs WLC to put device in a network segment that grants it access
to all required services
6. device does DHCP and we are done
This is simpler than the 2 x 802.1x, 2 x DHCP above.
Owen
-----Original Message-----
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Toerless Eckert
Sent: Wednesday 14 February 2018 19:13
To: Michael Richardson <mcr+i...@sandelman.ca>
Cc: anima@ietf.org
Subject: Re: [Anima] BRSKI over 802.11
On Wed, Feb 14, 2018 at 02:08:20PM -0500, Michael Richardson wrote:
> > 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.).
>
> I'm willing to listen to ideas, but I'm afraid of going down the IEEE hole
> here.
Maybe i was unclear. I think we should just know the whole slew of tools
available from 802.11 that we can use without changing 802.11. I only know
SSID/ESSID, so i try to figure out how to abuse oops: well use them. Nancy
pointed to more tools.
> > 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.
>
> your suggestions are inline with what I was thinking.
Cheers
Toerless
> --
> 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
