RFC 8110

Opportunistic Wireless Encryption

📅 published March 2017, from ietf

Title Block and Vibe Check 🎀

okay bestie, let's get into RFC 8110, Opportunistic Wireless Encryption 🦋. It's an Informational doc (so NOT a Standards Track spec, just published for info 💅), written by D. Harkins, Ed. from HP Enterprise and W. Kumari, Ed. from Google. It's from March 2017, lives in the ISSN 2070-1721 series, and it doesn't obsolete or update anything. Clean slate, no cap ✨.

Abstract 💜

The whole point is that this memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption on the wireless medium 🌸. Translation: encrypt the Wi-Fi air, but don't bother checking who anyone is 🙈.

Status of This Memo 🍓

This document is not an Internet Standards Track specification; it is published for informational purposes 💖.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841 🧚.

Info about the current status of this doc, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc8110 ✨.

Copyright Notice 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 🫶.

Table of Contents 🌈

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
  1.2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  802.11 Network Access . . . . . . . . . . . . . . . . . . . .   4
4.  Opportunistic Wireless Encryption . . . . . . . . . . . . . .   5
  4.1.  Cryptography  . . . . . . . . . . . . . . . . . . . . . .   5
  4.2.  OWE Discovery . . . . . . . . . . . . . . . . . . . . . .   6
  4.3.  OWE Association . . . . . . . . . . . . . . . . . . . . .   7
  4.4.  OWE Post-Association  . . . . . . . . . . . . . . . . . .   8
  4.5.  OWE PMK Caching . . . . . . . . . . . . . . . . . . . . .  10
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
6.  Implementation Considerations . . . . . . . . . . . . . . . .  10
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction 🦋

1.1. Requirements Language 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 💖.

1.2. Notation 🌸

This memo uses the following notation 👑:

y = F(X)
    An element-to-scalar mapping function.  For an elliptic curve
    group, it takes a point on the curve and returns the
    x-coordinate; for a finite field element, it is the identity
    function, just returning the element itself.

Z = DH(x,Y)
    For an elliptic curve, DH(x,Y) is the multiplication of point Y
    by the scalar value x, creating a point on the curve Z; for
    finite field cryptography, DH(x,Y) is an exponentiation of
    element Y to the power of x (implied modulo a field defining
    prime, p) resulting in an element Z.

a = len(b)
    Indicates the length in bits of the string b.

2. Background ✨

Okay so internet access is now expected everywhere, like coffee shops, airports, and hotels ☕✈️. A lot of the time it's offered over "Open" (unencrypted) Wi-Fi, because handing out a passphrase (or using other auth solutions) is just not convenient or realistic 🙈. Ideally everyone would use a VPN on sketchy networks, but literally nobody always does 😭. So their traffic is exposed to sniffing, like from someone in the next hotel room running Wireshark, or pervasive monitors, etc 💀.

Also, lots of businesses (coffee shops, bars) give out free Wi-Fi to get customers to stay and hang out 🍓. Customers totally pick a place based on whether there's free Wi-Fi 👀. But these businesses aren't ISPs, so they're often unwilling and/or unqualified to do complicated network config 🙃. And customers really don't want to do complicated device setup just to get free Wi-Fi 💅. So the popular move is a network protected by a shared, public Pre-Shared Key (PSK) that's printed on a sandwich board at the entrance, chalked on a wall, or on the menu 🍽️. The PSK gets used in a cryptographic handshake, defined in [IEEE802.11], called the "4-way handshake", to prove you know the PSK and derive traffic encryption keys for bulk wireless data 🔑.

The belief is that this protects the wireless medium from passive sniffing and simple attacks. That belief is erroneous 😭. Since the PSK is known by everyone, a passive attacker can observe the 4-way handshake and compute the traffic encryption keys used by a client and access point (AP) 💀. If the attacker is too late to see that exchange, they can send a forged "deauthenticate" frame that makes the client and/or AP reset the 802.11 state machine and redo the 4-way handshake, so the passive attacker can figure out the traffic keys anyway 🙀.

