< draft-wkumari-owe-00.txt   draft-wkumari-owe-01.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational W. George Intended status: Informational W. George
Expires: February 20, 2016 Time Warner Cable Expires: February 21, 2016 Time Warner Cable
August 19, 2015 August 20, 2015
OWE: Opportunistic Wireless Encryption OWE: Opportunistic Wireless Encryption
draft-wkumari-owe-00 draft-wkumari-owe-01
Abstract Abstract
This document describes a method to incrementally increase the This document describes a method to incrementally increase the
security of wireless networks against passive attackers / pervasive security of wireless networks against passive attackers / pervasive
monitors through unauthenticated encryption. monitors through unauthenticated encryption.
[ Ed note: Text inside square brackets ([]) is additional background [ Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings, information, answers to frequently asked questions, general musings,
etc. They will be removed before publication.] etc. They will be removed before publication.]
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 20, 2016. This Internet-Draft will expire on February 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. tl;dr / Executive summary . . . . . . . . . . . . . . . . . . 2 1. tl;dr / Executive summary . . . . . . . . . . . . . . . . . . 2
1.1. FAQ / Common questions / Notes . . . . . . . . . . . . . 3 1.1. FAQ / Common questions / Notes . . . . . . . . . . . . . 3
2. Introduction / Background . . . . . . . . . . . . . . . . . . 4 2. Introduction / Background . . . . . . . . . . . . . . . . . . 4
2.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
3. OWE protected networks . . . . . . . . . . . . . . . . . . . 5 3. OWE protected networks . . . . . . . . . . . . . . . . . . . 5
3.1. OWE Support Advertisement in Beacons . . . . . . . . . . 5 3.1. OWE Support Advertisement in Beacons . . . . . . . . . . 5
3.2. OWE Advertisement in Access Network Query Protocol (ANQP) 6 3.2. OWE Advertisement in Access Network Query Protocol (ANQP) 6
3.3. Implementation notes . . . . . . . . . . . . . . . . . . 6 4. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Advertising OWE support on legacy devices . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Implementation notes . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. tl;dr / Executive summary 1. tl;dr / Executive summary
This (colloquial) summary will be removed before publication: This (colloquial) summary will be removed before publication:
Currently, there are many open/unencrypted public WiFi networks, Currently, there are many open/unencrypted public WiFi networks,
designed for "ease of use" in places such as coffee shops, libraries, designed for "ease of use" in places such as coffee shops, libraries,
etc. When a user connects to these open networks, they are using an etc. When a user connects to these open networks, they are using an
unencrypted connection and their traffic can be easily viewed and/or unencrypted connection and their traffic can be easily viewed and/or
intercepted by any other user within wireless range, simply by using intercepted by any other user within wireless range, simply by using
skipping to change at page 3, line 40 skipping to change at page 3, line 40
A: Yes. This provides protection if the passive attacker wasn't A: Yes. This provides protection if the passive attacker wasn't
already present when the user connected, or if the passive attacker already present when the user connected, or if the passive attacker
was not able to hear both sides of the connection. OWE does not was not able to hear both sides of the connection. OWE does not
provide very strong protection, and does not claim to. It does, provide very strong protection, and does not claim to. It does,
however, raise the bar for the attacker, or force him to become however, raise the bar for the attacker, or force him to become
active (and force users to disassociate (so he can watch the 4 way active (and force users to disassociate (so he can watch the 4 way
handshake)). OWE specifically does NOT provide the "lock" icon (or handshake)). OWE specifically does NOT provide the "lock" icon (or
any other obvious feedback) when users scan for open wireless any other obvious feedback) when users scan for open wireless
networks, because we do not want users to assume that they are networks, because we do not want users to assume that they are
getting "real" encryption. OWE will become more secure if and when getting "real" encryption. OWE will become more secure if and when
WiFi with a secure PAKE / public key exchange is deployed. The WiFi with a public key exchange (such as Diffie-Hellman) is deployed.
incremental cost to implement OWE is very small (it involves adding a The incremental cost to implement OWE is very small (it involves
flag to beacons, and clients to know to not display the lock icon) adding a flag to beacons, and clients to know to not display the lock
and so we feel that the benefit outweighs the cost. icon) and so we feel that the benefit outweighs the cost.
Q3: Isn't this vulnerable to the fake AP attack?! Q3: Isn't this vulnerable to the fake AP attack?!
A: Yes. An attacker can stand up their own AP with the same SSID and A: Yes. An attacker can stand up their own AP with the same SSID and
passphrase. This is true for any network that uses WPA2-PSK when the passphrase. This is true for any network that uses WPA2-PSK when the
attacker knows the passphrase (for example, if the coffeeshop prints attacker knows the passphrase (for example, if the coffee shop prints
the passphrase on the wall, receipts, etc) and it not specific to the passphrase on the wall, receipts, etc) and it not specific to
OWE. OWE is not designed to defeat active attackers, nor solve all OWE. OWE is not designed to defeat active attackers, nor solve all
issues. See Q2. issues. See Q2.
Q4: This isn't really opportunistic encryption... Q4: This isn't really opportunistic encryption...
A: Perhaps not, but it is has many of the same properties - it is A: Perhaps not, but it is has many of the same properties - it is
unauthenticated, is mainly designed to deal with passive listeners, unauthenticated, is mainly designed to deal with passive listeners,
doesn't require interaction from the user, etc. I also wanted to doesn't require interaction from the user, etc. I also wanted to
have a cool acronym - actually I wanted it to be OWL, but was not have a cool acronym - actually I wanted it to be OWL, but was not
able to reverse engineer a non-contrived name that made that... able to reverse engineer a non-contrived name that made that...
skipping to change at page 4, line 28 skipping to change at page 4, line 28
standards, it simply takes advantage of work done in other standards standards, it simply takes advantage of work done in other standards
bodies. bodies.
2. Introduction / Background 2. Introduction / Background
As of the time of this writing, it is very common for users to As of the time of this writing, it is very common for users to
connect to so called "open" wireless networks, for example in coffee connect to so called "open" wireless networks, for example in coffee
shops, hotels, airports and similar. These networks provide no shops, hotels, airports and similar. These networks provide no
encryption, which means that the user's traffic is visible to anyone encryption, which means that the user's traffic is visible to anyone
nearby with packet capture software, for example, Wireshark. It is nearby with packet capture software, for example, Wireshark. It is
also trivial for an attacker to perform a Man-in-the-middle attacks also trivial for an attacker to perform a Man-in-the-Middle attacks
as they can see all of the user's traffic. as they can see all of the user's traffic.
There are a number of solutions to this problem, such as WPA2 (Wi-Fi There are a number of solutions to this problem, such as WPA2 (Wi-Fi
Protected Access II), but these require either obtaining a passphrase Protected Access II), but these require either obtaining a passphrase
from the network operator (WPA-Personal / Pre-Shared Key (PSK) mode) from the network operator (WPA-Personal / Pre-Shared Key (PSK) mode)
or having valid credentials for the network (WPA-Enterprise / or having valid credentials for the network (WPA-Enterprise /
[IEEE.802-11i]WPA-802.1X). [IEEE.802-11i]WPA-802.1X).
While these provide good security, for convenience reasons network While these provide good security, for convenience reasons network
operators often deploy open / unencrypted networks for public or operators often deploy open / unencrypted networks for public or
skipping to change at page 4, line 52 skipping to change at page 4, line 52
operators for providing insecure access, this document provides a operators for providing insecure access, this document provides a
method to implement unauthenticated, encrypted network access. method to implement unauthenticated, encrypted network access.
This is not intended to replace other existing and more robust This is not intended to replace other existing and more robust
methods of authentication that provide encrypted access to a WiFi methods of authentication that provide encrypted access to a WiFi
network once the user is authenticated and authorized to join the network once the user is authenticated and authorized to join the
network, e.g. WPA-Enterprise / IEEE 802.1x or Hotspot 2.0. Rather, network, e.g. WPA-Enterprise / IEEE 802.1x or Hotspot 2.0. Rather,
this is intended for low-end, unmanaged guest access networks such as this is intended for low-end, unmanaged guest access networks such as
SOHO networks that would otherwise either be left unencrypted, or SOHO networks that would otherwise either be left unencrypted, or
whose password would be shared via other means such as posting it on whose password would be shared via other means such as posting it on
the wall of the coffeeshop. the wall of the coffee shop.
2.1. Requirements notation 2.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. OWE protected networks 3. OWE protected networks
In order to provide an encrypted connection using OWE, the network In order to provide an encrypted connection using OWE, the network
skipping to change at page 6, line 24 skipping to change at page 6, line 24
3.2. OWE Advertisement in Access Network Query Protocol (ANQP) 3.2. OWE Advertisement in Access Network Query Protocol (ANQP)
This section to be fleshed out later, but the same general principle This section to be fleshed out later, but the same general principle
applies. applies.
SUpport for OWE can also be advertised in IEEE 802.11u-2011 using a SUpport for OWE can also be advertised in IEEE 802.11u-2011 using a
virtual roaming consortium with the same OUI. Examples will be virtual roaming consortium with the same OUI. Examples will be
provided soon. provided soon.
3.3. Implementation notes 4. Deployment
Because one of the largest problems with most low-end WiFi devices is
their ability to receive timely updates to patch security holes and
add new features post sale, it may be appropriate to define a
lightweight version of this opportunistic encryption such that one or
both sides of the wireless network connection can take advantage of
this improved privacy via opportunistic encryption despite not being
updated to formally support OWE beacons. This model simply defines
an agreed-upon or best practice method for manually configuring both
network and client devices to attempt connecting to open, but secured
WiFi networks when the password is not published, but the presence of
a password is intended to provide link encryption rather than access
control.
As with the full mode defined above, the access point is configured
to accept a WPA2-PSK that is identical to the SSID. However, instead
of advertising the OWE capability in beacons, the network looks like
a standard encrypted network to host devices that wish to connect to
it. Host devices that are not OWE aware can be configured by the
user to connect in the standard process, by selecting the desired
SSID and manually entering a password that just happens to be the
same as the SSID. Host devices that are OWE-aware can automatically
try the SSID as a password when the user selects that network to
attempt to connect to it, and only present the user with a password
prompt if that authentication fails, even if there is no OWE beacon
seen from the AP. If the device is able to connect to the network
automatically via the SSID password, it can infer that this is an OWE
network and present the appropriate notifications to the user.
4.1. Advertising OWE support on legacy devices
OWE is designed for use on consumer / commodity Customer Premises
Equipment (CPE). The software running on these devices are often not
upgrades for many years, and so adding the OWE Vendor Specific
Information Element into the beacon may not be feasible. In order to
allow users of these devices to still be able to advertise OWE
support we define an interim measure.
A user who wishes to advertise that their network / SSID supports OWE
should add the string '_owe' to the SSID name and set the passphrase
the same as the SSID. Clients connecting to this SSID SHOULD try the
full SSID name (including the _owe suffix) and SHOULD NOT display the
lock icon. Users who have legacy clients can manually see that the
SSID ends in _owe and manually configure the passphrase as the SSID.
5. Implementation notes
[ Ed note: This section contains rough notes for people who want to [ Ed note: This section contains rough notes for people who want to
experiment with OWE. It will be tidied / removed before experiment with OWE. It will be tidied / removed before
publication.] publication.]
There is some (very rough) example code in the Github repository, and There is some (very rough) example code in the Github repository, and
also some example beacon captures, in pcapng format (view with also some example beacon captures, in pcapng format (view with
Wireshark / tcpdump) Wireshark / tcpdump)
The easiest way to quickly test this (IMO) is to install the hostapd The easiest way to quickly test this (IMO) is to install the hostapd
skipping to change at page 7, line 20 skipping to change at page 8, line 20
Disable and reenable the Wireless interface and it should start Disable and reenable the Wireless interface and it should start
including the OWE information element in all beacon frames. You can including the OWE information element in all beacon frames. You can
look at the generated config in /tmp/run/hostapd-phy0.conf. While it look at the generated config in /tmp/run/hostapd-phy0.conf. While it
works, this code is far from ideal - it always includes the OWE works, this code is far from ideal - it always includes the OWE
Vendor Specific Information Element - eventually I'll add something Vendor Specific Information Element - eventually I'll add something
to the GUI to enable users to toggle it on and off, but this is a to the GUI to enable users to toggle it on and off, but this is a
good start for testing. Look for additional code in the Github repo good start for testing. Look for additional code in the Github repo
soon! soon!
4. Deployment 6. IANA Considerations
Because one of the largest problems with most low-end WiFi devices is
their ability to receive timely updates to patch security holes and
add new features post sale, it may be appropriate to define a
lightweight version of this opportunistic encryption such that one or
both sides of the wireless network connection can take advantage of
this improved privacy via opportunistic encryption despite not being
updated to formally support OWE beacons. This model simply defines
an agreed-upon or best practice method for manually configuring both
network and client devices to attempt connecting to open, but secured
WiFi networks when the password is not published, but the presence of
a password is intended to provide link encryption rather than access
control.
As with the full mode defined above, the access point is configured
to accept a WPA2-PSK that is identical to the SSID. However, instead
of advertising the OWE capability in beacons, the network looks like
a standard encrypted network to host devices that wish to connect to
it. Host devices that are not OWE aware can be configured by the
user to connect in the standard process, by selecting the desired
SSID and manually entering a password that just happens to be the
same as the SSID. Host devices that are OWE-aware can automatically
try the SSID as a password when the user selects that network to
attempt to connect to it, and only present the user with a password
prompt if that authentication fails, even if there is no OWE beacon
seen from the AP. If the device is able to connect to the network
automatically via the SSID password, it can infer that this is an OWE
network and present the appropriate notifications to the user.
[ Open question: Instead of just having clients attempt to connect to
whatever SSID they see, we could propose that OWE support is encoded
into the SSID at well -- for example, open WiFi operators could
append "--owe" to the name (e.g CentralPerk--owe). Thoughts? ]
5. IANA Considerations
[ To be completed after discussions ] [ To be completed after discussions ]
Currently the OWE Vendor-specific Information Element is using type Currently the OWE Vendor-specific Information Element is using type
1, sub-type 0 under the AUTH-SERVERS OUI. This is to allow 1, sub-type 0 under the AUTH-SERVERS OUI. This is to allow
experimentation with OWE without squatting on the IANA OUI. If OWE experimentation with OWE without squatting on the IANA OUI. If OWE
progresses within the IETF, and the IESG chooses, I'm fine to place progresses within the IETF, and the IESG chooses, I'm fine to place
this under the IANA OUI, or for it to remain under AUTH-SERVERS. this under the IANA OUI, or for it to remain under AUTH-SERVERS.
It's all just numbers. It's all just numbers.
6. Security Considerations 7. Security Considerations
There are many attacks that this does not protect against, including There are many attacks that this does not protect against, including
attackers watching the 4-Way Handshake and deriving the PTK between attackers watching the 4-Way Handshake and deriving the PTK between
the client and the user. This is a weakness in the wireless the client and the user. This is a weakness in the wireless
specification, and not specific to OWE. In order to not have the specification, and not specific to OWE. In order to not have the
user assume that they are getting stronger protection than they user assume that they are getting stronger protection than they
really are, the user interface should not provide obvious feedback really are, the user interface should not provide obvious feedback
that OWE is in use. OWE simply raises the bar slightly; it does not that OWE is in use. OWE simply raises the bar slightly; it does not
claim to solve all wireless issues. claim to solve all wireless issues.
skipping to change at page 9, line 5 skipping to change at page 9, line 19
for WiFi networks. for WiFi networks.
Ideally users would only associate to networks that they trust, using Ideally users would only associate to networks that they trust, using
WPA2-Enterprise (802.1X) with certificates that they trust, and then WPA2-Enterprise (802.1X) with certificates that they trust, and then
immediately use a VPN to a trusted endpoint. However, open wifi is immediately use a VPN to a trusted endpoint. However, open wifi is
really convenient and users will continue to want it. While really convenient and users will continue to want it. While
abstinence is the best policy, OWE recognises that users will abstinence is the best policy, OWE recognises that users will
continue to behave in risky ways, and thus aims to make this slightly continue to behave in risky ways, and thus aims to make this slightly
less risky... less risky...
7. Privacy Considerations 8. Privacy Considerations
By making "open" wireless encrypted by default we aim to decrease the By making "open" wireless encrypted by default we aim to increase
incidence of passive eavesdropping by pervasive monitors and idle privacy by decreasing the incidence of passive eavesdropping by
attackers. pervasive monitors and idle attackers.
8. Acknowledgements 9. Acknowledgements
The authors would like to thank a bunch of people, including Ted The authors would like to thank a bunch of people, including Stephen
Hardie, Chris Morrow. Farrell, Ted Hardie, Chris Morrow.
9. References 10. References
9.1. Normative References 10.1. Normative References
[IEEE.802-11i] [IEEE.802-11i]
IANA, "IEEE 802 Part 11: Wireless LAN Medium Access IANA, "IEEE 802 Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) specifications Control (MAC) and Physical Layer (PHY) specifications
Amendment 6: Medium Access Control (MAC) Security Amendment 6: Medium Access Control (MAC) Security
Enhancements", <http://standards.ieee.org/getieee802/ Enhancements", <http://standards.ieee.org/getieee802/
download/802.11i-2004.pdf>. download/802.11i-2004.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 10.2. Informative References
[OpenWrt] IANA, "OpenWrt", <http://wiki.openwrt.org/start>. [OpenWrt] IANA, "OpenWrt", <http://wiki.openwrt.org/start>.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ] [RFC Editor: Please remove this section before publication ]
From -00 to -01:
o Included comments and feedback from Stephen Farrell.
o Some more nits.
From null to -00. From null to -00.
o Initial text. o Initial text.
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
 End of changes. 19 change blocks. 
70 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/