| Internet-Draft | FT-OWE | June 2021 |
| Henry & Orr | Expires 16 December 2021 | [Page] |
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.¶
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 16 December 2021.¶
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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
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.¶
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.¶
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 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.¶
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 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.¶
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.¶
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 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.¶
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 | | | +-------+-----+-------------+---------+-----------+ 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.¶
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.¶
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.¶
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 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.¶
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 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.¶
This document does not require any IANA actions.¶
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.¶