With OWE, the client and AP do a Diffie-Hellman key exchange during the access procedure, and then use the resulting pairwise secret with the 4-way handshake instead of a shared, public PSK 🦋.

OWE needs no special configuration or user interaction, but it gives a higher level of security than a common, shared, and public PSK 🌈. It's more secure for the end user AND easier for both the provider and the end user, because there are no public keys to maintain, share, or manage 👑.

3. 802.11 Network Access 🎀

Wi-Fi access points (APs) advertise themselves using frames called "beacons" 📡. These frames tell clients in earshot the SSID (Service Set Identifier) the AP is advertising, the AP's Media Access Control (MAC) address (known as its "BSSID" (Basic Service Set Identifier)), the security policy governing access, the symmetric ciphers it uses for unicast and broadcast frames, QoS info, and support for other optional features of [IEEE802.11] 💖. Wi-Fi clients can also actively discover APs by sending "probe requests", which are queries that APs answer with "probe responses" 🔍. A probe response carries basically the same info as a beacon ✨.

Once a client finds an AP, actively through probing or passively through beacons, it starts a two-step method to get network access 🚀. Step one is "802.11 authentication". For most access methods this is an empty exchange called "Open Authentication", basically the client says "authenticate me" and the AP says "ok, you're authenticated" 🥰. Step two is 802.11 association, where the client asks the AP for network access (the SSID, which type of subsequent authentication to use, any pairwise and group ciphers, etc.) using an 802.11 association request. The AP replies with an 802.11 association response 💌.

If the network is Open (no authentication and no encryption), the client has network access right after 802.11 association finishes 🌸. If the network enforces PSK authentication, the AP starts the 4-way handshake using the PSK to authenticate the client and derive traffic encryption keys 🔐.

To add an opportunistic encryption mode of access to [IEEE802.11], it is necessary to perform a Diffie-Hellman key exchange during 802.11 authentication and use the resulting pairwise secret with the 4-way handshake 🧚.

4. Opportunistic Wireless Encryption 💜

4.1. Cryptography 🔥

Doing a Diffie-Hellman key exchange requires agreeing on a domain parameter set to work in. OWE uses a registry (see [IKE-IANA]) to map an integer into a complete domain parameter set 📚. OWE supports both Elliptic Curve Cryptography (ECC) and Finite Field Cryptography (FFC) 🦋.

OWE uses a hash algorithm to generate a secret and a secret identifier. The specific hash algorithm depends on the group chosen for the Diffie-Hellman. For ECC, it depends on the size of the prime defining the curve p 🌈:

SHA-256: when len(p) <= 256
SHA-384: when 256 < len(p) <= 384
SHA-512: when 384 < len(p)

For FFC, the hash algorithm depends on the prime, p, defining the finite field 💅:

SHA-256: when len(p) <= 2048
SHA-384: when 2048 < len(p) <= 3072
SHA-512: when 3072 < len(p)

4.2. OWE Discovery 🛸

An access point advertises OWE support using an Authentication and Key Management (AKM) suite selector for OWE 📢. This AKM is shown in Table 1 and gets added to the Robust Security Network (RSN) element, defined in [IEEE802.11], in all beacons and probe response frames the AP sends 🎀.

+----------+--------+-------------------+-------------+-------------+
|   OUI    | Suite  |   Authentication  |     Key     |     Key     |
|          |  Type  |        Type       |  Management |  derivation |
|          |        |                   |     Type    |     type    |
+----------+--------+-------------------+-------------+-------------+
| 00-0F-AC |   18   |   Opportunistic   |     This    |  [RFC5869]  |
|          |        |      Wireless     |   document  |             |
|          |        |     Encryption    |             |             |
+----------+--------+-------------------+-------------+-------------+

                     Table 1: OWE AKM

