Inline Toerless. -----Original Message----- From: Toerless Eckert [mailto:t...@cs.fau.de] Sent: Thursday 15 February 2018 22:44 To: Owen Friel (ofriel) <ofr...@cisco.com> Cc: Michael Richardson <mcr+i...@sandelman.ca>; anima@ietf.org; Max Pritikin (pritikin) <priti...@cisco.com>; Eliot Lear (elear) <el...@cisco.com> Subject: Re: [Anima] BRSKI over 802.11
Thanks, Owen, inline On Thu, Feb 15, 2018 at 07:54:48PM +0000, Owen Friel (ofriel) wrote: > (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. > [ofriel] One other comment on NAI Realms, WLCs often place artificial restrictions on the numbers of these than can be configured. 802.11 allows 2x octet count of realms, but WLCs could only allow e.g. 32. Additionally, big mobile SPs often have dozens of roaming partners, and these guys tend to use a single Roaming consortium OI instead of NAI Realms. > 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. Right. I've looked at http://web.mit.edu/freebsd/head/contrib/wpa/hostapd/hostapd.conf where it shows all the parameters you could configure. If we wanted to make this applicable to BRSKI i am mostly worried that we wold need to register somehow new values for parameters that allow only predefined values. [ofriel] Well, if we went down the path of using NAI Realms for BRSKI, NAI Realms already allows entry of free-form domains. It doesn't have pre-defined values for NAI Realms. What would be needed is some registry where we define the well-known NAI Realm that should be configured on the WLC. That wouldn't require IEEE changes. And that value could be defined in an IETF draft that points to an IANA registry..? [ofriel] That hostapd.conf file has a section " # NAI Realm information " outlining how to configure these, it also allows specification of the EAP Method Type, with that value being taken from the IANA registry. It gives examples for 13 (EAP-TLS) and 21 (EAP-TTLS) so if a EAP-BRSKI method were defined, that hostapd.conf already supports that type of config. Any idea what the process for that is ? [ofriel] If we wanted to e.g. advertise a new value for the Access Network Type bits in the Access Network Options octet in the Interworking IE, that's IEEE work I guess. If we wanted to define a new vendor extension IE (similar to HS2.0) then that's.. Wi-Fi alliance work..? > 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. Sure. But the whole world does not support 802.11u, and there is a lot of pre-existing practice to use well-known SSID names. [ofriel] By pre-existing practice, are you primarily referring to e.g. hotel 'guest' or 'internet' SSIDs? Are there other use cases defined in specs for example? > 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. Yes. The technical argument in favor of separate SSID is that it does not change the security model of existing SSIDs. Ideally, we wold want unencrypted SSID for BRSKI because we rely on the application layer crypto of the TSL level and the voucher. The typical use case would be that you want to allow for devices to use BRSKI to enroll into a service, and the service itself uses some 802.11 crypto for which you need the LDevID that you only get through BRSKI+EST. [ofriel] By configuring suitable AAA policy, we could possibly have our cake and eat it. Devices/BRSKI Pledges connect to a secure network enforcing some kind of 802.1x password-less authentication such as EAP-TLS, and ignore the infrastructure cert presented in the initial 802.1x EAP until after the BRSKI flow is complete (very similar to what the existing BRSKI draft does). And the AAA can determine based on the LDevID what to do with the bootstrapping device. Can you quantify the overhead of an SSID ? You can exclude the artifical overhead created by vendors like Cisco (could be Huawei too) like "you can only configure N SSID on the AP, if you want more, you have to pay more". [ofriel] Here is an SSID overhead calculator: http://www.revolutionwifi.net/revolutionwifi/p/ssid-overhead-calculator.html I'll also quote from two WLC recommended best practices as I do not claim by any means to be an expert here: https://www.cisco.com/c/en/us/td/docs/wireless/technology/wlc/8-5/82463-wlc-config-best-practice.html#pgfId-390434 " RF pollution increases as more SSIDs are added. Also, some smaller wireless stations such as PDA, WiFi Phones, and barcode scanners cannot cope with a high number of basic SSID (BSSID) information. This results in lockups, reloads, or association failures. Also, the more SSIDs, the more beaconing needed, which results in less RF time for real data transmits. It is recommended to have one to three SSIDs for an enterprise, and one SSID for high-density designs. AAA override can be leveraged for per user VLAN/settings on a single SSID scenario. " http://www.arubanetworks.com/assets/vrd/Aruba_VHD_VRD_Engineering_Configuration_Guide.pdf "Airtime is an extremely limited resource. To maximize performance, you must use the absolute minimum number of SSIDs. When SSIDs are created for specific user groups such as staff or press or ticketing, they generate significant additional beacon traffic throughout the area, which leaves less airtime for actual user traffic." > 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. Aka; NAI realm is your proposal for a 802.11u atribute that allow values without registration == no IETF process, and it could logically be argued how BRSKI is a NAI realm. [ofriel] Well, wouldn't it require some formal spec to register "_bootstrapks" as the correct value to configure in the NAI Realm? This would need to be baked into device firmware. Once could possibly see this is a pre-canned option in WLC config. Again, see above: My primary concern is how i can combine BRSKI with no 802.11 crypto with a service afterwards that uses 802.11 crypto. Using a single SSID. AFAIK, you can not have multiple crypto options on an SSID, or at least it would considered to be highly problematic to allows non-802.11 crypto based BRSKI on an SSID that otherwise should have 802.11 crypto. [ofriel] I think this could be possible via backend AAA config policy if you uses 802.11 and 802.1x. I plan on deploying a WLC and AAA to test this theory, hopefully before IETF 101... > 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. Yes. This is a problem independent of 802.11, just most likely to be happening with 802.11. It would be great if we could tackle this problem, but IMHO a draft doing that should not be specific to 802.11 because i feel a lot of what we could/should do here could expand beyond 802.11 [ofriel] Right. It would be good to frame the problem by identifying 2 or 3 specific deployment options (802.11 being one of those) and see if a common solution could be found. > 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...) Right. > 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. Well, not sure if you followed anima mailing list a few years back when we had that discussion, i also had a lot of OOB discussions about that, but i would always try to avoid going down that path if i can find a feasible solution not requireing any IEEE level work. [ofriel] No, not aware of prior discussions on this. Any pointers to the specific threads on the mailers you could provide so I can brush up would be appreciated.. > 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... Well. Would be happy to get more of a debrief of the details of DPP to figure out applicability without modification of IEEE level standards. [ofriel] Maybe Eliot can help here. I only read DPP for the first time last week. > 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. How would that work in the face of multi-operator domains supported by the AP ? Aka: on my home AP i can have xfinity and my own home network service, and we would not want to assume coordination betwen them about which of the two domain should claim a device. [ofriel] That is a good question! > 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. I am somewhat cautious as to how easy it would be to get all the necessary bits implemented in APs to support that approach without impacting the pre-existing SSID security. For example, if this requires to know something about IDevIDs on the radius server, and radius server upgrades, then it IMHO a nogo. [ofriel] Is the nogo about having to upgrade the AAA server to support new functionality, or the nogo about having to reconfigure the AAA using existing functionality? The former should be avoided if at all possible, but I don't see how the latter can be avoided... Having the AAA know about the IDevID manufacturer signing CA should fall into the realms of reconfiguring the AAA. > 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). This is getting back to the discussion i referred to a few years back. [ofriel] Well, that flow above about is enabling BRSKI without defining a new EAP-BRSKI mechanism and just leveraging existing EAP-TLS and existing AAA policy flexibility. The flow below relies on a new EAP-BRSKI mechanism > 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. Cheers toerless > > 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 -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
