Network Working Group D. Harkins, Ed. Internet-Draft HP Enterprise Intended status: Informational W. Kumari, Ed. Expires: February 24, 2017 Google August 23, 2016 Opportunistic Wireless Encryption draft-harkins-owe-03 Abstract This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media. [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on in Github at: https://github.com/wkumari/draft- harkins-owe. The authors (gratefully) accept pull requests. ] 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 http://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 February 24, 2017. Copyright Notice Copyright (c) 2016 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 Harkins & Kumari Expires February 24, 2017 [Page 1] Internet-Draft Opportunistic Wireless Encryption August 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 6 4.4. OWE Post-Association . . . . . . . . . . . . . . . . . . 8 4.5. OWE PMK Caching . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Implementation Considerations . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This memo describes a mode of opportunistic encryption [RFC7435] for 802.11 -- OWE -- 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. Harkins & Kumari Expires February 24, 2017 [Page 2] Internet-Draft Opportunistic Wireless Encryption August 2016 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 expontiation 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. 1.3. Why IETF? The protocol described here is an extension to the IEEE 802.11 standard and the question, naturally, arises: why do this in the IETF? As the name implies, OWE provides opportunistic encryption, or encryption of traffic without authentication of endpoints. OWE was presented to the IEEE 802.11 Working Group for consideration but an "all or nothing" approach to cryptographic protection has been adopted by that body, and OWE is a stop in between "all" and "nothing". Through documents such as [RFC7435] and [RFC5386] the IETF has been at the forefront of expanding the use of encryption in the Internet, even when authentication is not possible or practical. The IETF is a natural home for OWE. [ RFC Editor, please remove: This topic has been discussed within the IEEE IETF Coordination group (notes from meeting: https://www.ietf.org/mail-archive/web/ieee-ietf-coord/current/ msg00828.html), and within the IEEE. The IEEE has allocated codepoints for this technique, see: http://www.ieee802.org/11/email/ stds-802-11-editors/msg00209.html ] 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. [Ed note: The ietf-hotel SSID is an example of an open wifi network likely familiar to most readers. ] Harkins & Kumari Expires February 24, 2017 [Page 3] Internet-Draft Opportunistic Wireless Encryption August 2016 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 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 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. If the attacker is too late to observe this exchange, he can issue a forged "de-authenticate" 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. Basically, this shared and public PSK mode of access is as bad as an open and unencrypted network. [TODO: Explain trade offs; shared PSK means the attacker has to be active and could provide a false sense of security.] With OWE, the client and AP, would 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 -- there are no public keys to maintain, share, or manage. 3. 802.11 Network Access Wi-Fi Access Points advertise their presence through frames called "beacons". These frames inform clients within earshot of the SSID the AP is advertising, the AP's MAC address (known as its "BSSID"), security policy governing access, which 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 Harkins & Kumari Expires February 24, 2017 [Page 4] Internet-Draft Opportunistic Wireless Encryption August 2016 that respond with "probe responses". A probe response carries essentially the same information as a beacon. 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 (SAE being the exception), 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, 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 Expires February 24, 2017 [Page 5] Internet-Draft Opportunistic Wireless Encryption August 2016 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 identifier for OWE. This AKM is illustrated in Table 1 and is added to the RSN Element in all beacons and probe responses that the AP issues. OWE AKM +----------+--------+-------------------+-------------+-------------+ | OUI | Suite | Authentication | Key | Key | | | Type | Type | Management | derivation | | | | | Type | type | +----------+--------+-------------------+-------------+-------------+ | 00-0F-AC | ANA-1 | Opportunistic | This | [RFC5869] | | | | Wireless | document | | | | | Encryption | | | +----------+--------+-------------------+-------------+-------------+ Table 1: OWE AKM where ANA-1 is assigned by IEEE 802.11 ANA. Once a client discovers an OWE-compliant AP, it performs "Open System" 802.11 authentication as defined in [IEEE802.11], it then proceeds to 802.11 association. 4.3. OWE Association Information is added to 802.11 association requests and responses by 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 associate 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 associate request and the AP adds his public key in the 802.11 associate response. Harkins & Kumari Expires February 24, 2017 [Page 6] Internet-Draft Opportunistic Wireless Encryption August 2016 The Diffie-Hellman Parameter Element +------------+----------+------------+------------------------+ | Element ID | Length | ID | element-specific | | | | Extension | data | +------------+----------+------------+---------+--------------+ | 255 | variable | ANA-2 | group | public key | +------------+----------+------------+---------+--------------+ Figure 1 where o ANA-2 is assigned by IEEE 802.11 ANA; 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 encoded according to section 2.3.3 (Elliptic Curve to Octet String Conversion) or 2.3.5 (Field Element to Octet String Conversion) of [SEC1] depending on whether the public key is ECC or FFC, respectively; and, o Element ID, Length, and ID Extension are all single octet integers in little-endian format. 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 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. [ TODO: what to do if the AP doesn't like the client's chosen group? ] Received Diffie-Hellman Parameter Elements are checked for validity upon receipt. For ECC, elements are checked by verifying that equation for the curve is correct for the given x- and y- coordinates, excluding the point at infinity. 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 Harkins & Kumari Expires February 24, 2017 [Page 7] Internet-Draft Opportunistic Wireless Encryption August 2016 Diffie-Hellman keys MUST result in unsuccessful association and a failure of OWE. [ TODO: Add text on what to do next. ] 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. 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(NULL, z) PMK = HKDF-expand(prk, "OWE Key Generation", n) Where HKDF-expand() and HKDF-extract() are defined in [RFC5869], NULL indicates the "salt-less" invocation of HKDF using the hash algorithm defined in section Section 4.1, and n is the bit-length of the digest produced by that hash algorithm. z and prk are 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 left-most 128 bits: PMKID = Truncate-128(Hash(C | A)) where C is the client's Diffie-Hellman public key from the 802.11 Association request and A is the AP's Diffie-Hellman public key from the 802.11 Association response, and Hash is the hash algorithm defined in section Section 4.1. Upon completion of 802.11 association, the AP initiates the 4-way Handshake to the client using the PMK generated above. The result of the 4-way Handshake is encryption keys to protect bulk unicast data and broadcast data. 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 Harkins & Kumari Expires February 24, 2017 [Page 8] Internet-Draft Opportunistic Wireless Encryption August 2016 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 that 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 memo includes no request to IANA. 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. 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 is susceptible to an active attack in which an adversary impersonates an Access Point, induces a client to connect to it via Harkins & Kumari Expires February 24, 2017 [Page 9] Internet-Draft Opportunistic Wireless Encryption August 2016 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 Computer Society, "Telecommunications and information exchange between systems Local and metropolitan area networks--", Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications IEEE Std 802.11-2012, 2012. [IKE-IANA] IANA, "Internet Key Exchange (version 2) Parameters", Transform Type 4: Diffie-Hellman Group Transform IDs, 2005, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ RFC5869, May 2010, . [SEC1] Brown, D., "Elliptic Curve Cryptography", Version 2.0, 2009. 8.2. Informative References [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, DOI 10.17487/RFC5386, November 2008, . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . Harkins & Kumari Expires February 24, 2017 [Page 10] Internet-Draft Opportunistic Wireless Encryption August 2016 Appendix A. Changes / Author Notes. [ RFC Editor: Please remove this section befor publication ] -00: Initial version. -00 to -01: Editorial, title change. -01 to -02: Stressed the use of this as an alternative to "Open", not PSK. The PSK case is more interesting to discuss, but Open is more widely applicable. -02 to -03: Added "Why IETF?" Authors' Addresses Dan Harkins (editor) HP Enterprise 1322 Crossman avenue Sunnyvale, California 94089 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 Expires February 24, 2017 [Page 11]