Once a client discovers an OWE-compliant AP, it does "Open System" 802.11 authentication as defined in [IEEE802.11], and then moves on to 802.11 association 🥳.

Part 1 of 3 done, bestie 💖 Keep going, we're just getting started 🌟

4.3. OWE Association ✨

okay so 802.11 association requests and responses carry extra info in little TLV chunks that [IEEE802.11] calls "elements" 🎀. Each element has an "Element ID" (plus an Element ID extension, if it has one), a length, and a value field that's element specific 💅. You just stack the elements back to back to build an association request or response 🧚.

OWE adds the Diffie-Hellman Parameter element (see Figure 1) to 802.11 association requests and responses 💖. The client drops her public key into the association request, and the AP drops his public key into the association response 🫶.

   +------------+----------+------------+------------------------+
   | Element ID |  Length  | Element ID |   element-specific     |
   |            |          |  Extension |         data           |
   +------------+----------+------------+---------+--------------+
   |    255     | variable |     32     | group   |  public key  |
   +------------+----------+------------+---------+--------------+

           Figure 1: The Diffie-Hellman Parameter Element

where:

group is an unsigned two-octet integer defined in [IKE-IANA], in little-endian format, that identifies a domain parameter set;
public key is an octet string representing the Diffie-Hellman public key; and,
Element ID, Length, and Element ID Extension are all single-octet integers.

the way the public key gets encoded depends on what type it is 🌸. FFC elements SHALL be encoded per the integer-to-octet-string conversion technique of [RFC6090]. For ECC elements, the encoding depends on the definition of the curve, either the one in [RFC6090] or the one in [RFC7748]. If the public key is from a curve defined in [RFC6090], compact representation SHALL be used.

okay, the main rules for who sends what 👑: a client wishing to do OWE MUST indicate the OWE AKM in the RSN element portion of the 802.11 association request, and MUST include a Diffie-Hellman Parameter element in that same association request. An AP agreeing to do OWE MUST include the OWE AKM in the RSN element portion of the 802.11 association response. If "PMK caching" (see Section 4.5) is not performed, the AP MUST also include a Diffie-Hellman Parameter element. And if "PMK caching" is not being performed, a client MUST discard any 802.11 association response that indicates the OWE AKM in the RSN element but does not have not a Diffie-Hellman Parameter element 🙈.

for interoperability, a compliant implementation MUST support group nineteen (19), a 256-bit elliptic curve group 🦋. If the AP does not support the group indicated in the received 802.11 association request, it MUST respond with an 802.11 association response with a status code of seventy-seven (77), which means unsupported finite cyclic group 💀. A client that receives an 802.11 association response with a status code of seventy-seven SHOULD retry OWE with a different supported group. Due to the unsecured nature of 802.11 association, the client MAY request association again using the group that resulted in failure 🌈. This failure SHOULD be logged, and if the client abandons association because it couldn't agree on any group, notification of this fact SHOULD be provided to the user ✨.

received Diffie-Hellman Parameter elements get checked for validity as soon as they arrive 🔥. For ECC, the validity check depends on the curve definition, either the one in [RFC6090] or the one in [RFC7748]. For FFC, elements are checked to make sure they're between one (1) and one less than the prime, p, exclusive (i.e., 1 < element < p-1). Invalid received Diffie-Hellman keys MUST result in unsuccessful association, a failure of OWE, and a reset of the 802.11 state machine 😭. Due to the unsecured nature of 802.11 association, a client SHOULD retry OWE a number of times (this memo does not specify the number of times). This failure should be logged, and if the client abandons association due to the (repeated) receipt of invalid elements, notification of this fact should be provided to the user 🍓.

4.4. OWE Post-Association

once the client and AP have finished 802.11 association, they complete the Diffie-Hellman key exchange and create a Pairwise Master Key (PMK) and its associated identifier, PMKID [IEEE802.11] 🔑. Given a private key x and the peer's public key Y (the AP's if you're the client, the client's if you're the AP), the following get generated:

