Fast Transition for Opportunistic Wireless Ecnryption (FT-OWE)
draft-henry-ft-owe-00

Document Type Active Internet-Draft (individual)
Authors Jerome Henry  , Stephen Orr 
Last updated 2021-06-14
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           J. Henry
Internet-Draft                                                    S. Orr
Intended status: Informational                                     Cisco
Expires: December 16, 2021                                 June 14, 2021

     Fast Transition for Opportunistic Wireless Ecnryption (FT-OWE)
                         draft-henry-ft-owe-00

Abstract

   Opportunistic Wireless Encryption, defined in RFC 8110, specifies an
   extension to IEEE Std 802.11 to provide for opportunistic
   (unauthenticated) encryption to a specific wireless access point
   (AP).  This memo extends the method to allow the establishment of OWE
   keying material to other APs before connection establishment, thus
   enabling a fast transition mode for OWE.

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 December 16, 2021.

Copyright Notice

   Copyright (c) 2021 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
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Henry & Orr             Expires December 16, 2021               [Page 1]
Internet-Draft                   FT-OWE                        June 2021

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements language . . . . . . . . . . . . . . . . . . . .   2
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
     3.1.  Crowd Wisdom  . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  802.11 Fast Transition  . . . . . . . . . . . . . . . . .   4
   4.  FT-OWE Operations . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Cryptography and Key Hierarchy  . . . . . . . . . . . . .   4
     4.2.  FT-OWE Discovery  . . . . . . . . . . . . . . . . . . . .   5
     4.3.  FT-OWE Association  . . . . . . . . . . . . . . . . . . .   6
     4.4.  FT-OWE Post-Association and Roaming . . . . . . . . . . .   6
       4.4.1.  Over-the-air FT-OWE authentication  . . . . . . . . .   6
       4.4.2.  Over-the-DS FT-OWE authentication . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   This document describes an extension to Opportunistic Wireless
   Encryption (OWE), defined in [RFC8110], that is compatible with
   802.11 multi-AP environments, where encrypted connections are
   expected between one client and more than one AP, with the light
   requirement that APs belong to the same Extended Service Set (ESS),
   i.e. communicate with one another over the same infrastructure.

2.  Requirements language

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
   appear in all capitals, as shown here.

3.  Background

   Opportunistic Wireless Encryption provides a mechanism for an 802.11
   station (STA) to establish an encrypted connection with an 802.11
   access point (AP).  OWE does not provide authentication, which means
   that the STA cannot know if the AP is legitimate or not (i.e. is part
   of the local network infrastructure or belongs to an attacker).  In
   many environments, the STA may need to establish an encrypted
   connection to multiple APs in succession and with short intervals.
   For example, the 802.11 Fine Timing Measurement (FTM) procedure

Henry & Orr             Expires December 16, 2021               [Page 2]
Internet-Draft                   FT-OWE                        June 2021

   supposes that a STA would measure its distance to multiple APs (which
   individual location is shared), and deduce from these measures its
   own location.  To increase the privacy of the exchanges, it is
   desirable that those exchanges would be protected from eavesdroppers.
   In such scenario, the STA would need to establish an encrypted link
   to each AP, in a rapid and consecutive manner.  There is a need for a
   mechanism to facilitate the secure key exchange between the STA and
   these APs, without wasting time on each AP channels before ranging
   can start.  In other scenarios, a STA would obtain information from
   one AP about other APs, for example through a Neighbor Report.  The
   STA may then need to exchange information with these other APs, such
   as capabilities, data broadcast information, or more details about
   the supporting network through ANQP messages.  To improve the
   reliability of the information obtained, the STA may want an
   indication that the second AP is part of the same system as the first
   AP.  In such scenario, the STA would need to establish an encrypted
   link to the second AP, and obtain an indication that the second AP is
   likely part of the same system as the first AP.  An extension of OWE
   allowing this multi-AP scenario provides such mechanism.

