Internet DRAFT - draft-henry-ft-owe
draft-henry-ft-owe
Network Working Group J. Henry
Internet-Draft S. Orr
Intended status: Informational Cisco
Expires: 16 June 2022 13 December 2021
Fast Transition for Opportunistic Wireless Ecnryption (FT-OWE)
draft-henry-ft-owe-01
Abstract
Opportunistic Wireless Encryption, defined in RFC 8110, specifies an
extension to the 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 to these
APs, 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 16 June 2022.
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Henry & Orr Expires 16 June 2022 [Page 1]
Internet-Draft FT-OWE December 2021
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 . . . . . . . . . . . . . . . . . . . . 6
4.3. FT-OWE Association . . . . . . . . . . . . . . . . . . . 6
4.4. FT-OWE Post-Association and Roaming . . . . . . . . . . . 6
4.4.1. Over-the-air FT-OWE authentication . . . . . . . . . 7
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
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
Henry & Orr Expires 16 June 2022 [Page 2]
Internet-Draft FT-OWE December 2021
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
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
Henry & Orr Expires 16 June 2022 [Page 3]
Internet-Draft FT-OWE December 2021
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.11 FT 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-R1s) that are each specific
to the connection between a STA and a given 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 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,
Henry & Orr Expires 16 June 2022 [Page 4]
Internet-Draft FT-OWE December 2021
\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.
Henry & Orr Expires 16 June 2022 [Page 5]
Internet-Draft FT-OWE December 2021
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 | | |
+-------+-----+-------------+---------+-----------+ 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.
Henry & Orr Expires 16 June 2022 [Page 6]
Internet-Draft FT-OWE December 2021
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
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
Henry & Orr Expires 16 June 2022 [Page 7]
Internet-Draft FT-OWE December 2021
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.
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
Henry & Orr Expires 16 June 2022 [Page 8]
Internet-Draft FT-OWE December 2021
Stephen Orr
Cisco
Email: sorr@cisco.com
Henry & Orr Expires 16 June 2022 [Page 9]