From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8110.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc8110.txt (limited to 'doc/rfc/rfc8110.txt') diff --git a/doc/rfc/rfc8110.txt b/doc/rfc/rfc8110.txt new file mode 100644 index 0000000..43e9806 --- /dev/null +++ b/doc/rfc/rfc8110.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Harkins, Ed. +Request for Comments: 8110 HP Enterprise +Category: Informational W. Kumari, Ed. +ISSN: 2070-1721 Google + March 2017 + + + Opportunistic Wireless Encryption + +Abstract + + This memo specifies an extension to IEEE Std 802.11 to provide for + opportunistic (unauthenticated) encryption to the wireless media. + +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. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8110. + +Copyright Notice + + Copyright (c) 2017 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 + (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. + + + + + + + +Harkins & Kumari Informational [Page 1] + +RFC 8110 Opportunistic Wireless Encryption March 2017 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Harkins & Kumari Informational [Page 2] + +RFC 8110 Opportunistic Wireless Encryption March 2017 + + +1. Introduction + + This memo describes Opportunistic Wireless Encryption (OWE) -- a mode + of opportunistic security [RFC7435] for IEEE Std 802.11 that provides + encryption of the wireless medium but no authentication. + +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 + + Internet access has become an expected service at many locations -- + for example, coffee shops, airports, and hotels. In many cases, this + is offered over "Open" (unencrypted) wireless networks, because + distributing a passphrase (or using other authentication solutions) + is not convenient or realistic. Ideally, users would always use a + VPN when using an untrusted network, but often they don't. This + leaves their traffic vulnerable to sniffing attacks, for example, + from someone in the adjacent hotel room running Wireshark, pervasive + monitors, etc. + + In addition, many businesses (for example, coffee shops and bars) + offer free Wi-Fi as an inducement to customers to enter and remain in + the premises. Many customers will use the availability of free Wi-Fi + as a deciding factor in which business to patronize. Since these + + + +Harkins & Kumari Informational [Page 3] + +RFC 8110 Opportunistic Wireless Encryption March 2017 + + + businesses are not Internet service providers, they are often + unwilling and/or unqualified to perform complex configuration on + their network. In addition, customers are generally unwilling to do + complicated provisioning on their devices just to obtain free Wi-Fi. + This leads to a popular deployment technique -- a network protected + using a shared and public Pre-Shared Key (PSK) that is printed on a + sandwich board at the entrance, on a chalkboard on the wall, or on a + menu. The PSK is used in a cryptographic handshake, defined in + [IEEE802.11], called the "4-way handshake" to prove knowledge of 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, it is possible for a passive attacker to + 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 observe this exchange, he can issue a forged "deauthenticate" + frame that will cause the client and/or AP to reset the 802.11 state + machine and cause them to go through the 4-way handshake again, + thereby allowing the passive attacker to determine the traffic keys. + + With OWE, the client and AP perform a Diffie-Hellman key exchange + during the access procedure and use the resulting pairwise secret + with the 4-way handshake instead of using a shared and public PSK in + the 4-way handshake. + + OWE requires no special configuration or user interaction but + provides a higher level of security than a common, shared, and public + PSK. OWE not only provides more security to the end user, it is also + easier to use both for 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 their presence through frames + called "beacons". These frames inform clients within earshot of 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)), security policy governing access, the symmetric ciphers + it uses for unicast and broadcast frames, QoS information, as well as + support for other optional features of [IEEE802.11]. Wi-Fi clients + can actively discover APs by issuing "probe requests", which are + queries for APs that respond with "probe responses". A probe + response carries essentially the same information as a beacon. + + + + + + + +Harkins & Kumari Informational [Page 4] + +RFC 8110 Opportunistic Wireless Encryption March 2017 + + + After an AP is discovered by a client, actively through probing or + passively through beacons, the client initiates a two-step method to + gain network access. The first step is "802.11 authentication". For + most methods of access, this is an empty exchange known as "Open + Authentication" -- basically, the client says, "authenticate me", and + the AP responds, "ok, you're authenticated". 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", . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + + + +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, + . + + [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic + Curve Cryptography Algorithms", RFC 6090, + DOI 10.17487/RFC6090, February 2011, + . + + [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves + for Security", RFC 7748, DOI 10.17487/RFC7748, January + 2016, . + +8.2. Informative References + + [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection + Most of the Time", RFC 7435, DOI 10.17487/RFC7435, + December 2014, . + +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] + -- cgit v1.2.3