idnits 2.17.00 (12 Aug 2021) /tmp/idnits28207/draft-wkumari-owe-00.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 (August 19, 2015) is 2467 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: February 20, 2016 Time Warner Cable 6 August 19, 2015 8 OWE: Opportunistic Wireless Encryption 9 draft-wkumari-owe-00 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 February 20, 2016. 43 Copyright Notice 45 Copyright (c) 2015 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 3.3. Implementation notes . . . . . . . . . . . . . . . . . . 6 68 4. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 9.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. tl;dr / Executive summary 81 This (colloquial) summary will be removed before publication: 83 Currently, there are many open/unencrypted public WiFi networks, 84 designed for "ease of use" in places such as coffee shops, libraries, 85 etc. When a user connects to these open networks, they are using an 86 unencrypted connection and their traffic can be easily viewed and/or 87 intercepted by any other user within wireless range, simply by using 88 a network sniffing tool such as Wireshark. 90 While users *should* use a VPN, many do not. Places that provide 91 public WiFi access *should* only provide an encrypted SSID, and print 92 the passphrase on the wall or receipts (or similar); but, well, they 93 are a coffee shop, and want to provide easy access to everyone who 94 buys an espresso... 96 This document defines a new, opportunistically encrypted mode for 97 WiFi networks. The SSID will still appear to be open (there will not 98 be a "lock" icon when scanning), but will actually be encrypted, 99 using the SSID as the passphrase. Software running on the client 100 will detect that this is an opportunistically encrypted connection 101 and will automagically provide the SSID as the passphrase, providing 102 an encrypted connection without any interaction from the user. This 103 system leverages existing WiFi protocols and WPA2, the only change is 104 in operational practices and the client UI. 106 1.1. FAQ / Common questions / Notes 108 Q1: If everyone uses the SSID as the key, can't attackers just use 109 this to decrypt all the data? 110 A: WPA2 using PSK generates a unique Pairwise Transient Key (PTK) 111 between the AP and each client. This PTK is derived using something 112 called the 4-Way Handshake ( see IEEE 802.11-2012 (or the summary at 113 https://en.wikipedia.org/wiki/IEEE_802.11i-2004#The_four- 114 way_handshake )), which includes nonces from both the client and the 115 AP. Unfortunately, this doesn't use a public key exchange protocol, 116 and so an attacker who can watch the initial client association can 117 derive the user's encryption key. This is a weakness in WPA2-PSK, 118 and not specific to OWE. 120 Q2: So does this actually help? 121 A: Yes. This provides protection if the passive attacker wasn't 122 already present when the user connected, or if the passive attacker 123 was not able to hear both sides of the connection. OWE does not 124 provide very strong protection, and does not claim to. It does, 125 however, raise the bar for the attacker, or force him to become 126 active (and force users to disassociate (so he can watch the 4 way 127 handshake)). OWE specifically does NOT provide the "lock" icon (or 128 any other obvious feedback) when users scan for open wireless 129 networks, because we do not want users to assume that they are 130 getting "real" encryption. OWE will become more secure if and when 131 WiFi with a secure PAKE / public key exchange is deployed. The 132 incremental cost to implement OWE is very small (it involves adding a 133 flag to beacons, and clients to know to not display the lock icon) 134 and so we feel that the benefit outweighs the cost. 136 Q3: Isn't this vulnerable to the fake AP attack?! 137 A: Yes. An attacker can stand up their own AP with the same SSID and 138 passphrase. This is true for any network that uses WPA2-PSK when the 139 attacker knows the passphrase (for example, if the coffeeshop prints 140 the passphrase on the wall, receipts, etc) and it not specific to 141 OWE. OWE is not designed to defeat active attackers, nor solve all 142 issues. See Q2. 144 Q4: This isn't really opportunistic encryption... 145 A: Perhaps not, but it is has many of the same properties - it is 146 unauthenticated, is mainly designed to deal with passive listeners, 147 doesn't require interaction from the user, etc. I also wanted to 148 have a cool acronym - actually I wanted it to be OWL, but was not 149 able to reverse engineer a non-contrived name that made that... 151 Q5: Doesn't this belong in [ IEEE | WiFi Alliance | ] ? 153 A: Answer unclear, ask again later. I have discussed this with a 154 number of people who participate in other SDOs, and it seems like the 155 IETF is the best home for it, at least for now. It does not require 156 changes to any underlying transport, it does not change any 157 standards, it simply takes advantage of work done in other standards 158 bodies. 160 2. Introduction / Background 162 As of the time of this writing, it is very common for users to 163 connect to so called "open" wireless networks, for example in coffee 164 shops, hotels, airports and similar. These networks provide no 165 encryption, which means that the user's traffic is visible to anyone 166 nearby with packet capture software, for example, Wireshark. It is 167 also trivial for an attacker to perform a Man-in-the-middle attacks 168 as they can see all of the user's traffic. 170 There are a number of solutions to this problem, such as WPA2 (Wi-Fi 171 Protected Access II), but these require either obtaining a passphrase 172 from the network operator (WPA-Personal / Pre-Shared Key (PSK) mode) 173 or having valid credentials for the network (WPA-Enterprise / 174 [IEEE.802-11i]WPA-802.1X). 176 While these provide good security, for convenience reasons network 177 operators often deploy open / unencrypted networks for public or 178 "guest" use. This allows the public or visitors to get Internet 179 access without having to ask for a passphrase, look around for one 180 printed on a receipt or similar. Instead of chastising network 181 operators for providing insecure access, this document provides a 182 method to implement unauthenticated, encrypted network access. 184 This is not intended to replace other existing and more robust 185 methods of authentication that provide encrypted access to a WiFi 186 network once the user is authenticated and authorized to join the 187 network, e.g. WPA-Enterprise / IEEE 802.1x or Hotspot 2.0. Rather, 188 this is intended for low-end, unmanaged guest access networks such as 189 SOHO networks that would otherwise either be left unencrypted, or 190 whose password would be shared via other means such as posting it on 191 the wall of the coffeeshop. 193 2.1. Requirements notation 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [RFC2119]. 199 3. OWE protected networks 201 In order to provide an encrypted connection using OWE, the network 202 operator creates an SSID with the (WPA2 / 802.11i [IEEE.802-11i]) 203 pre-shared key identical to the SSID. As part of the WPA2 protocol 204 the wireless client (STAtion) and Access Point (AP) derive a Pairwise 205 Transient Key (PTK), which provides an encrypted "channel" between 206 the client and AP. 208 3.1. OWE Support Advertisement in Beacons 210 In order to advertise that this network supports OWE the Access Point 211 will include the OWE Vendor-specific Information Element in Wireless 212 Beacon frames. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | VSA (221) | Length (5) | OUI 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 OUI (Cont) | Type | Sub-type | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 VSA One octet. The IEEE Assigned Vendor-Specific Information 223 element ID - 221. 225 Length One octet. The length of the information field, including 226 the OUI - 5. 228 OUI Three octets. The OUI for the of the entity that has defined 229 the content of the particular vendor-specific information element 230 - 64-6A-74 (AUTH-SERVERS). [ If approved, this may move under the 231 IANA OUI if desired] 233 Type One octet. OWE has been assigned Type 1 under the AUTH-SERVERS 234 OUI 236 Sub-type One octet. Sub-type identified the version of the OWE 237 protocol. Currently only 0 is defined. 239 An Access Point that includes the OWE Vendor-specific Information 240 Element in beacon frames is signalling that is supports OWE on that 241 particular SSID, and that they PSK is the same as the SSID. Client 242 (STAtions) connecting to OWE enabled networks MUST use the SSID as 243 the PSK, and MUST NOT display a "lock" icon in the list of SSIDs when 244 scanning. User Interfaces MAY provide some feedback that this is an 245 OWE protected network, but this should not be too prominent to avoid 246 users assuming that they are getting more security than they actually 247 are. 249 3.2. OWE Advertisement in Access Network Query Protocol (ANQP) 251 This section to be fleshed out later, but the same general principle 252 applies. 254 SUpport for OWE can also be advertised in IEEE 802.11u-2011 using a 255 virtual roaming consortium with the same OUI. Examples will be 256 provided soon. 258 3.3. Implementation notes 260 [ Ed note: This section contains rough notes for people who want to 261 experiment with OWE. It will be tidied / removed before 262 publication.] 264 There is some (very rough) example code in the Github repository, and 265 also some example beacon captures, in pcapng format (view with 266 Wireshark / tcpdump) 268 The easiest way to quickly test this (IMO) is to install the hostapd 269 tools on something like a Raspberry Pi, and then add 271 272 #OWE: 273 vendor_elements=dd05646a740100 274 276 to /etc/hostapd/hostapd.conf. 278 Another easy option is to use an AP running OpenWRT[OpenWrt]. My 279 testing setup for this is a Ubiquiti Unifi (~$70USD on Amazon) 280 running Barrier Breaker 14.07. 282 After installing OpenWRT login via SSH and edit the /lib/netifd/ 283 hostapd.sh (this gets run when the WiFi interfaces is enabled). Find 284 the section around 'append bss_conf' and add: 286 287 #This adds the OWE 802.11 Vendor Specific Information Element to the beacon frames. 288 append bss_conf "# OWE: Opportunistic Wireless Encryption - draft-wkumari-owe" "$N" 289 append bss_conf "vendor_elements=dd05646a740100" "$N" 290 292 Disable and reenable the Wireless interface and it should start 293 including the OWE information element in all beacon frames. You can 294 look at the generated config in /tmp/run/hostapd-phy0.conf. While it 295 works, this code is far from ideal - it always includes the OWE 296 Vendor Specific Information Element - eventually I'll add something 297 to the GUI to enable users to toggle it on and off, but this is a 298 good start for testing. Look for additional code in the Github repo 299 soon! 301 4. Deployment 303 Because one of the largest problems with most low-end WiFi devices is 304 their ability to receive timely updates to patch security holes and 305 add new features post sale, it may be appropriate to define a 306 lightweight version of this opportunistic encryption such that one or 307 both sides of the wireless network connection can take advantage of 308 this improved privacy via opportunistic encryption despite not being 309 updated to formally support OWE beacons. This model simply defines 310 an agreed-upon or best practice method for manually configuring both 311 network and client devices to attempt connecting to open, but secured 312 WiFi networks when the password is not published, but the presence of 313 a password is intended to provide link encryption rather than access 314 control. 316 As with the full mode defined above, the access point is configured 317 to accept a WPA2-PSK that is identical to the SSID. However, instead 318 of advertising the OWE capability in beacons, the network looks like 319 a standard encrypted network to host devices that wish to connect to 320 it. Host devices that are not OWE aware can be configured by the 321 user to connect in the standard process, by selecting the desired 322 SSID and manually entering a password that just happens to be the 323 same as the SSID. Host devices that are OWE-aware can automatically 324 try the SSID as a password when the user selects that network to 325 attempt to connect to it, and only present the user with a password 326 prompt if that authentication fails, even if there is no OWE beacon 327 seen from the AP. If the device is able to connect to the network 328 automatically via the SSID password, it can infer that this is an OWE 329 network and present the appropriate notifications to the user. 331 [ Open question: Instead of just having clients attempt to connect to 332 whatever SSID they see, we could propose that OWE support is encoded 333 into the SSID at well -- for example, open WiFi operators could 334 append "--owe" to the name (e.g CentralPerk--owe). Thoughts? ] 336 5. IANA Considerations 338 [ To be completed after discussions ] 340 Currently the OWE Vendor-specific Information Element is using type 341 1, sub-type 0 under the AUTH-SERVERS OUI. This is to allow 342 experimentation with OWE without squatting on the IANA OUI. If OWE 343 progresses within the IETF, and the IESG chooses, I'm fine to place 344 this under the IANA OUI, or for it to remain under AUTH-SERVERS. 345 It's all just numbers. 347 6. Security Considerations 349 There are many attacks that this does not protect against, including 350 attackers watching the 4-Way Handshake and deriving the PTK between 351 the client and the user. This is a weakness in the wireless 352 specification, and not specific to OWE. In order to not have the 353 user assume that they are getting stronger protection than they 354 really are, the user interface should not provide obvious feedback 355 that OWE is in use. OWE simply raises the bar slightly; it does not 356 claim to solve all wireless issues. 358 This solution does not protect against so called "fake AP" attacks. 359 Wireless networks that use PSKs that the attacker may know are 360 vulnerable to an attacker standing up an access point with the same 361 SSID and PSK. This is not specific to OWE, it affects all WiFi 362 networks. 364 This solution does not (directly) protect against disassociation 365 attacks and the attacker observing the client authentication. This 366 is not specific to OWE. 368 This solution does not claim to provide "strong" security, it is 369 intended to be less insecure than "open" WiFi. In order to avoid 370 users assuming that they are getting more security than they really 371 are, OWE protected networks do not get a "lock" icon then scanning 372 for WiFi networks. 374 Ideally users would only associate to networks that they trust, using 375 WPA2-Enterprise (802.1X) with certificates that they trust, and then 376 immediately use a VPN to a trusted endpoint. However, open wifi is 377 really convenient and users will continue to want it. While 378 abstinence is the best policy, OWE recognises that users will 379 continue to behave in risky ways, and thus aims to make this slightly 380 less risky... 382 7. Privacy Considerations 384 By making "open" wireless encrypted by default we aim to decrease the 385 incidence of passive eavesdropping by pervasive monitors and idle 386 attackers. 388 8. Acknowledgements 390 The authors would like to thank a bunch of people, including Ted 391 Hardie, Chris Morrow. 393 9. References 395 9.1. Normative References 397 [IEEE.802-11i] 398 IANA, "IEEE 802 Part 11: Wireless LAN Medium Access 399 Control (MAC) and Physical Layer (PHY) specifications 400 Amendment 6: Medium Access Control (MAC) Security 401 Enhancements", . 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 406 RFC2119, March 1997, 407 . 409 9.2. Informative References 411 [OpenWrt] IANA, "OpenWrt", . 413 Appendix A. Changes / Author Notes. 415 [RFC Editor: Please remove this section before publication ] 417 From null to -00. 419 o Initial text. 421 Authors' Addresses 423 Warren Kumari 424 Google 425 1600 Amphitheatre Parkway 426 Mountain View, CA 94043 427 US 429 Email: warren@kumari.net 430 Wesley George 431 Time Warner Cable 432 13820 Sunrise Valley Drive 433 Herndon, VA 20171 434 US 436 Email: wesley.george@twcable.com