idnits 2.17.1 draft-harkins-owe-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harkins, Ed. 3 Internet-Draft HP Enterprise 4 Intended status: Informational W. Kumari, Ed. 5 Expires: May 3, 2017 Google 6 October 30, 2016 8 Opportunistic Wireless Encryption 9 draft-harkins-owe-04 11 Abstract 13 This memo specifies an extension to IEEE Std 802.11 to provide for 14 opportunistic (unauthenticated) encryption to the wireless media. 16 [ Ed note: Text inside square brackets ([]) is additional background 17 information, answers to frequently asked questions, general musings, 18 etc. They will be removed before publication. This document is 19 being collaborated on in Github at: https://github.com/wkumari/draft- 20 harkins-owe. The authors (gratefully) accept pull requests. ] 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 58 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.3. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. 802.11 Network Access . . . . . . . . . . . . . . . . . . . . 4 62 4. Opportunistic Wireless Encryption . . . . . . . . . . . . . . 5 63 4.1. Cryptography . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. OWE Discovery . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. OWE Association . . . . . . . . . . . . . . . . . . . . . 6 66 4.4. OWE Post-Association . . . . . . . . . . . . . . . . . . 8 67 4.5. OWE PMK Caching . . . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 6. Implementation Considerations . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 This memo describes a mode of opportunistic encryption [RFC7435] for 80 802.11 -- OWE -- that provides encryption of the wireless medium but 81 no authentication. 83 1.1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 1.2. Notation 91 This memo uses the following notation: 93 y = F(X) an element-to-scalar mapping function. For an elliptic 94 curve group, it takes a point on the curve and returns the 95 x-coordinate; for a finite field element it is the identity 96 function, just returning the element itself. 98 Z = DH(x,Y) 99 for an elliptic curve DH(x,Y) is the multiplication of point Y by 100 the scalar value x creating a point on the curve Z; for finite 101 field cryptography DH(x,Y) is expontiation of element Y to the 102 power of x (implied modulo a field defining prime, p) resulting 103 in an element Z. 105 a = len(b) 106 indicates the length in bits of the string b. 108 1.3. Why IETF? 110 The protocol described here is an extension to the IEEE 802.11 111 standard and the question, naturally, arises: why do this in the 112 IETF? 114 As the name implies, OWE provides opportunistic encryption, or 115 encryption of traffic without authentication of endpoints. OWE was 116 presented to the IEEE 802.11 Working Group for consideration but an 117 "all or nothing" approach to cryptographic protection has been 118 adopted by that body, and OWE is a stop in between "all" and 119 "nothing". 121 Through documents such as [RFC7435] and [RFC5386] the IETF has been 122 at the forefront of expanding the use of encryption in the Internet, 123 even when authentication is not possible or practical. The IETF is a 124 natural home for OWE. 126 [ RFC Editor, please remove: This topic has been discussed within the 127 IEEE IETF Coordination group (notes from meeting: 128 https://www.ietf.org/mail-archive/web/ieee-ietf-coord/current/ 129 msg00828.html), and within the IEEE. The IEEE has allocated 130 codepoints for this technique, see: http://www.ieee802.org/11/email/ 131 stds-802-11-editors/msg00209.html ] 133 2. Background 135 Internet access has become an expected service at many locations - 136 for example, coffee shops, airports and hotels. In many cases, this 137 is offered over "Open" (unencrypted) wireless networks, because 138 distributing a passphrase (or using other authentication solutions) 139 is not convenient or realistic. Ideally, users would always use a 140 VPN when using an untrusted network, but often they don't. This 141 leaves their traffic vulnerable to sniffing attacks, for example from 142 someone in the adjacent hotel room running Wireshark, pervasive 143 monitors, etc. [Ed note: The ietf-hotel SSID is an example of an 144 open wifi network likely familiar to most readers. ] 145 In addition, many businesses (for example, coffee shops and bars) 146 offer free Wi-Fi as an inducement to customers to enter and remain in 147 the premises. Many customers will use the availability of free Wi-Fi 148 as a deciding factor in which business to patronize. Since these 149 businesses are not Internet service providers, they are often 150 unwilling and/or unqualified to perform complex configuration on 151 their network. In addition, customers are generally unwilling to do 152 complicated provisioning on their devices just to obtain free Wi-Fi. 153 This leads to a popular deployment technique -- a network protected 154 using a shared and public PSK that is printed on a sandwich board at 155 the entrance, on a chalkboard on the wall, or on a menu. The PSK is 156 used in a cryptographic handshake defined in [IEEE802.11] called the 157 "4-way handshake" to prove knowledge of the PSK and derive traffic 158 encryption keys for bulk wireless data. 160 The belief is that this protects the wireless medium from passive 161 sniffing and simple attacks. That belief is erroneous. Since the 162 PSK is known by everyone, it is possible for a passive attacker to 163 observe the 4-way Handshake and compute the traffic encryption keys 164 used by a client and access point. If the attacker is too late to 165 observe this exchange, he can issue a forged "de-authenticate" frame 166 that will cause the client and/or AP to reset the 802.11 state 167 machine and cause them to go through the 4-way Handshake again 168 thereby allowing the passive attacker to determine the traffic keys. 169 Basically, this shared and public PSK mode of access is as bad as an 170 open and unencrypted network; some would say worse, as it provides 171 users with a false sense of security. 173 With OWE, the client and AP, would perform a Diffie-Hellman key 174 exchange during the access procedure and use the resulting pairwise 175 secret with the 4-way Handshake, instead of using a shared and public 176 PSK in the 4-way Handshake. 178 OWE requires no special configuration or user interaction but 179 provides a higher level of security than a common, shared, and public 180 PSK. OWE not only provides more security to the end user, it is also 181 easier to use both for the provider and the end user -- there are no 182 public keys to maintain, share, or manage. 184 3. 802.11 Network Access 186 Wi-Fi Access Points advertise their presence through frames called 187 "beacons". These frames inform clients within earshot of the SSID 188 the AP is advertising, the AP's MAC address (known as its "BSSID"), 189 security policy governing access, which symmetric ciphers it uses for 190 unicast and broadcast frames, QoS information, as well as support for 191 other optional features of [IEEE802.11]. Wi-Fi clients can actively 192 discover APs by issuing "probe requests" which are queries for APs 193 that respond with "probe responses". A probe response carries 194 essentially the same information as a beacon. 196 After an AP is discovered by a client, actively through probing or 197 passively through beacons, the client initiates a two-step method to 198 gain network access. The first step is "802.11 authentication". For 199 most methods of access (SAE being the exception), this is an empty 200 exchange known as "Open Authentication-- basically the client says, 201 "authenticate me", and the AP responds "ok, you're authenticated". 202 After 802.11 authentication is 802.11 association, in which the 203 client requests network access from an AP-- the SSID, a selection of 204 the type of subsequent authentication to be made, any pairwise and 205 group ciphers, etc-- using an 802.11 association request. The AP 206 acknowledges the request with an 802.11 association response. 208 If the network is Open-- no authentication, no encryption-- the 209 client has network access immediately after completion of 802.11 210 association. If the network enforces PSK authentication, the 4-way 211 Handshake is initiated by the AP using the PSK to authenticate the 212 client and derive traffic encryption keys. 214 To add an opportunistic encryption mode of access to [IEEE802.11], it 215 is necessary to perform a Diffie-Hellman key exchange during 802.11 216 authentication and use the resulting pairwise secret with the 4-way 217 Handshake. 219 4. Opportunistic Wireless Encryption 221 4.1. Cryptography 223 Performing a Diffie-Hellman key exchange requires agreement on a 224 domain parameter set in which to perform the exchange. OWE uses a 225 registry (see [IKE-IANA]) to map an integer into a complete domain 226 parameter set. OWE supports both elliptic curve cryptography (ECC) 227 and finite field cryptography (FFC). 229 OWE uses a hash algorithm for generation of a secret and a secret 230 identifier. The particular hash algorithm depends on the group 231 chosen for the Diffie-Hellman. For ECC, the hash algorithm depends 232 on the size of the prime defining the curve, p: 234 o SHA-256: when len(p) <= 256 236 o SHA-384: when 256 < len(p) <= 384 238 o SHA-512: when 384 < len(p) 239 For FFC, the hash algorithm depends on the prime, p, defining the 240 finite field: 242 o SHA-256: when len(p) <= 2048 244 o SHA-384: when 2048 < len(p) <= 3072 246 o SHA-512: when 3072 < len(p) 248 4.2. OWE Discovery 250 An access point advertises support for OWE using an Authentication 251 and Key Management (AKM) suite identifier for OWE. This AKM is 252 illustrated in Table 1 and is added to the RSN Element in all beacons 253 and probe responses that the AP issues. 255 OWE AKM 257 +----------+--------+-------------------+-------------+-------------+ 258 | OUI | Suite | Authentication | Key | Key | 259 | | Type | Type | Management | derivation | 260 | | | | Type | type | 261 +----------+--------+-------------------+-------------+-------------+ 262 | 00-0F-AC | 18 | Opportunistic | This | [RFC5869] | 263 | | | Wireless | document | | 264 | | | Encryption | | | 265 +----------+--------+-------------------+-------------+-------------+ 267 Table 1: OWE AKM 269 Once a client discovers an OWE-compliant AP, it performs "Open 270 System" 802.11 authentication as defined in [IEEE802.11], it then 271 proceeds to 802.11 association. 273 4.3. OWE Association 275 Information is added to 802.11 association requests and responses by 276 using TLVs that [IEEE802.11] calls "elements". Each element has an 277 "Element ID" (including any Element ID extension), a length, and a 278 value field that is element-specific. These elements are appended to 279 each other to construct 802.11 associate requests and responses. 281 OWE adds the Diffie-Hellman Parameter element (see Figure 1) to 282 802.11 association requests and responses. The client adds her 283 public key in the 802.11 associate request and the AP adds his public 284 key in the 802.11 associate response. 286 The Diffie-Hellman Parameter Element 288 +------------+----------+------------+------------------------+ 289 | Element ID | Length | ID | element-specific | 290 | | | Extension | data | 291 +------------+----------+------------+---------+--------------+ 292 | 255 | variable | 32 | group | public key | 293 +------------+----------+------------+---------+--------------+ 295 Figure 1 297 where 299 o group is an unsigned two-octet integer defined in [IKE-IANA], in 300 little-endian format, that identifies a domain parameter set; 302 o public key is an octet string representing the Diffie-Hellman 303 public key encoded according to section 2.3.3 (Elliptic Curve to 304 Octet String Conversion) or 2.3.5 (Field Element to Octet String 305 Conversion) of [SEC1] depending on whether the public key is ECC 306 or FFC, respectively; and, 308 o Element ID, Length, and ID Extension are all single octet integers 309 in little-endian format. 311 A client wishing to do OWE MUST indicate the OWE AKM in the RSN 312 element portion of the 802.11 association request, and MUST include a 313 Diffie-Hellman Parameter element to its 802.11 association request. 314 An AP agreeing to do OWE MUST include the OWE AKM in the RSN element 315 portion of the 802.11 association response. If "PMK caching" (see 316 Section 4.5) is not performed, it MUST also include a Diffie-Hellman 317 Parameter element. If "PMK caching" is not being performed, a client 318 MUST discard any 802.11 association response that indicates the OWE 319 AKM in the RSN element but does not have not a Diffie-Hellman 320 Parameter element. 322 For interoperability purposes, a compliant implementation MUST 323 support group nineteen (19), a 256-bit elliptic curve group. If the 324 AP does not support the group indicated in the received 802.11 325 association request it MUST respond with an 802.11 association 326 response with a status code of seventy-seven (77) indicating an 327 unsupported finite cyclic group. A client that receives an 802.11 328 association response with a status code of seventy-seven SHOULD retry 329 OWE with a different supported group and, due to the unsecured nature 330 of 802.11 association, MAY request association again using the group 331 which resulted in failure. This failure SHOULD be logged and if the 332 client abandons association due to the failure to agree on any group, 333 notification of this fact SHOULD be provided to the user. 335 Received Diffie-Hellman Parameter Elements are checked for validity 336 upon receipt. For ECC, elements are checked by verifying that 337 equation for the curve is correct for the given x- and y- 338 coordinates, excluding the point at infinity. For FFC, elements are 339 checked that they are between one (1) and one (1) less than the 340 prime, p, exclusive (i.e. 1 < element < p-1). Invalid received 341 Diffie-Hellman keys MUST result in unsuccessful association, a 342 failure of OWE, and resetting of the 802.11 state machine. Due to 343 the unsecured nature of 802.11 association a client SHOULD retry OWE 344 a number of times (which this memo does not specify). This failure 345 SHOULD be logged and if the client abandons association due to the 346 (repeated) receipt of invalid elements, notification of this fact 347 SHOULD be provided to the user. 349 4.4. OWE Post-Association 351 Once the client and AP have finished 802.11 association, they then 352 complete the Diffie-Hellman key exchange and create a "pairwise 353 master key" (PMK), and its associated identifier, PMKID. Given a 354 private key x, and the peer's (AP's if client, client's if AP) public 355 key Y the following are generated: 357 z = F(DH(x, Y)) 359 prk = HKDF-extract(NULL, z) 361 PMK = HKDF-expand(prk, "OWE Key Generation", n) 363 Where HKDF-expand() and HKDF-extract() are defined in [RFC5869], NULL 364 indicates the "salt-less" invocation of HKDF using the hash algorithm 365 defined in section Section 4.1, and n is the bit-length of the digest 366 produced by that hash algorithm. z and prk are irretrievably deleted 367 once the PMK has been generated. 369 The PMKID is generated by hashing the two Diffie-Hellman public keys 370 (the data, as sent and received, from the "public key" portion of the 371 Diffie-Hellman Parameter element in the 802.11 Association request 372 and response) and returning the left-most 128 bits: 374 PMKID = Truncate-128(Hash(C | A)) 376 where C is the client's Diffie-Hellman public key from the 802.11 377 Association request and A is the AP's Diffie-Hellman public key from 378 the 802.11 Association response, and Hash is the hash algorithm 379 defined in section Section 4.1. 381 Upon completion of 802.11 association, the AP initiates the 4-way 382 Handshake to the client using the PMK generated above. The result of 383 the 4-way Handshake is encryption keys to protect bulk unicast data 384 and broadcast data. 386 4.5. OWE PMK Caching 388 [IEEE802.11] defines "PMK caching" where a client and access point 389 can cache a PMK for a certain period of time and reuse it with the 390 4-way Handshake after subsequent associations to bypass potentially 391 expensive authentication. A client indicates its desire to do "PMK 392 caching" by including the identifying PMKID in its 802.11 association 393 request. If an AP has cached the PMK identified by that PMKID, it 394 includes the PMKID in its 802.11 association response, otherwise it 395 ignores the PMKID and proceeds with normal 802.11 association. OWE 396 supports the notion of "PMK caching". 398 Since "PMK caching" is indicated in the same frame as the Diffie- 399 Hellman Parameter element is passed, a client wishing to do "PMK 400 caching" MUST include both in her 802.11 association request. If the 401 AP has the PMK identified by the PMKID and wishes to perform "PMK 402 caching", he will include the PMKID in his 802.11 association 403 response but does not include a Diffie-Hellman parameter element. If 404 the AP does not have the PMK identified by the PMKID, it ignores the 405 PMKID and proceeds with normal OWE 802.11 association by including a 406 Diffie-Hellman Parameter element. 408 When attempting "PMK caching" a client SHALL ignore any Diffie- 409 Hellman Parameter element in an 802.11 association response that 410 whose PMKID matches that of the client-issued 802.11 association 411 request. If the 802.11 association response does not include a 412 PMKID, or if the PMKID does not match that of the client-issued 413 802.11 association request, the client SHALL proceed with normal OWE 414 association. 416 The client SHALL ignore a PMKID in any 802.11 association response 417 frame for which it did not include a PMKID in the corresponding 418 802.11 association request frame. 420 5. IANA Considerations 422 This memo includes no request to IANA. 424 6. Implementation Considerations 426 OWE is a replacement for 802.11 "Open" authentication. Therefore, 427 when OWE-compliant access points are discovered, the presentation of 428 the available SSID to users should not include special security 429 symbols such as a "lock icon". To a user, an OWE SSID is the same as 430 "Open", it simply provides more security behind the scenes. 432 7. Security Considerations 434 Opportunistic encryption does not provide authentication. The client 435 will have no authenticated identity for the Access Point, and vice 436 versa. They will share pairwise traffic encryption keys and have a 437 cryptographic assurance that a frame claimed to be from the peer is 438 actually from the peer and was not modified in flight. 440 OWE is susceptible to an active attack in which an adversary 441 impersonates an Access Point, induces a client to connect to it via 442 OWE while it makes a connection to the legitimate Access Point. In 443 this particular attack, the adversary is able to inspect, modify, and 444 forge any data between the client and legitimate Access Point. 446 OWE is not a replacement for any authentication protocol specified in 447 [IEEE802.11] and is not intended to be used when an alternative that 448 provides real authentication is available. 450 8. References 452 8.1. Normative References 454 [IEEE802.11] 455 IEEE Computer Society, "Telecommunications and information 456 exchange between systems Local and metropolitan area 457 networks--", Part 11: Wireless LAN Medium Access Control 458 (MAC) and Physical Layer (PHY) Specifications IEEE Std 459 802.11-2012, 2012. 461 [IKE-IANA] 462 IANA, "Internet Key Exchange (version 2) Parameters", 463 Transform Type 4: Diffie-Hellman Group Transform IDs, 464 2005, . 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 471 Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ 472 RFC5869, May 2010, 473 . 475 [SEC1] Brown, D., "Elliptic Curve Cryptography", Version 2.0, 476 2009. 478 8.2. Informative References 480 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 481 Security: An Unauthenticated Mode of IPsec", RFC 5386, DOI 482 10.17487/RFC5386, November 2008, 483 . 485 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 486 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 487 December 2014, . 489 Appendix A. Changes / Author Notes. 491 [ RFC Editor: Please remove this section befor publication ] 493 -00: 495 Initial version. 497 -00 to -01: 499 Editorial, title change. 501 -01 to -02: 503 Stressed the use of this as an alternative to "Open", not PSK. 504 The PSK case is more interesting to discuss, but Open is more 505 widely applicable. 507 -02 to -03: 509 Added "Why IETF?" 511 -03 to -04: 513 Closed the "False sense of security" TODO - it was already done 514 (above). 516 Filled in the ANA-1 and ANA-2 placeholders with the actual values. 518 Closed the "failure to agree on group" TODO. 520 Closed the "what to do if invalid elements are received" TODO. 522 Authors' Addresses 524 Dan Harkins (editor) 525 HP Enterprise 526 1322 Crossman avenue 527 Sunnyvale, California 94089 528 United States of America 530 Phone: +1 415 555 1212 531 Email: dharkins@arubanetworks.com 533 Warren Kumari (editor) 534 Google 535 1600 Amphitheatre Parkway 536 Mountain View, California 94043 537 United States of America 539 Phone: +1 408 555 1212 540 Email: warren@kumari.net