3.1.  Crowd Wisdom

   This requirement is especially present in public settings.  A large
   venue accessible to the general public is likely to include multiple
   legitimate APs, that are all part of the same system (e.g., "mall Wi-
   Fi").  There may also be some APs that are legitimate, but that are
   not part of a larger system (e.g., small store individual AP).  Last,
   there may be one or more illegitimate APs (e.g., attacker APs).
   Although OWE is not intended to provide authentication, extending OWE
   to a multiple-APs scenario also has the virtue of providing to the
   STA this indication that several APs can communicate with one
   another, and thus have established a trusted relationship over the
   network (e.g., through a wired communication, directly or via a
   central WLAN controller).  Such communication is not a guarantee that
   the APs are legitimate, but offers a good indication that, if a first
   AP provides some information, the second AP is likely to provide
   information that is consistent of that of the first AP.  As such, if
   FT-OWE does not provide authentication, it provides an element of
   crowd wisdom, where a STA can build confidence that a set of APs is
   coherent.  This confidence is useful when a STA needs to exchange
   information with more than one AP in a short amount of time, and use
   that information to make a decision.  For example, if APs 1 to 3
   provide coherent location and ranging information and can communicate
   with one another, but APs 4 and 5 provide incoherent ranging or
   location information and cannot communicate with APs 1 to 3, then a
   location algorithm running on the end device would have no difficulty
   classifying APs 4 and 5 as suspicious outliers (e.g., possible evil
   twins), even if they announce the same SSIDs as APs 1 to 3, and even

Henry & Orr             Expires December 16, 2021               [Page 3]
Internet-Draft                   FT-OWE                        June 2021

   if APs 1 to 3 list APs 4 and 5 MAC addresses (BSSID) as known.
   Without the knowledge of such backend trusted communication, the
   client would be left with location values provided by five APs of
   equal legitimacy value.  The same logic applies to other
   unauthenticated exchanges, where the STA can easily form coherent
   groups of APs, which information is likely to display consistent
   value.

3.2.  802.11 Fast Transition

   To extend OWE to a multi-AP scenario, a mechanism comparable to
   802.11FT is needed. 802.11 Fast Basic Service Set (BSS) Transition
   (FT) is a mechanism initially intended for associated and
   authenticated STAs and APs.  With FT, a key hierarchy is created.  A
   first level key (called Pairwise Masker Key R0, PMK-R0) is used to
   generate second level sets of keys (PMK-R1) that are specific to the
   connection between a STA and an AP.  PMK-R0 is established when the
   STA connects to the network, and is used to derive the keying
   material specific to the connection of the STA to the first AP.
   Then, when the STA detects and needs to transition to a second AP,
   depending on what is signaled in the Mobility Domain Element from the
   AP [IEEE802.11] clause 9.4.2.46, the STA will authenticate Over-the-
   Air or Over-the-DS as defined in [IEEE802.11] section 13.5.  With
   either method (Over-the-Air or Over-the-DS) the keying material (PMK-
   R1) required for the secured communication between the STA and the
   second AP is obtained before the STA joins the second AP.  This
   process allows the STA to expedite the process of joining the second
   AP and resuming encrypted data exchange.

4.  FT-OWE Operations

4.1.  Cryptography and Key Hierarchy

   As specified in [IEEE802.11] clause 12.7.6.1, the PMK is obtained
   upon successful authentication and association between the STA and
   the network.  In a coordinated network system where APs communicate
   with one another, it is expected that a single entity (e.g. a Primary
   AP, or a Wireless LAN Controller) will be in charge of generating the
   public key defined in [RFC8110] section 4.3.  Once the PMK generation
   between the STA and the network completes as per [RFC8110] section
   4.4, a Master PMK is generated, following the process defined by
   [IEEE802.11] clause 12.7.1.6.3, where: MPMK = PMK generated as the
   result of OWE authentication in [RFC8110] section 4.4 PMKID =
   Truncate-128(Hash(C | A)) as defined in [RFC8110] section 4.4 Thus
   where C is the client's Diffie-Hellman public key from the 802.11
   association request, A is the Authenticator (primary AP or WLAN
   controller) Diffie-Hellman public key from the 802.11 association
   response, and Hash is the hash algorithm defined in [RFC8110] section

Henry & Orr             Expires December 16, 2021               [Page 4]
Internet-Draft                   FT-OWE                        June 2021

   4.1.  Once the MPMK has been derived, each side (AP/WLC and STA)
   derives the PMK-R0 value, following [IEEE802.11] clause 12.7.1.6.3,
   and where: R0-Key-Data = KDF-Hash-Length(MPMK, \FT-R0", SSIDlength ||
   SSID || MDID || R0KHlength || R0KH-ID || S0KH-ID) PMK-R0 = L(R0-Key-
   Data, 0, Q) PMK-R0Name-Salt = L(R0-Key-Data, Q, 128) Length = Q + 128
   Where Q is the length of the curve p defined in [RFC8110] section
   4.1, KDF-Hash-Length is the key derivation function as defined in
   [IEEE802.11] clause 12.7.1.6.2 using the hash algorithm identified by
   [RFC8110] table 2, SSIDlength is a single octet whose value is the
   number of octets in the SSID SSID is the service set identifier, a
   variable length sequence of octets, as it appears in the Beacon and
   Probe Response frames MDID is the Mobility Domain Identifier field
   from the Mobile Domain element (MDE) that was used during FT initial
   mobility domain association R0KHlength is a single octet whose value
   is the number of octets in the R0KH-ID R0KH-ID is the identifier of
   the holder of PMK-R0 in the Authenticator S0KH-ID is the STA, or
   Supplicant's MAC address (SPA) The PMK-R0 is referenced and named as
   follows: PMKR0Name = Truncate-128(Hash(\FT-R0N" || PMK-R0Name-Salt))
   where Hash is the hash algorithm identified by [RFC8110] table 2,
   \FT-R0N" is treated as an ASCII string The PMKR0Name is used to
   identify the PMK-R0.  Once the PMK-R0 was determined, each side
   derives a PMK-R1 key, specific to the connection between the STA and
   a given AP, and used to derive the PTK.  The PMK-R1 derivation
   follows the process defined in [IEEE802.11] clause 12.7.1.6.4, where:
   PMK-R1 = KDF-Hash-Length(PMK-R0, \FT-R1", R1KH-ID || S1KH-ID) where
   KDF-Hash-Length is the key derivation function as defined in
   [IEEE802.11] 12.7.1.6.2 Hash is the hash algorithm identified by
   [RFC8110] table 2 Length is the length of the hash algorithm's digest
   PMK-R0 is the first level key in the FT key hierarchy R1KH-ID is a
   MAC address of the holder of the PMK-R1 in the Authenticator of the
   AP S1KH-ID is the SPA The PMK-R1 is then referenced and named as
   follows: PMKR1Name = Truncate-128(Hash(\FT-R1N" || PMKR0Name || R1KH-
   ID || S1KH-ID)) where Hash is the hash algorithm identified by
   [RFC8110] table 2 \FT-R1N" is treated as an ASCII string PMKR1Name is
   used to identify the PMK-R1.  The PTK is then defined following the
   KDF method described in [IEEE802.11] clause 12.7.1.6.5.

4.2.  FT-OWE Discovery

   An access point advertises support for FT-OWE using an Authentication
   and Key Management (AKM) suite selector for FT-OWE, illustrated in
   table 1, in its beacons and probe responses.
   +-------+-----+-------------+---------+-----------+ | OUI | Suite |
   Authentication | Key | Key | | | Type | Type | Management |
   derivation | | | | | Type | type |
   +-------+-----+-------------+---------+-----------+ | 00-0F-AC |
   [TBD] | FT-Opportunistic | This | [IEEE802.11] | | | | Wireless |
   Document | 12.7.1.6.2 | | | | Encryption | | |

Henry & Orr             Expires December 16, 2021               [Page 5]
Internet-Draft                   FT-OWE                        June 2021

   +-------+-----+-------------+---------+-----------+ The access point
   also advertises the Mobility Domain element (MDE) defined in
   [IEEE8021.11] clause 9.4.2.46.  The Mobility Domain element includes
   the 2-octets Mobility Domain Identifier that names the mobility
   domain supported by all APs in the same roaming domain, and the FT
   Capability and Policy Field that indicates if FT is set to occur over
   the air or over the DS.  A STA in the process of discovering FT-OWE-
   compliant APs can use the above information, and can also insert the
   MDE in its probe requests.

4.3.  FT-OWE Association

   Once a STA discovers an FT-OWE-compliant AP, it performs an
   authentication as defined in [IEEE802.11], with the Authentication
   Algorithm number set to [TBD] (FT-OWE).  The STA then proceeds to the
   FT-OWE association phase.  In the Association Request frame, the STA
   includes the MDE defined in [IEEE802.11] and the Diffie-Hellman
   Parameter element (DHPE) defined in [RFC8110] section 4.3.  The DHPE
   includes the STA public key.  In the Association Response frame, the
   AP includes the MDE, and the Fast BSS Transition Element (FTE)
   defined in [IEEE802.11] clause 9.4.2.47.  The FTE also includes the
   R0KH-ID and the R1KH-ID for the AP.  The AP also includes the Diffie-
   Hellman Parameter element (DHPE) defined in [RFC8110] section 4.3.
   The DHPE includes the AP public key.

4.4.  FT-OWE Post-Association and Roaming

   Once association is completed, the STA and the AP derive the PMK-R0,
   then the PMK-R1 for the current STA/AP pair, then the matching PTK.
   Later, the STA will need to establish a secure association with
   another AP (called the target AP) part of the same mobility domain as
   a the current AP.  In this scenario, it is expected that the STA will
   have discovered the target AP through a scanning process during which
   the target AP MAC address was discovered.

4.4.1.  Over-the-air FT-OWE authentication

   To perform OTA FT-OWE, the STA follows the process indicated in
   [IEEE802.11] clause 13.5.2.  The STA first sends to the target AP an
   FT-OWE Authentication Request.  The request indicates FT-OWE as the
   Authentication Algorithm, includes the RSNE with the PMKR0Name value,
   includes the MDE, and includes the FTE with a SNonce and the R0KH-ID.
   It is expected that the target AP should be able to communicate with
   a primary AP or a WLAN controller, recognize the PMKR0Name and R0KH-
   ID, and be able to derive the information needed to derive a PMKR1
   value.  The target AP responds with an FT-OWE Authentication
   Response.  The response indicates FT-OWE as the Authentication
   Algorithm, includes the RSNE with the PMKR0Name value, includes the

Henry & Orr             Expires December 16, 2021               [Page 6]
Internet-Draft                   FT-OWE                        June 2021

   MDE, and includes the FTE with the ANonce, the SNonce, the target AP
   R1KH-ID and the R0KH-ID.  At this stage, the FT-OWE authentication to
   the target AP has completed, and stays valid until the expiration of
   the reassociation deadline time.  It is understood that the STA may
   establish such authentication to multiple target APs.  Later, when
   the STA needs to associate to the target AP and proceed to secure
   exchanges, and while the authentication is still valid, the STA sends
   a FT-OWE reassociation request to the target AP.  The request
   includes the RSNE with the PMKR1Name value, the MDE, the FTE with MIC
   (as defined in [RFC8110] section 4.4), ANonce, SNonce, the R1KH1-ID
   obtained during the authentication phase, R0KH-ID, and the Diffie-
   Hellman Parameter element (DHPE) defined in [RFC8110] section 4.3.
   The DHPE includes the STA public key.  The Target AP responds with a
   FT-OWE Reassociation response.  The response includes the RSNE with
   the PMKR1Name for the target AP, the MDE, the FTE with MIC (as
   defined in [RFC8110] section 4.4), ANonce, SNonce, the target AP
   R1KH1-ID, R0KH-ID, the and the Diffie-Hellman Parameter element
   (DHPE) defined in [RFC8110] section 4.3.  The DHPE includes the STA
   public key.  At the conclusion of the reassociation, both sides
   compute the PMKR1 as described in section 4.4, then the matching PTK.

4.4.2.  Over-the-DS FT-OWE authentication

   To perform Over-the-DS FT-OWE, the STA follows the process indicated
   in [IEEE802.11] clause 13.5.3.  The STA first sends to the current AP
   an FT-OWE Request.  The request is an action frame, and includes the
   STA MAC address, the target AP BSSID, the RSNE with the PMKR0Name,
   the MDE, and the FTE with a SNonce and the R0KH-ID.  The current AP
   passes the request, over the DS, to the target AP.  The target AP
   responds with a FT Response containing the STA MAC address, the
   target AP BSSID, the RSNE with the PMKR0Name, the MDE, and the FTE
   with a MIC (as defined in [RFC8110] section 4.4), ANonce, SNonce,
   R1KH-ID for the target AP, and R0KH-ID.  The current AP relays this
   response to the STA through an FT Response action frame.  The STA
   responds with an FT confirm action frame sent to the current AP.  The
   frame includes the STA MAC address, the target AP BSSID, the RSNE
   with the PMKR1Name (derived from the PMKR0Name, the R1KH-ID obtained
   above from the target AP, and the STA MAC address (S1KH-ID), as
   defined in [IEEE802.11] clause 12.7.1.4.1), the MDE, and the FTE with
   a MIC (as defined in [RFC8110] section 4.4), ANonce, SNonce, R1KH-ID
   for the target AP, and the R0KH-ID.  The current AP forwards this
   message over the Distribution System to the target AP.  The target AP
   then replies with an FT ACK message, that includes the STA MAC
   address, the target AP BSSID, the RSNE with the PMKR1Name, the MDE,
   the FTE with a MIC ((as defined in [RFC8110] section 4.4), the
   ANonce, Snonce, R1KH-ID and R0KH-ID, and the Timeout Interval Element
   (TIE) that specifies the reassociation deadline value.  At this
   stage, the FT-OWE authentication to the target AP has completed, and

Henry & Orr             Expires December 16, 2021               [Page 7]
Internet-Draft                   FT-OWE                        June 2021

   stays valid until the expiration of the reassociation deadline time.
   It is understood that the STA may establish such authentication to
   multiple target APs.  Later, when the STA needs to associate to the
   target AP and proceed to secure exchanges, and while the
   authentication is still valid, the STA proceeds through the FT-OWE
   reassociation exchange with the target AP as described in section
   4.4.1.

5.  IANA Considerations

   This document does not require any IANA actions.

6.  Security Considerations

   FT-OWE does not provide authentication.  FT-OWE provides a
   cryptographic assurance that a target AP with which a STA has
   established an FT-OWE connection is derived from an FT-OWE connection
   to its current AP, assuring each AP (current and target) have a
   trusted network connection with each other, and thus the information
   provided by both APs are likely coherent.  FT-OWE does not guarantee
   that the APs are legitimate.  When a large set of APs provide
   coherent information and allow for FT-OWE communication, it is likely
   that all these APs are part of the same system.  The system may be
   legitimate or not.  OWE is not a replacement for any authentication
   protocol specified in [IEEE802.11] and is not intended to be used
   when an alternative that provides real authentication is available.

Authors' Addresses

   Jerome Henry
   Cisco

   Email: jerhenry@cisco.com

   Stephen Orr
   Cisco

   Email: sorr@cisco.com

Henry & Orr             Expires December 16, 2021               [Page 8]