idnits 2.17.1 draft-wkumari-owe-02.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2016) is 2985 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Intended status: Informational W. George 5 Expires: August 24, 2016 Time Warner Cable 6 February 21, 2016 8 OWE: Opportunistic Wireless Encryption 9 draft-wkumari-owe-02 11 Abstract 13 This document describes a method to incrementally increase the 14 security of wireless networks against passive attackers / pervasive 15 monitors through unauthenticated encryption. 17 [ Ed note: Text inside square brackets ([]) is additional background 18 information, answers to frequently asked questions, general musings, 19 etc. They will be removed before publication.] 21 [ This document is being collaborated on in Github at: 22 https://github.com/wkumari/draft-wkumari-owe. The most recent 23 version of the document, open issues, etc should all be available 24 here. The authors (gratefully) accept pull requests. ] 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 24, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. tl;dr / Executive summary . . . . . . . . . . . . . . . . . . 2 61 1.1. FAQ / Common questions / Notes . . . . . . . . . . . . . 3 62 2. Introduction / Background . . . . . . . . . . . . . . . . . . 4 63 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 64 3. OWE protected networks . . . . . . . . . . . . . . . . . . . 5 65 3.1. OWE Support Advertisement in Beacons . . . . . . . . . . 5 66 3.2. OWE Advertisement in Access Network Query Protocol (ANQP) 6 67 4. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Advertising OWE support on legacy devices . . . . . . . . 7 69 5. Implementation notes . . . . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 10.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. tl;dr / Executive summary 82 This (colloquial) summary will be removed before publication: 84 Currently, there are many open/unencrypted public WiFi networks, 85 designed for "ease of use" in places such as coffee shops, libraries, 86 etc. When a user connects to these open networks, they are using an 87 unencrypted connection and their traffic can be easily viewed and/or 88 intercepted by any other user within wireless range, simply by using 89 a network sniffing tool such as Wireshark. 91 While users *should* use a VPN, many do not. Places that provide 92 public WiFi access *should* only provide an encrypted SSID, and print 93 the passphrase on the wall or receipts (or similar); but, well, they 94 are a coffee shop, and want to provide easy access to everyone who 95 buys an espresso... 97 This document defines a new, opportunistically encrypted mode for 98 WiFi networks. The SSID will still appear to be open (there will not 99 be a "lock" icon when scanning), but will actually be encrypted, 100 using the SSID as the passphrase. Software running on the client 101 will detect that this is an opportunistically encrypted connection 102 and will automagically provide the SSID as the passphrase, providing 103 an encrypted connection without any interaction from the user. This 104 system leverages existing WiFi protocols and WPA2, the only change is 105 in operational practices and the client UI. 107 1.1. FAQ / Common questions / Notes 109 Q1: If everyone uses the SSID as the key, can't attackers just use 110 this to decrypt all the data? 111 A: WPA2 using PSK generates a unique Pairwise Transient Key (PTK) 112 between the AP and each client. This PTK is derived using something 113 called the 4-Way Handshake ( see IEEE 802.11-2012 (or the summary at 114 https://en.wikipedia.org/wiki/IEEE_802.11i-2004#The_four- 115 way_handshake )), which includes nonces from both the client and the 116 AP. Unfortunately, this doesn't use a public key exchange protocol, 117 and so an attacker who can watch the initial client association can 118 derive the user's encryption key. This is a weakness in WPA2-PSK, 119 and not specific to OWE. 121 Q2: So does this actually help? 122 A: Yes. This provides protection if the passive attacker wasn't 123 already present when the user connected, or if the passive attacker 124 was not able to hear both sides of the connection. OWE does not 125 provide very strong protection, and does not claim to. It does, 126 however, raise the bar for the attacker, or force him to become 127 active (and force users to disassociate (so he can watch the 4 way 128 handshake)). OWE specifically does NOT provide the "lock" icon (or 129 any other obvious feedback) when users scan for open wireless 130 networks, because we do not want users to assume that they are 131 getting "real" encryption. OWE will become more secure if and when 132 WiFi with a public key exchange (such as Diffie-Hellman) is deployed. 133 The incremental cost to implement OWE is very small (it involves 134 adding a flag to beacons, and clients to know to not display the lock 135 icon) and so we feel that the benefit outweighs the cost. 137 Q3: Isn't this vulnerable to the fake AP attack?! 138 A: Yes. An attacker can stand up their own AP with the same SSID and 139 passphrase. This is true for any network that uses WPA2-PSK when the 140 attacker knows the passphrase (for example, if the coffee shop prints 141 the passphrase on the wall, receipts, etc) and it not specific to 142 OWE. OWE is not designed to defeat active attackers, nor solve all 143 issues. See Q2. 145 Q4: This isn't really opportunistic encryption... 146 A: Perhaps not, but it is has many of the same properties - it is 147 unauthenticated, is mainly designed to deal with passive listeners, 148 doesn't require interaction from the user, etc. I also wanted to 149 have a cool acronym - actually I wanted it to be OWL, but was not 150 able to reverse engineer a non-contrived name that made that... 152 Q5: Doesn't this belong in [ IEEE | WiFi Alliance | ] ? 154 A: Answer unclear, ask again later. I have discussed this with a 155 number of people who participate in other SDOs, and it seems like the 156 IETF is the best home for it, at least for now. It does not require 157 changes to any underlying transport, it does not change any 158 standards, it simply takes advantage of work done in other standards 159 bodies. 161 2. Introduction / Background 163 As of the time of this writing, it is very common for users to 164 connect to so called "open" wireless networks, for example in coffee 165 shops, hotels, airports and similar. These networks provide no 166 encryption, which means that the user's traffic is visible to anyone 167 nearby with packet capture software, for example, Wireshark. It is 168 also trivial for an attacker to perform a Man-in-the-Middle attacks 169 as they can see all of the user's traffic. 171 There are a number of solutions to this problem, such as WPA2 (Wi-Fi 172 Protected Access II), but these require either obtaining a passphrase 173 from the network operator (WPA-Personal / Pre-Shared Key (PSK) mode) 174 or having valid credentials for the network (WPA-Enterprise / 175 [IEEE.802-11i]WPA-802.1X). 177 While these provide good security, for convenience reasons network 178 operators often deploy open / unencrypted networks for public or 179 "guest" use. This allows the public or visitors to get Internet 180 access without having to ask for a passphrase, look around for one 181 printed on a receipt or similar. Instead of chastising network 182 operators for providing insecure access, this document provides a 183 method to implement unauthenticated, encrypted network access. 185 This is not intended to replace other existing and more robust 186 methods of authentication that provide encrypted access to a WiFi 187 network once the user is authenticated and authorized to join the 188 network, e.g. WPA-Enterprise / IEEE 802.1x or Hotspot 2.0. Rather, 189 this is intended for low-end, unmanaged guest access networks such as 190 SOHO networks that would otherwise either be left unencrypted, or 191 whose password would be shared via other means such as posting it on 192 the wall of the coffee shop. 194 2.1. Requirements notation 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 3. OWE protected networks 202 In order to provide an encrypted connection using OWE, the network 203 operator creates an SSID with the (WPA2 / 802.11i [IEEE.802-11i]) 204 pre-shared key identical to the SSID. As part of the WPA2 protocol 205 the wireless client (STAtion) and Access Point (AP) derive a Pairwise 206 Transient Key (PTK), which provides an encrypted "channel" between 207 the client and AP. 209 3.1. OWE Support Advertisement in Beacons 211 In order to advertise that this network supports OWE the Access Point 212 will include the OWE Vendor-specific Information Element in Wireless 213 Beacon frames. 215 0 1 2 3 216 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | VSA (221) | Length (5) | OUI 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 OUI (Cont) | Type | Sub-type | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 VSA One octet. The IEEE Assigned Vendor-Specific Information 224 element ID - 221. 226 Length One octet. The length of the information field, including 227 the OUI - 5. 229 OUI Three octets. The OUI for the of the entity that has defined 230 the content of the particular vendor-specific information element 231 - 64-6A-74 (AUTH-SERVERS). [ If approved, this may move under the 232 IANA OUI if desired] 234 Type One octet. OWE has been assigned Type 1 under the AUTH-SERVERS 235 OUI 237 Sub-type One octet. Sub-type identifies the version of the OWE 238 protocol. Currently only 0 is defined. 240 An Access Point that includes the OWE Vendor-specific Information 241 Element in beacon frames is signalling that is supports OWE on that 242 particular SSID, and that they PSK is the same as the SSID. Client 243 (STAtions) connecting to OWE enabled networks MUST use the SSID as 244 the PSK, and MUST NOT display a "lock" icon in the list of SSIDs when 245 scanning. User Interfaces MAY provide some feedback that this is an 246 OWE protected network, but this should not be too prominent to avoid 247 users assuming that they are getting more security than they actually 248 are. 250 3.2. OWE Advertisement in Access Network Query Protocol (ANQP) 252 This section to be fleshed out later, but the same general principle 253 applies. 255 SUpport for OWE can also be advertised in IEEE 802.11u-2011 using a 256 virtual roaming consortium with the same OUI. Examples will be 257 provided soon. 259 4. Deployment 261 Because one of the largest problems with most low-end WiFi devices is 262 their ability to receive timely updates to patch security holes and 263 add new features post sale, it may be appropriate to define a 264 lightweight version of this opportunistic encryption such that one or 265 both sides of the wireless network connection can take advantage of 266 this improved privacy via opportunistic encryption despite not being 267 updated to formally support OWE beacons. This model simply defines 268 an agreed-upon or best practice method for manually configuring both 269 network and client devices to attempt connecting to open, but secured 270 WiFi networks when the password is not published, but the presence of 271 a password is intended to provide link encryption rather than access 272 control. 274 As with the full mode defined above, the access point is configured 275 to accept a WPA2-PSK that is identical to the SSID. However, instead 276 of advertising the OWE capability in beacons, the network looks like 277 a standard encrypted network to host devices that wish to connect to 278 it. Host devices that are not OWE aware can be configured by the 279 user to connect in the standard process, by selecting the desired 280 SSID and manually entering a password that just happens to be the 281 same as the SSID. Host devices that are OWE-aware can automatically 282 try the SSID as a password when the user selects that network to 283 attempt to connect to it, and only present the user with a password 284 prompt if that authentication fails, even if there is no OWE beacon 285 seen from the AP. If the device is able to connect to the network 286 automatically via the SSID password, it can infer that this is an OWE 287 network and present the appropriate notifications to the user. 289 4.1. Advertising OWE support on legacy devices 291 OWE is designed for use on consumer / commodity Customer Premises 292 Equipment (CPE). The software running on these devices are often not 293 upgrades for many years, and so adding the OWE Vendor Specific 294 Information Element into the beacon may not be feasible. In order to 295 allow users of these devices to still be able to advertise OWE 296 support we define an interim measure. 298 A user who wishes to advertise that their network / SSID supports OWE 299 should add the string '_owe' to the SSID name and set the passphrase 300 the same as the SSID. Clients connecting to this SSID SHOULD try the 301 full SSID name (including the _owe suffix) and SHOULD NOT display the 302 lock icon. Users who have legacy clients can manually see that the 303 SSID ends in _owe and manually configure the passphrase as the SSID. 305 5. Implementation notes 307 [ Ed note: This section contains rough notes for people who want to 308 experiment with OWE. It will be tidied / removed before 309 publication.] 311 There is some (very rough) example code in the Github repository, and 312 also some example beacon captures, in pcapng format (view with 313 Wireshark / tcpdump) 315 The easiest way to quickly test this (IMO) is to install the hostapd 316 tools on something like a Raspberry Pi, and then add 318 319 #OWE: 320 vendor_elements=dd05646a740100 321 323 to /etc/hostapd/hostapd.conf. 325 Another easy option is to use an AP running OpenWRT[OpenWrt]. My 326 testing setup for this is a Ubiquiti Unifi (~$70USD on Amazon) 327 running Barrier Breaker 14.07. 329 After installing OpenWRT login via SSH and edit the /lib/netifd/ 330 hostapd.sh (this gets run when the WiFi interfaces is enabled). Find 331 the section around 'append bss_conf' and add: 333 334 #This adds the OWE 802.11 Vendor Specific Information Element to the beacon frames. 335 append bss_conf "# OWE: Opportunistic Wireless Encryption - draft-wkumari-owe" "$N" 336 append bss_conf "vendor_elements=dd05646a740100" "$N" 337 339 Disable and reenable the Wireless interface and it should start 340 including the OWE information element in all beacon frames. You can 341 look at the generated config in /tmp/run/hostapd-phy0.conf. While it 342 works, this code is far from ideal - it always includes the OWE 343 Vendor Specific Information Element - eventually I'll add something 344 to the GUI to enable users to toggle it on and off, but this is a 345 good start for testing. Look for additional code in the Github repo 346 soon! 348 6. IANA Considerations 350 [ To be completed after discussions ] 352 Currently the OWE Vendor-specific Information Element is using type 353 1, sub-type 0 under the AUTH-SERVERS OUI. This is to allow 354 experimentation with OWE without squatting on the IANA OUI. If OWE 355 progresses within the IETF, and the IESG chooses, I'm fine to place 356 this under the IANA OUI, or for it to remain under AUTH-SERVERS. 357 It's all just numbers. 359 7. Security Considerations 361 There are many attacks that this does not protect against, including 362 attackers watching the 4-Way Handshake and deriving the PTK between 363 the client and the user. This is a weakness in the wireless 364 specification, and not specific to OWE. In order to not have the 365 user assume that they are getting stronger protection than they 366 really are, the user interface should not provide obvious feedback 367 that OWE is in use. OWE simply raises the bar slightly; it does not 368 claim to solve all wireless issues. 370 This solution does not protect against so called "fake AP" attacks. 371 Wireless networks that use PSKs that the attacker may know are 372 vulnerable to an attacker standing up an access point with the same 373 SSID and PSK. This is not specific to OWE, it affects all WiFi 374 networks. 376 This solution does not (directly) protect against disassociation 377 attacks and the attacker observing the client authentication. This 378 is not specific to OWE. 380 This solution does not claim to provide "strong" security, it is 381 intended to be less insecure than "open" WiFi. In order to avoid 382 users assuming that they are getting more security than they really 383 are, OWE protected networks do not get a "lock" icon then scanning 384 for WiFi networks. 386 Ideally users would only associate to networks that they trust, using 387 WPA2-Enterprise (802.1X) with certificates that they trust, and then 388 immediately use a VPN to a trusted endpoint. However, open wifi is 389 really convenient and users will continue to want it. While 390 abstinence is the best policy, OWE recognises that users will 391 continue to behave in risky ways, and thus aims to make this slightly 392 less risky... 394 8. Privacy Considerations 396 By making "open" wireless encrypted by default we aim to increase 397 privacy by decreasing the incidence of passive eavesdropping by 398 pervasive monitors and idle attackers. 400 9. Acknowledgements 402 The authors would like to thank a bunch of people, including Stephen 403 Farrell, Ted Hardie, Chris Morrow. 405 10. References 407 10.1. Normative References 409 [IEEE.802-11i] 410 IANA, "IEEE 802 Part 11: Wireless LAN Medium Access 411 Control (MAC) and Physical Layer (PHY) specifications 412 Amendment 6: Medium Access Control (MAC) Security 413 Enhancements", . 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 418 RFC2119, March 1997, 419 . 421 10.2. Informative References 423 [OpenWrt] IANA, "OpenWrt", . 425 Appendix A. Changes / Author Notes. 427 [RFC Editor: Please remove this section before publication ] 429 From -01 to -02: 431 o Integrated some changes from Wes. 433 From -00 to -01: 435 o Included comments and feedback from Stephen Farrell. 437 o Some more nits. 439 From null to -00. 441 o Initial text. 443 Authors' Addresses 445 Warren Kumari 446 Google 447 1600 Amphitheatre Parkway 448 Mountain View, CA 94043 449 US 451 Email: warren@kumari.net 453 Wesley George 454 Time Warner Cable 455 13820 Sunrise Valley Drive 456 Herndon, VA 20171 457 US 459 Email: wesley.george@twcable.com