z = F(DH(x, Y))

prk = HKDF-extract(C | A | group, z)

PMK = HKDF-expand(prk, "OWE Key Generation", n)

where HKDF-expand() and HKDF-extract() are defined in [RFC5869]. "C | A | group" is a concatenation of the client's Diffie-Hellman public key, the AP's Diffie-Hellman public key (from the 802.11 association request and response, respectively), and the two-octet group from the Diffie-Hellman Parameter element (in little-endian format). It gets passed as the salt to the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) using the hash algorithm defined in Section 4.1 💜. And n is the bit length of the digest produced by that hash algorithm. z and prk SHOULD be irretrievably deleted once the PMK has been generated 🫧.

the PMKID is made by hashing the two Diffie-Hellman public keys (the data as sent and received, from the "public key" portion of the Diffie-Hellman Parameter element in the 802.11 association request and response), then keeping the leftmost 128 bits 🦋:

PMKID = Truncate-128(Hash(C | A))

where C is the client's Diffie-Hellman public key from the 802.11 association request, A is the AP's Diffie-Hellman public key from the 802.11 association response, and Hash is the hash algorithm defined in Section 4.1.

+---------+--------------+----------+-------+------------+----------+
|   Hash  |  Integrity   | KCK_bits |  Size |  Key-wrap  | KEK_bits |
|         |  Algorithm   |          |   of  | Algorithm  |          |
|         |              |          |  MIC  |            |          |
+---------+--------------+----------+-------+------------+----------+
| SHA-256 | HMAC-SHA-256 |   128    |   16  |  NIST AES  |   128    |
|         |              |          |       |  Key-wrap  |          |
| SHA-384 | HMAC-SHA-384 |   192    |   24  |  NIST AES  |   256    |
|         |              |          |       |  Key-wrap  |          |
| SHA-512 | HMAC-SHA-521 |   256    |   32  |  NIST AES  |   256    |
|         |              |          |       |  Key-wrap  |          |
+---------+--------------+----------+-------+------------+----------+

                Table 2: Integrity and Key Wrap Algorithms

upon completion of 802.11 association, the AP starts the 4-way handshake with the client using the PMK generated above 🤝. The 4-way handshake generates a Key-Encrypting Key (KEK), a Key-Confirmation Key (KCK), and a Message Integrity Code (MIC) to protect the frames that define the 4-way handshake. The algorithms and key lengths used in the 4-way handshake depend on the hash algorithm selected in Section 4.1 and are listed in Table 2 🌟.

the result of the 4-way handshake is the encryption keys that protect bulk unicast data and broadcast data 🔐. If the 4-way handshake fails, this information SHOULD be presented to the user 😬.

4.5. OWE PMK Caching

[IEEE802.11] defines "PMK caching," where a client and access point can cache a PMK for a certain period of time and reuse it with the 4-way handshake after later associations, skipping potentially expensive authentication 🧠. A client says it wants "PMK caching" by including the identifying PMKID in its 802.11 association request. If an AP has cached the PMK identified by that PMKID, it includes the PMKID in its 802.11 association response. Otherwise, it ignores the PMKID and carries on with normal 802.11 association. OWE supports the notion of "PMK caching" 💅.

since "PMK caching" is signalled in the same frame that carries the Diffie-Hellman Parameter element, a client wishing to do "PMK caching" MUST include both in her 802.11 association request 📦. If the AP has the PMK identified by the PMKID and wants to do "PMK caching," it includes the PMKID in its 802.11 association response but does not include a Diffie-Hellman Parameter element. If the AP does not have the PMK identified by the PMKID, it ignores the PMKID and carries on with normal OWE 802.11 association by including a Diffie-Hellman Parameter element 🎯.

when attempting "PMK caching," a client SHALL ignore any Diffie-Hellman Parameter element in an 802.11 association response whose PMKID matches that of the client-issued 802.11 association request. If the 802.11 association response does not include a PMKID, or if the PMKID does not match that of the client-issued 802.11 association request, the client SHALL proceed with normal OWE association 🌷.

