Opportunistic Wireless Encryption
RFC 8110
Document | Type |
RFC
- Informational
(March 2017)
Errata
Was
draft-harkins-owe
(individual in sec area)
|
|
---|---|---|---|
Authors | Dan Harkins , Warren "Ace" Kumari | ||
Last updated | 2020-01-21 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
IESG | Responsible AD | Stephen Farrell | |
Send notices to | (None) |
RFC 8110
quot;. After 802.11 authentication is 802.11 association, in which the client requests network access from an AP (the SSID, a selection of the type of subsequent authentication to be made, any pairwise and group ciphers, etc.) using an 802.11 association request. The AP acknowledges the request with an 802.11 association response. If the network is Open (no authentication and no encryption), the client has network access immediately after completion of 802.11 association. If the network enforces PSK authentication, the 4-way handshake is initiated by the AP 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 Performing a Diffie-Hellman key exchange requires agreement on a domain parameter set in which to perform the exchange. 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 for generation of a secret and a secret identifier. The particular hash algorithm depends on the group chosen for the Diffie-Hellman. For ECC, the hash algorithm depends on the size of the prime defining the curve p: o SHA-256: when len(p) <= 256 o SHA-384: when 256 < len(p) <= 384 o SHA-512: when 384 < len(p) Harkins & Kumari Informational [Page 5] RFC 8110 Opportunistic Wireless Encryption March 2017 For FFC, the hash algorithm depends on the prime, p, defining the finite field: o SHA-256: when len(p) <= 2048 o SHA-384: when 2048 < len(p) <= 3072 o SHA-512: when 3072 < len(p) 4.2. OWE Discovery An access point advertises support for OWE using an Authentication and Key Management (AKM) suite selector for OWE. This AKM is illustrated in Table 1 and is added to the Robust Security Network (RSN) element, defined in [IEEE802.11], in all beacons and probe response frames the AP issues. +----------+--------+-------------------+-------------+-------------+ | 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 performs "Open System" 802.11 authentication as defined in [IEEE802.11], and it then proceeds to 802.11 association. Harkins & Kumari Informational [Page 6] RFC 8110 Opportunistic Wireless Encryption March 2017 4.3. OWE Association Information is added to 802.11 association requests and responses using TLVs that [IEEE802.11] calls "elements". Each element has an "Element ID" (including any Element ID extension), a length, and a value field that is element specific. These elements are appended to each other to construct 802.11 association requests and responses. OWE adds the Diffie-Hellman Parameter element (see Figure 1) to 802.11 association requests and responses. The client adds her public key in the 802.11 association request, and the AP adds his public key in the 802.11 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: o group is an unsigned two-octet integer defined in [IKE-IANA], in little-endian format, that identifies a domain parameter set; o public key is an octet string representing the Diffie-Hellman public key; and, o Element ID, Length, and Element ID Extension are all single-octet integers. The encoding of the public key depends on its type. 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 that in [RFC6090] or [RFC7748]. If the public key is from a curve defined in [RFC6090], compact representation SHALL be used. 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 to its 802.11 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, it MUST also include a Diffie-Hellman Parameter element. If "PMK caching" is not being performed, a client MUST discard any 802.11 association response that indicates the OWE Harkins & Kumari Informational [Page 7] RFC 8110 Opportunistic Wireless Encryption March 2017 AKM in the RSN element but does not have not a Diffie-Hellman Parameter element. For interoperability purposes, 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) indicating an 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 and, due to the unsecured nature of 802.11 association, MAY request association again using the group that resulted in failure. This failure SHOULD be logged, and if the client abandons association due to the failure to agree on any group, notification of this fact SHOULD be provided to the user. Received Diffie-Hellman Parameter elements are checked for validity upon receipt. For ECC, a validity check depends on the curve definition, either that in [RFC6090] or [RFC7748]. For FFC, elements are checked that they are between one (1) and one (1) 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 then 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 (AP's if client, client's if AP) public key Y, the following are 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) and is Harkins & Kumari Informational [Page 8] RFC 8110 Opportunistic Wireless Encryption March 2017 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 generated 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) and returning 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 initiates the 4-way handshake to 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 use for protection of 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 encryption keys to protect bulk unicast data and broadcast data. If the 4-way handshake fails, this information SHOULD be presented to the user. Harkins & Kumari Informational [Page 9] RFC 8110 Opportunistic Wireless Encryption March 2017 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 subsequent associations to bypass potentially expensive authentication. A client indicates its desire to do "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 proceeds with normal 802.11 association. OWE supports the notion of "PMK caching". Since "PMK caching" is indicated in the same frame as the Diffie- Hellman Parameter element is passed, 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 wishes to perform "PMK caching", he will include the PMKID in his 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 proceeds 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. Therefore, when OWE-compliant access points are discovered, the presentation of the available SSID 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 simply provides more security behind the scenes. When OWE is initially deployed as a replacement for an existing network that uses "Open" authentication or a shared and public PSK, it will be necessary to create an additional Basic Service Set Harkins & Kumari Informational [Page 10] RFC 8110 Opportunistic Wireless Encryption March 2017 Identifier (BSSID) or a new Extended Service Set (ESS) with a separate Service Set Identifier (SSID) for OWE so 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 will have no authenticated identity for the access point, and vice versa. They will share pairwise traffic encryption keys and have a cryptographic assurance that a frame claimed to be from the peer is actually from the peer and was not modified in flight. OWE only secures data sent over the wireless medium and 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. 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. 8. References 8.1. Normative References [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>. Harkins & Kumari Informational [Page 11] RFC 8110 Opportunistic Wireless Encryption March 2017 [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 [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 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 Harkins & Kumari Informational [Page 12]