[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



Network Working Group                                           O. Friel
Internet-Draft                                                   E. Lear
Intended status: Standards Track                             M. Pritikin
Expires: September 3, 2018                                         Cisco
                                                           M. Richardson
                                                Sandelman Software Works
                                                          March 02, 2018


                         BRSKI over IEEE 802.11
                   draft-friel-brski-over-802dot11-00

Abstract

   This document outlines the challenges associated with implementing
   Bootstrapping Remote Secure Key Infrastructures over IEEE 802.11 and
   IEEE 802.1x networks.  Multiple options are presented for discovering
   and authenticating to the correct IEEE 802.11 SSID.  This initial
   draft is a discussion document and no final recommendations are made
   on the recommended approaches to take.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 3, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Friel, et al.           Expires September 3, 2018               [Page 1]


Internet-Draft                 BRSKI-WIFI                     March 2018


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Potential SSID Discovery Mechanisms . . . . . . . . . . . . .   4
     2.1.  Incorrect SSID Discovery  . . . . . . . . . . . . . . . .   4
     2.2.  Well-known BRSKI SSID . . . . . . . . . . . . . . . . . .   4
     2.3.  802.11aq  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  802.11u NAI Realm . . . . . . . . . . . . . . . . . . . .   6
     2.5.  802.11u Interworking Information - Internet . . . . . . .   7
     2.6.  Define new 802.11u Extensions . . . . . . . . . . . . . .   7
     2.7.  Wi-Fi Protected Setup . . . . . . . . . . . . . . . . . .   7
     2.8.  Wi-Fi Device Provisioning Profile . . . . . . . . . . . .   7
   3.  Potential Authentication Options  . . . . . . . . . . . . . .   8
     3.1.  SSID Considerations . . . . . . . . . . . . . . . . . . .   9
     3.2.  IP Address Assignment Considerations  . . . . . . . . . .  10
     3.3.  Unauthenticated Pre-BRSKI and EAP-TLS Post-BRSKI  . . . .  10
     3.4.  PSK Pre-BRSKI and 802.1X EAP-TLS Post-BRSKI . . . . . . .  10
     3.5.  802.1X EAP-TLS Pre-BRSKI and 802.1X EAP-TLS Post-BRSKI  .  11
     3.6.  New 802.1X EAP-BRSKI mechanism  . . . . . . . . . . . . .  11
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   6.  Informative References  . . . . . . . . . . . . . . . . . . .  13
   Appendix A.  802.11 Primer  . . . . . . . . . . . . . . . . . . .  15
     A.1.  802.11i . . . . . . . . . . . . . . . . . . . . . . . . .  15
     A.2.  802.11u . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   Bootstrapping Remote Secure Key Infrastructures (BRSKI)
   [I-D.ietf-anima-bootstrapping-keyinfra] describes how a device can
   bootstrap against a local network using an Initial Device Identity
   X.509 [IEEE802.1AR] IDevID certificate that is pre-installed by the
   vendor on the device in order to obtain an [IEEE802.1AR] LDevID.  The
   BRSKI flow assumes the device can obtain an IP address, and thus
   assumes the device has already connected to the local network.
   Further, the draft states that BRSKI use of IDevIDs:

      allows for alignment with 802.1X network access control methods,
      its use here is for Pledge authentication rather than network
      access control.  Integrating this protocol with network access




Friel, et al.           Expires September 3, 2018               [Page 2]


Internet-Draft                 BRSKI-WIFI                     March 2018


      control, perhaps as an Extensible Authentication Protocol (EAP)
      method (see [RFC3748], is out-of-scope.

   The draft does not describe any mechanisms for how an [IEEE802.11]
   enabled device would discover and select a suitable [IEEE802.11] SSID
   when multiple SSIDs are available.  A typical deployment scenario
   could involve a device begin deployed in a location were twenty or
   more SSIDs are being broadcast, for example, in a multi-tenanted
   building or campus where multiple independent organizations operate
   [IEEE802.11] networks.

   In order to reduce the administrative overhead of installing new
   devices, it is desirable that the device will automatically discover
   and connect to the correct SSID without the installer having to
   manually provision any network information or credentials on the
   device.  It is also desirable that the device does not discover,
   connect to, and automatically enroll with the wrong network as this
   could result in a device that is owned by one organization connecting
   to the network of a different organization in a multi-tenanted
   building or campus.

   Additionally, as noted above, the BRSKI draft does not describe how
   BRSKI could potentially align with [IEEE802.1X] authentication
   mechanisms.

   This document outlines multiple different potential mechanisms that
   would enable a bootstrapping device to choose between different
   available 802.11 SSIDs in order to execute the BRSKI flow.  This
   document also outlines several options for how 802.11 networks
   enforcing 802.1X authentication could enable the BRSKI flow, and
   describes the required device behaviour.

1.1.  Terminology

   802.11u: an amendment to the IEEE 802.11-2007 standard to add
   features that improve interworking with external networks.

   ANQP: Access Network Query Protocol

   AP: IEEE 802.11 Access Point

   CA: Certificate Authority

   EAP: Extensible Authentication Protocol

   EST: Enrollment over Secure Transport





Friel, et al.           Expires September 3, 2018               [Page 3]


Internet-Draft                 BRSKI-WIFI                     March 2018


   HotSpot 2.0 / HS2.0: Wi-Fi Alliance standard that enables cell phones
   to roam seamlessly between cellular and IEEE 802.11 networks.

   IDevID: Initial Device Identifier

   LDevID: Locally Significant Device Identifier

   SSID: 802.11 Service Set Identifier

   STA: IEEE 802.11 station

   WLC: Wireless LAN Controller

2.  Potential SSID Discovery Mechanisms

   This section outlines multiple different mechanisms that could
   potentially be leveraged that would enable a bootstrapping device to
   choose between multiple different available 802.11 SSIDs.  As noted
   previously, this draft does not make any final recommendations.

2.1.  Incorrect SSID Discovery

   As will be seen in the following sections, there are several
   discovery options where the deivce can choose an incorrect SSID and
   attempt to join the wrong network.  For example, the device is being
   deployed by one organization in a multi-tenant campus, and chooses to
   connect to the SSID of a different organization.  The device is
   dependent upon the incorrect network rejecting its BRSKI enrollment
   attempt.  It is possible that the device could end up enrolled with
   the wrong network.

2.2.  Well-known BRSKI SSID

   A standardized naming convention for SSIDs offering BRSKI services is
   defined such as:

   o  BRSKI%ssidname

   Where:

   o  BRSKI: is a well-known prefix string of characters.  This prefix
      string would be baked into device firmware.

   o  %: is a well known delimiter character.  This delimiter character
      would be baked into device firmware.

   o  ssidname: is the freeform SSID name that the network operator
      defines.



Friel, et al.           Expires September 3, 2018               [Page 4]


Internet-Draft                 BRSKI-WIFI                     March 2018


   Device manufacturers would bake the well-known prefix string and
   character delimiter into device firmware.  Network operators
   configuring SSIDs which offer BRSKI services would have to ensure
   that the SSID of those networks begins with this prefix.  On
   bootstrap, the device would scan all available SSIDs and look for
   ones with this given prefix.

   If multiple SSIDs are available with this prefix, then the device
   could simply round robin through these SSIDs and attempt to start the
   BRSKI flow on each one in turn until it succeeds.

   This mechanism suffers from the limitations outlined in Section 2.1 -
   it does nothing to prevent a device enrolling against the same
   network.

   Another issue with defining a specific naming convention for the SSID
   is that this may require network operators to have to deploy a new
   SSID.  In general, network operators attempt to keep the number of
   unique SSIDs deployed to a minimum as each deployed SSID eats up a
   percentage of available air time and network capacity.  A good
   discussion of SSID overhead and an SSID overhead [calculator] is
   available.

2.3.  802.11aq

   [IEEE802.11aq] is currently being worked by the IEEE, but is not yet
   finalized, and is not yet supported by any vendors in shipping
   product. 802.11aq defines new elements that can be included in 802.11
   Beacon, Probe Request and Probe Response frames, and defines new
   elements for ANQP frames.

   The extensions allow an AP to broadcast support for backend services,
   where allowed services are those registered in the [IANA] Service
   Name and Transport Protocol Port Number Registry.  The services can
   be advertised in 802.11 elements that include either:

   o  SHA256 hashes of the registered service names

   o  a bloom filter of the SHA256 hashes of the registered service
      names

   Bloom filters simply serve to reduce the size of Beacon and Probe
   Response frames when a large number of services are advertised.  If a
   bloom filter is used by the AP, and a device discovers a potential
   service match in the bloom filter, then the device can query the AP
   for the full list of service name hashes using newly defined ANQP
   elements.




Friel, et al.           Expires September 3, 2018               [Page 5]


Internet-Draft                 BRSKI-WIFI                     March 2018


   If BRSKI were to leverage 802.11aq, then the 802.11aq specification
   would need to be pushed and supported, and a BRSKI service would need
   to be defined in [IANA].

   This mechanism suffers from the limitations outlined in Section 2.1 -
   it does nothing to prevent a device enrolling against the same
   network.

2.4.  802.11u NAI Realm

   [IEEE802.11u] defines mechanisms for interworking.  An introduction
   to 802.11u is given in the appendices.  The 802.11u NAI Realm IE
   could be a possible mechanism for advertising BRSKI capability.
   BRSKI could possibly piggy back on top of NAI Realm and simply
   advertise an NAI Realm of "_bootstrapks".  Wireless LAN Controllers
   (WLC) appear to allow this kind of configuration today.

   Note that today some WLCs tie 802.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 with this NAI Realm proposal is that
   BRSKI uses this special realm name more as a logical service
   advertisement rather than as a backhaul internet provider
   advertisement.  Leveraging the NAI Realm to advertise a service is
   conceptually very similar to what 802.11aq is attempting to achieve.

   Leveraging NAI Realm would not require any 802.11 specification
   changes, and could be defined by this IETF draft.  Note that the
   author's are not aware of any currently defined IETF or IANA
   namespaces that define NAI Realms.  Device manufacturers would bake
   the well-known NAI Realm string into device firmware.  Network
   operators configuring SSIDs which offer BRSKI services would have to
   ensure that the SSID offered an NAI Realm with this specific name.
   On bootstrap, the device would scan all available SSIDs and use ANQP
   to query for NAI Realms matching the BRSKI service name.

   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.  Devices could then scan for an NAI
   Realm that enforced EAP-BRSKI, and ignore the realm name.

   This mechanism suffers from the limitations outlined in Section 2.1 -
   it does nothing to prevent a device enrolling against the same
   network.





Friel, et al.           Expires September 3, 2018               [Page 6]


Internet-Draft                 BRSKI-WIFI                     March 2018


   Additionally, as the IEEE is attempting to standardize logical
   service advertisement via 802.11aq, 802.11aq would seem to be the
   more appropriate option than overloading NAI Realm.  However, it is
   worth noting that configuring of NAI Realms is supported today by
   WLCs.

2.5.  802.11u Interworking Information - Internet

   It is possible that an SSID may be configured to provide unrestricted
   and unauthenticated internet access.  This could be advertised in the
   Interworking Information IE by including:

   o  internet bit = 1

   o  ASRA bit = 0

   If such a network were discovered, a device could attempt to use the
   BRSKI well-known vendor cloud Registrar.  Possibly this could be a
   default fall back mechanism that a device could use when determining
   which SSID to use.

2.6.  Define new 802.11u Extensions

   Of the various elements currently defined by 802.11u for potentially
   advertising BRSKI, NAI Realm is the only element that is a possible
   option, as outlined above.  The Roaming Consortium and 3GPP Cellular
   Network elements are not suitable at all.  Another option that has
   been suggested in the IETF mailers is defining an extension to
   802.11u specifically for advertising BRSKI service capability.

   802.11aq appears to be the proposed mechanism for generically
   advertising any service capability, provided that service is
   registered with [IANA].  It is probably a better approach to
   encourage adoption of 802.11aq and register a service name for BRSKI
   with [IANA] rather than attempt to define a completely new BRSKI-
   specific 802.11u extension.

2.7.  Wi-Fi Protected Setup

   This is probably a bad idea for reasons to be documented...

2.8.  Wi-Fi Device Provisioning Profile

   The [DPP] specification defines how an entity that is already trusted
   by a network can assist an untrusted entity in enrolling with the
   network.  The description below assumes the 802.11 network is in
   infrastructure mode.  DPP introduces multiple key roles including:




Friel, et al.           Expires September 3, 2018               [Page 7]


Internet-Draft                 BRSKI-WIFI                     March 2018


   o  Configurator: A logical entity that is already trusted by the
      network that has capabilities to enroll and provision devices
      called Enrollees.  A Configurator may be a STA or an AP.

   o  Enrollee: A logical entity that is being provisioned by a
      Configurator.  An Enrollee may be a STA or an AP.

   o  Initiator: A logical entity that initiates the DPP Authentication
      Protocol.  The Initiator may be the Configurator or the Enrollee.

   h- Responder: A logical entity that responds to the Initiator of the
   DPP Authentication Protocol.  The Responder may be the Configurator
   or the Enrollee.

   In order to support a plug and play model for installation of
   devices, where the device is simply powered up for the first time and
   automatically discovers the network without the need for a helper or
   supervising application, for example an application running on a
   smart cell phone or tablet that performs the role of Configurator,
   then this implies that the AP must perform the role of the
   Configurator and the device or STA performs the role of Enrollee.
   Note that the AP may simply proxy DPP messages through to a backend
   WLC, but from the perspective of the device, the AP is the
   Configurator.

   The DPP specification also mandates that the Initiator must know in
   advance and validate the bootstrapping public key of the Responder.
   For BRSKI purposes, the DPP bootstrapping public key will be the
   [IEEE802.1AR] IDevID of the device.  As the boostrapping device
   cannot know in advance the bootstrapping public key of a specific
   operators network, this implies that the Configurator must take on
   the role of the Initiator.  Therefore, the AP must take on the roles
   of both the Configurator and the Initiator.

   More details to be added...

3.  Potential Authentication Options

   When the bootstrapping device determines which SSID to connect to,
   there are multiple potential options available for how the device
   authenticates with the network while bootstrapping.  Several options
   are outlined in this section.  This list is not exhaustive.

   At a high level, authentication can generally be split into two
   phases using two different credentials:

   o  Pre-BRSKI: The device can use its [IEEE802.1AR] IDevID to connect
      to the network while executing the BRSKI flow



Friel, et al.           Expires September 3, 2018               [Page 8]


Internet-Draft                 BRSKI-WIFI                     March 2018


   o  Post-BRSKI: The device can use its [IEEE802.1AR] LDevID to connect
      to the network after completing BRSKI enrollment

   The authentication options outlined in this document include:

   o  Unauthenticated Pre-BRSKI and EAP-TLS Post-BRSKI

   o  PSK Pre-BRSKI and 802.1X EAP-TLS Post-BRSKI

   o  802.1X EAP-TLS Pre-BRSKI and 802.1X EAP-TLS Post-BRSKI

   o  New 802.1X EAP-BRSKI mechanism

   These mechanisms are described in more detail in the following
   sections.

3.1.  SSID Considerations

   [IEEE802.11i] allows an SSID to advertise multiple authentication
   mechanisms.  A very brief introduction to 802.11i is given in the
   appendices.  For example, a single SSID could advertise both PSK and
   802.1X authentication mechanisms.  When a network operator needs to
   enforce two different authentication mechanisms, one for pre-BRSKI
   devices and one for post-BRSKI devices, the operator has two options:

   o  configure one SSID advertising both authentication mechanisms

   o  configure two SSIDs with each one advertising a different
      authentication mechanism

   Devices should be flexible enough to handle both potential scenarios.
   When discovering a pre-BRSKI SSID, the device should also discover
   the authentication mechanism enforced by the SSID that is advertising
   BRSKI support.  If the device supports the authentication mechanism
   being advertised, then the device can connect to the SSID in order to
   initiate the BRSKI flow.  For example, the device may support 802.1X
   as a pre-BRSKI authentication mechanism, but may not support PSK as a
   pre-BRSKI authentication mechanism.

   Once the device has completed the BRKSI flow and has obtained an
   LDevID, a mechanism is needed to tell the device which SSID to use
   for post-BRSKI network access.  This may be a different SSID to the
   pre-BRSKI SSID.  The mechanism by which the post-BRSKI SSID is
   advertised to the device is out-of-scope of this version of this
   document.






Friel, et al.           Expires September 3, 2018               [Page 9]


Internet-Draft                 BRSKI-WIFI                     March 2018


3.2.  IP Address Assignment Considerations

   If a device has to perform two different authentications, one for
   pre-BRSKI and one for post-BRSKI, network policy will typically
   assign the device to different VLANs for these different stages, and
   assign the device different IP addresses depending on which network
   segment the device is assigned to.  This will generally be true even
   if a single SSID is used for both pre-BRSKI and post-BRSKI
   connections.  Therefore, the bootstrapping device must be able to
   completely reset its network connection and network software stack,
   and obtain a new IP address between pre-BRSKI and post-BRSKI
   connections.

3.3.  Unauthenticated Pre-BRSKI and EAP-TLS Post-BRSKI

   The device connects to an unauthenticated network pre-BRSKI.  The
   device connects to a network enforcing 802.1X EAP-TLS post-BRSKI.
   The device uses its LDevID as the post-BRSKI 802.1X credential.

   To be completed..

3.4.  PSK Pre-BRSKI and 802.1X EAP-TLS Post-BRSKI

   The device connects to a network enforcing PSK pre-BRSKI.  The
   mechanism by which the PSK is provisioned on the device for pre-BRSKI
   authentication is out-of-scope of this version of this document.  The
   device connects to a network enforcing 802.1X EAP-TLS post-BRSKI.
   The device uses the LDevID obtained via BRSKI as the post-BRSKI
   802.1X credential.

   When the device connects to the post-BRSKI network that is enforcing
   802.1X EAP-TLS, the device uses its LDevID as its credential.  The
   device should verify the certificate presented by the server during
   that EAP-TLS exchange against the trusted CA list it obtained during
   BRSKI.

   If the 802.1X network enforces a tunneled EAP method, for example
   [RFC7170], where the device must present an additional credential
   such as a password, the mechanism by which that additional credential
   is provisioned on the device for post-BRSKI authentication is out-of-
   scope of this version of this document.  NAI Realm may be used to
   advertise the EAP methods being enforced by an SSID.  It is to be
   determined if guidelines should be provided on use of NAI Realm for
   advertising EAP method in order to streamline BRSKI.







Friel, et al.           Expires September 3, 2018              [Page 10]


Internet-Draft                 BRSKI-WIFI                     March 2018


3.5.  802.1X EAP-TLS Pre-BRSKI and 802.1X EAP-TLS Post-BRSKI

   The device connects to a network enforcing 802.1X EAP-TLS pre-BRSKI.
   The device uses its IDevID as the pre-BRSKI 802.1X credential.  The
   device connects to a network enforcing 802.1X EAP-TLS post-BRSKI.
   The device uses its LDevID as the post-BRSKI 802.1X credential.

   When the device connects to a pre-BRSKI network that is enforcing
   802.1X EAP-TLS, the device uses its IDevID as its credential.  The
   deivce should not attempt to verify the certificate presented by the
   server during that EAP-TLS exchange, as it has not yet discovered the
   local domain trusted CA list.

   When the device connects to the post-BRSKI network that is enforcing
   802.1X EAP-TLS, the device uses its LDevID as its credential.  The
   deivce should verify the certificate presented by the server during
   that EAP-TLS exchange against the trusted CA list it obtained during
   BRSKI.

   Again, if the post-BRSKI network enforces a tunneled EAP method, the
   mechanism by which that second credential is provisioned on the
   device is out-of-scope of this version of this document.

3.6.  New 802.1X EAP-BRSKI mechanism

   A new EAP method, let's call it EAP-BRSKI, is defined that
   encapsulates the full BRSKI flow.  At a high level, this enables the
   device to obtain an LDevID during the Layer 2 authentication stage.
   This has multiple advantages including:

   o  avoids the need for the device to potentially connect to two
      different SSIDs during bootstrap

   o  the device only needs to handle one authentication mechanism
      during bootstrap

   o  the device only needs to obtain one IP address, which it obtains
      after BRSKI is complete

   o  avoids the need for the device to have to disconnect from the
      network, reset its network stack, and reconnect to the network

   o  potentially simplifies network policy configuration

   The device discovers and connects to a network enforcing 802.1X EAP-
   BRSKI.  A high level EAP-BRSKI flow would look something like:





Friel, et al.           Expires September 3, 2018              [Page 11]


Internet-Draft                 BRSKI-WIFI                     March 2018


   o  Device starts the EAP flow by sending the EAP TLS ClientHello
      message

   o  EAP server replies and includes CertificateRequest message, and
      may specify certificate_authorities in the message

   o  if the device has an LDevID and the LDevID issuing CA is allowed
      by the certificate_authorities list (i.e. the issuing CA is
      explicitly included in the list, or else the list is empty) then
      the device uses its LDevID to establish the TLS tunnel

   o  if the device does not have an LDevID, or certificate_authorities
      prevents it using its LDevID, then the device uses its IDevID to
      establish the TLS tunnel

   o  if certificate_authorities prevents the device from using its
      IDevID (and its LDevID if it has one) then the device fails to
      connect

   The EAP server continues with TLS tunnel establishment:

   o  if the device certificate is invalid or expired, then the EAP
      server fails the connection request.

   o  if the device certificate is valid but is not allowed due to a
      configured policy on the EAP server, then the EAP server fails the
      connection request

   o  if the device certificate is accepted, then the EAP server
      establishes the TLS tunnel and starts the tunneled EAP-BRSKI
      procedures

   At this stage, the EAP server has some policy decisions to make:

   o  if network policy indicates that the device certificate is
      sufficient to grant network access, whether it is an LDevID or an
      IDevID, then the EAP server simply initiates the Crypto-Binding
      TLV and 'Success' Result TLV exchange.  The device can now obtain
      an IP address and connect to the network.

   o  if the device certificate is an LDevID, the EAP server may
      instruct the device via a new EAP TLV to do an [RFC7030] EST
      'simplereenroll' using its LDevID.  Assuming the 'simplereenroll'
      completes successfully, the EAP server completes the exchange by
      initiating the Crypto-Binding TLV and 'Success' Result TLV
      exchange.





Friel, et al.           Expires September 3, 2018              [Page 12]


Internet-Draft                 BRSKI-WIFI                     March 2018


   o  the EAP server may instruct the device to initialise a full BRSKI
      flow.  Typically, the EAP server will instruct the device to
      initialize a BRSKI flow when it presents an IDevID, however, the
      EAP server may instruct the device to initialize a BRSKI flow even
      if it presented a valid LDevID.  The device sends all BRSKI
      messages, for example 'requestvoucher', inside the TLS tunnel
      using new EAP TLVs.  Assuming the BRSKI flow completes
      successfully and the device is issued an LDevID, the EAP server
      completes the exchange by initiating the Crypto-Binding TLV and
      'Success' Result TLV exchange.

   Once the EAP flow has successfully compelted, then:

   o  network policy will automatically assign the device to the correct
      network segment

   o  the device obtains an IP address

   o  the device can access production service

4.  IANA Considerations

   [[ TODO ]]

5.  Security Considerations

   [[ TODO ]]

6.  Informative References

   [calculator]
              Revolution Wi-Fi, "SSID Overhead Calculator", n.d.,
              <http://www.revolutionwifi.net/revolutionwifi/p/
              ssid-overhead-calculator.html>.

   [DPP]      Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol",
              n.d., <https://www.wi-fi.org/file/wi-fi-device-
              provisioning-protocol-dpp-draft-technical-specification-
              v0023>.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-11 (work in progress), February 2018.






Friel, et al.           Expires September 3, 2018              [Page 13]


Internet-Draft                 BRSKI-WIFI                     March 2018


   [IANA]     Internet Assigned Numbers Authority, "Service Name and
              Transport Protocol Port Number Registry", n.d.,
              <https://www.iana.org/assignments/service-names-port-
              numbers/service-names-port-numbers.xhtml>.

   [IEEE802.11]
              IEEE, ., "Wireless LAN Medium Access Control (MAC) and
              Physical Layer (PHY) Specifications", 2016.

   [IEEE802.11aq]
              IEEE, ., "802.11 Amendment 5 Pre-Association Discovery",
              2017.

   [IEEE802.11i]
              IEEE, ., "802.11 Amendment 6 Medium Access Control (MAC)
              Security Enhancements", 2004.

   [IEEE802.11u]
              IEEE, ., "802.11 Amendment 9 Interworking with External
              Networks", 2011.

   [IEEE802.1AR]
              IEEE, ., "Secure Device Identity", 2017.

   [IEEE802.1X]
              IEEE, ., "Port-Based Network Access Control", 2010.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <https://www.rfc-editor.org/info/rfc3748>.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282,
              DOI 10.17487/RFC4282, December 2005,
              <https://www.rfc-editor.org/info/rfc4282>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

   [RFC7170]  Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
              "Tunnel Extensible Authentication Protocol (TEAP) Version
              1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
              <https://www.rfc-editor.org/info/rfc7170>.





Friel, et al.           Expires September 3, 2018              [Page 14]


Internet-Draft                 BRSKI-WIFI                     March 2018


Appendix A.  802.11 Primer

A.1.  802.11i

   802.11i-2004 is an IEEE standard from 2004 that improves connection
   security. 802.11i-2004 is incorporated into 802.11-2014. 802.11i
   defines the Robust Security Network IE which includes information on:

   o  Pairwise Cipher Suites (WEP-40, WEP-104, CCMP-128, etc.)

   o  Authentication and Key Management Suites (PSK, 802.1X, etc.)

   The RSN IEs are included in Beacon and Probe Response frames.  STAs
   can use this frame to determine the authentication mechanisms offered
   by a particular AP e.g.  PSK or 802.1X.

A.2.  802.11u

   802.11u-2011 is an IEEE standard from 2011 that adds features that
   improve interworking with external networks. 802.11u-2011 is
   incorporated into 802.11-2016.

   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 information on:

   o  Access Network Type (Private, Free public, Chargeable public,
      etc.)

   o  Internet bit (yes/no)

   o  ASRA (Additional Step required for Access - e.g.  Acceptance of
      terms and conditions, On-line enrollment, etc.)

   802.11u introduced Access Network Query Protocol (ANQP) which enables
   STAs to query APs for information not present in Beacons/Probe
   Responses.

   ANQP defines these key IEs for enabling the STA to determine which
   network to connect to:

   o  Roaming consortium IE: includes the Organization Identifier(s) of
      the roaming consortium(s).  The OI is typically provisioned on
      cell phones by the SP, so the cell phone can automatically detect
      802.11 networks that provide access to its SP's consortium.



Friel, et al.           Expires September 3, 2018              [Page 15]


Internet-Draft                 BRSKI-WIFI                     March 2018


   o  3GPP Cellular Network IE: includes the Mobile Country Code (MCC)
      and Mobile Network Code (MNC) of the SP the AP provides access to.

   o  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.

   o  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 specification 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 included in Beacons and Probe Responses so
   that STAs can immediately tell if an SSID supports HS2.0.

Authors' Addresses

   Owen Friel
   Cisco

   Email: ofriel@cisco.com


   Eliot Lear
   Cisco

   Email: lear@cisco.com


   Max Pritikin
   Cisco

   Email: pritikin@cisco.com


   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca





Friel, et al.           Expires September 3, 2018              [Page 16]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/