The client SHALL ignore a PMKID in any 802.11 association response frame for which it did not include a PMKID in the corresponding 802.11 association request frame 🙅‍♀️.

5. IANA Considerations

This document does not require any IANA actions 🎀.

6. Implementation Considerations

OWE is a replacement for 802.11 "Open" authentication 🌈. So when OWE-compliant access points are discovered, the available SSID shown to users should not include special security symbols such as a "lock icon." To a user, an OWE SSID is the same as "Open." It just provides more security behind the scenes 🤫.

when OWE is first deployed as a replacement for an existing network that uses "Open" authentication or a shared and public PSK, an additional Basic Service Set Identifier (BSSID) or a new Extended Service Set (ESS) with a separate Service Set Identifier (SSID) is needed for OWE. That way two distinct 802.11 networks can exist on the same access point (see [IEEE802.11]) 🏠. This arrangement should remain until the majority of users have switched over to OWE 🦋.

7. Security Considerations

Opportunistic encryption does not provide authentication 🚨. The client has no authenticated identity for the access point, and vice versa. They share pairwise traffic encryption keys and get a cryptographic assurance that a frame claimed to be from the peer is actually from the peer and was not modified in flight. That's the good part 🔒. But it's not the whole story 😭.

OWE only secures data sent over the wireless medium. It does not provide security for end-to-end traffic. Users should still use application-level security to achieve security end-to-end 💖.

OWE is susceptible to an active attack in which an adversary impersonates an access point and induces a client to connect to it via OWE while it makes a connection to the legitimate access point. In this particular attack, the adversary is able to inspect, modify, and forge any data between the client and legitimate access point. Yikes, bestie 💀🚨.

OWE is not a replacement for any authentication protocol specified in [IEEE802.11], and it is not intended to be used when an alternative that provides real authentication is available 🛡️.

8. References ✨

8.1. Normative References ✨

okay bestie, these are the docs the spec basically can't function without, so they're the ones you HAVE to read 📚💅

[IEEE802.11]
           IEEE, "IEEE Standard for Information technology--
           Telecommunications and information exchange between
           systems Local and metropolitan area networks--Specific
           requirements - Part 11: Wireless LAN Medium Access Control
           (MAC) and Physical Layer (PHY) Specifications", IEEE Std
           802.11, DOI 10.1109/IEEESTD.2016.7786995.

[IKE-IANA] IANA, "Transform Type 4 - Diffie-Hellman Group Transform
           IDs", <http://www.iana.org/assignments/ikev2-parameters/>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
           Key Derivation Function (HKDF)", RFC 5869,
           DOI 10.17487/RFC5869, May 2010,
           <http://www.rfc-editor.org/info/rfc5869>.

[RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
           Curve Cryptography Algorithms", RFC 6090,
           DOI 10.17487/RFC6090, February 2011,
           <http://www.rfc-editor.org/info/rfc6090>.

[RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
           for Security", RFC 7748, DOI 10.17487/RFC7748, January
           2016, <http://www.rfc-editor.org/info/rfc7748>.

8.2. Informative References 🦋

these ones are more of a "good to know" vibe, super helpful for context but the spec doesn't lean on them the same way 🧚

[RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
           Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
           December 2014, <http://www.rfc-editor.org/info/rfc7435>.

Authors' Addresses 💖

and here are the lovely people who wrote it, with their contact info so you can slide into their inbox if you have questions 💌

Dan Harkins (editor)
HP Enterprise
3333 Scott Boulevard
Santa Clara, California  95054
United States of America

Phone: +1 415 555 1212
Email: dharkins@arubanetworks.com


Warren Kumari (editor)
Google
1600 Amphitheatre Parkway
Mountain View, California  94043
United States of America

Phone: +1 408 555 1212
Email: warren@kumari.net

📦 where this page comes from

ietf: rfc8110 2017-03
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms