It's "secure authentication of equals", which is a protocol that kind of looks like it's trying to be a PAKE (Password Authenticated Key Exchange), but the paper does not mention PAKE anywhere in its abstract, and I'm not at all confident that SAE's design or analysis takes into account the properties that PAKE protocols should have.
I think that the original WPA key exchange was supposed to use the SRP protocol, which is a PAKE, but that was dropped due to patent issues. Since then, as I understand it, quite a few very nice PAKE protocols have had their patents expire, so I don't see what the problem is now.
That's a Dan Harkins protocol; Harkins is a little notorious for Dragonfly, a PAKE he tried to get "approved" by IETF CFRG before being slagged by Trevor Perrin†, who wrote up a particularly simple and nasty side channel attack on the elliptic curve point generation technique Dragonfly used. SAE includes what looks like the same "hunt-and-peck" point generator.
All I ever read about the Dragonfly PAKE was trevp taking it apart on CFRG, but from a quick skim of this paper and the IETF draft Harkins wrote for Dragonfly, this looks like it's just an instantiation of Dragonfly.
That would be pretty funny.
What is it about WiFi security that makes it such a backwater?
> What is it about WiFi security that makes it such a backwater?
The fact that the specs are developed behind closed doors in pay-to-play venues? At least, IME, there's a pretty strong correlation between specs developed behind closed doors and bad specs.
There is plenty of more discussion on IETF mailing lists (and probably elsewhere too). Ultimately on a glance I can't say how trustworthy Dragonfly is because of the controversy. Perrin has obvious strong dislike for it, but that alone is not yet the end of the world.
It does indeed seem to be DRAGONFLY (I'd heard rumours indicating such in advance): a surprising choice for an interactive protocol with attacker-observable timings, I felt, given its already chequered reputation?
I couldn't possibly speculate as to why, but one does feel inclined to agree that the people behind wireless LAN security haven't always generally chosen high quality methods in the past, and this feels to me like it could well be a continuation of that pattern.
After some years staring at this I've decided everything looks this way if you're used to the Web PKI. I tried very hard at first to assume that the PCI SSC, the EMV group, Wi-Fi Alliance and suchlike are doing great work but it's behind closed doors and so invisible to me. That theory has been challenged so thoroughly that I feel compelled to reject it.
Four things that stick in my mind in no particular order in relation to this realisation:
1. Peter Gutmann's out of the blue attack on ACME when it was relatively young. Gutmann's SCEP doesn't solve the problem, and at first my assumption was that he just needed to have that explained. After a while I realised that SCEP's success depends up not understanding what the real problem is, and SCEP is widely deployed outside the Web PKI largely _because_ choosing not to understand the problem suits those applications perfectly well. ACME can't displace SCEP in such applications but its existence might cause people to ask uncomfortable questions and perhaps Peter would (unconsciously?) rather that didn't happen.
2. Eric Rescorla's explanation of what a great environment HTTP (and particularly web browsers) is for a cryptographic adversary. In the literature imaginary bad guys often get to watch one party do a million message/reply back and forths, time them accurately and then send a million bytes of nonsense data to the target as setup for their attack, and in many applications this would be ludicrous in practice, the target would obviously react, how could you do cause anyone to send so many messages without attracting notice, let alone time them? So the attacks seem just theoretical. But on the web you can just write some Javascript and victims will happily run it for you on their computers.
3. Dean Coclin of Symantec and eventually the various banks/ payment providers etcetera that had hidden behind Symantec explaining that such institutions really _needed_ security, unlike mere cat blogs and search engines, but of course they couldn't be expected to react to notice of serious issues with an obsolete hash algorithm in a timely fashion, and so surely they ought to get an extra year or five to upgrade from SHA-1, and if they didn't there'd be dire consequences.
4. ETSI's work on the "Middlebox Security Protocol" aka ETSI TS 103 523. Obviously most of this happens out of view, so we have no idea if there's something productive being discussed - but they kindly (?) shared their work in progress documents with outsiders including the TLS Working Group and er... yuck. I mean... see for yourself:
> Wi-Fi Alliance is also introducing Wi-Fi CERTIFIED Easy Connect™, a new program that reduces the complexity of onboarding Wi-Fi devices with limited or no display interface – such as devices coming to market for Internet of Things (IoT) – while still maintaining high security standards. Wi-Fi Easy Connect™ enables users to securely add any device to a Wi-Fi network using another device with a more robust interface, such as a smartphone, by simply scanning a product quick response (QR) code. Wi-Fi Easy Connect and WPA3 represent the latest evolution in Wi-Fi Alliance programs to ensure users receive a positive experience while remaining securely connected as the security landscape evolves.
This is highly reminiscent of WPS. The language indicates that they've learned their lesson and focused on making the standard secure, at least in theory. Time will tell how well it's implemented, but history says to be skeptical and disable it for the time being.
It is allowing any device already on the network to vouch for new devices. What could possibly go wrong? WPS had flaws in its implementation, but was reasonable on a theoretical level. This seems foolhardy at best.
WPA2, when properly implemented, is very secure. I'm not sure of WPA3's real purpose. Is strong encryption of wifi signals of any benefit? The days of banking passwords being send in html gets should be behind us. Anything important will be protected by other encryption layers than wifi. Is WPA3 meant to protect unauthorized network access? WPA2 isn't exactly easy to crack. Do we really need a new scheme, and the inevitable new flaws that come with it? Or is this really about streamlining the user experience, about making wifi that little bit less complicated, so that people can attached their smart toasters to the home network without having to actually remember the password.
To clarify for those who obviously do not understand the difference between protocol and concept implementation: Errors in the protocol would have been inconsequential if WPS was implemented properly. Had it not been left on 24/7, the temporary use of shorter keys would have been a good thing. It would have allowed home networks to adopt much more complex keys without having to type them into every new device (a big deal on things like printers which didn't have keyboards). WPS could have contributed to greater WPA2 security. But instead the concept was improperly implemented, allowing the inevitable errors discovered in the adopted protocol to be leveraged.
Though with WPA2 (personal, at least), isn't it already possible for "any permitted device" to "vouch for new devices" by simply giving those new devices the Wi-Fi password?
This is really why they went with WPA3, but I've noticed the Wi-Fi Alliance goes to great lengths to avoid any mentions of KRACK. So now, many, like you, are scratching their heads wondering what's the point of WPA3.
> WPS had flaws in its implementation, but was reasonable on a theoretical level.
Not sure about that since it has a key space of 10,000.
Implementations without a timeout were super-easy to crack while those with a timeout just took time to figure out how long the timeout was and to not exceed it. I have a Netgear wifi bridge that doesn't turn of WPS (even if you click the button) with no timeout and is trivial to get the password out of while another case it took a couple weeks once I determined the timeout.
*of course I only tested on my own devices and never engaged in wifi thievery from my neighbors
If I understood everything, you have to be a Wi-Fi Alliance member in order to develop/contribute/vote on all things WiFi. The smallest membership that allows you to participate is US$7,500/year for 2018 (next year it’ll be $7,725/year). And that’s only for small businesses and they won’t have all voting rights. The actual membership is a whopping US$15,000/year ($450 more next year).
It disgusts me to see that in order to improve something that a crapton of people use daily to protect them self, that’s currently broken, you’d have to pay. I didn’t see any mention that individuals can become members on the website of the Wi-Fi Alliance seems to be only businesses can participate.
I’d be alright with some open-source implementation instead.
Seems like it would encounter same problem earlier in Wifi history
"Early 802.11 products suffered from interoperability problems because the Institute of Electrical and Electronics Engineers (IEEE) had no provision for testing equipment for compliance with its standards."
Wi-Fi enhanced open looks like a nice security enhancement for open networks, but unfortunately (correct me if I'm wrong) it still doesn't look like it protects users from rogue access points; it only stops eavesdropping if users have already connected to the correct network.
I'd love to see a system similar to what Wi-Fi is already doing with Easy Connect, where users can scan a public key embedded in a QR Code or NFC tag to securely connect to a Wi-Fi network. (Or does Easy Connect already allow that? It'd be great if it does.)
That is the obvious difference, but why don't they develop crypto protocol with a more open model? They have had too many fiascos for me to trust their current model.
> WPA3 leverages Simultaneous Authentication of Equals (SAE), a secure key establishment protocol between devices, to provide stronger protections for users against password guessing attempts by third parties.
Is that their term for PAKE?
Also I hope they have finally included an actual error message for incorrect passwords, rather than just "connection failed" which is the best that seems to be possible at the moment.
I've seen some cases where I actually do get an authentication failed error connecting to wifi, but other cases where it just gives me some generic connection failed (even when the issue turns out to be authentication). It seems quite random.
Wow, I hadn't realized that WiFi standards were developed like this. Looking down the page, I see a bunch of TM symbols, endorsements from massive companies, and no technical details or even attempt to describe anything related to security. Not very confidence-inspiring to an outsider.
Readit News
https://ieeexplore.ieee.org/document/4622764/
It's "secure authentication of equals", which is a protocol that kind of looks like it's trying to be a PAKE (Password Authenticated Key Exchange), but the paper does not mention PAKE anywhere in its abstract, and I'm not at all confident that SAE's design or analysis takes into account the properties that PAKE protocols should have.
I think that the original WPA key exchange was supposed to use the SRP protocol, which is a PAKE, but that was dropped due to patent issues. Since then, as I understand it, quite a few very nice PAKE protocols have had their patents expire, so I don't see what the problem is now.
So color me extremely skeptical.
† https://www.ietf.org/mail-archive/web/tls/current/msg10922.h...
Later:
All I ever read about the Dragonfly PAKE was trevp taking it apart on CFRG, but from a quick skim of this paper and the IETF draft Harkins wrote for Dragonfly, this looks like it's just an instantiation of Dragonfly.
That would be pretty funny.
What is it about WiFi security that makes it such a backwater?
The fact that the specs are developed behind closed doors in pay-to-play venues? At least, IME, there's a pretty strong correlation between specs developed behind closed doors and bad specs.
https://www.ietf.org/mail-archive/web/tls/current/msg10962.h...
https://www.ietf.org/mail-archive/web/cfrg/current/msg03554....
https://www.ietf.org/mail-archive/web/cfrg/current/msg03736....
There is plenty of more discussion on IETF mailing lists (and probably elsewhere too). Ultimately on a glance I can't say how trustworthy Dragonfly is because of the controversy. Perrin has obvious strong dislike for it, but that alone is not yet the end of the world.
I couldn't possibly speculate as to why, but one does feel inclined to agree that the people behind wireless LAN security haven't always generally chosen high quality methods in the past, and this feels to me like it could well be a continuation of that pattern.
https://patents.justia.com/inventor/daniel-harkins
This one is granted:
https://patents.google.com/patent/US20170013449
"Original Assignee Aruba Networks Inc"
"Current Assignee Hewlett-Packard Enterprise Development LP"
He co-authored a blog post about the WPA3(TM):
http://community.arubanetworks.com/t5/Technology-Blog/WPA3-T...
After some years staring at this I've decided everything looks this way if you're used to the Web PKI. I tried very hard at first to assume that the PCI SSC, the EMV group, Wi-Fi Alliance and suchlike are doing great work but it's behind closed doors and so invisible to me. That theory has been challenged so thoroughly that I feel compelled to reject it.
Four things that stick in my mind in no particular order in relation to this realisation:
1. Peter Gutmann's out of the blue attack on ACME when it was relatively young. Gutmann's SCEP doesn't solve the problem, and at first my assumption was that he just needed to have that explained. After a while I realised that SCEP's success depends up not understanding what the real problem is, and SCEP is widely deployed outside the Web PKI largely _because_ choosing not to understand the problem suits those applications perfectly well. ACME can't displace SCEP in such applications but its existence might cause people to ask uncomfortable questions and perhaps Peter would (unconsciously?) rather that didn't happen.
2. Eric Rescorla's explanation of what a great environment HTTP (and particularly web browsers) is for a cryptographic adversary. In the literature imaginary bad guys often get to watch one party do a million message/reply back and forths, time them accurately and then send a million bytes of nonsense data to the target as setup for their attack, and in many applications this would be ludicrous in practice, the target would obviously react, how could you do cause anyone to send so many messages without attracting notice, let alone time them? So the attacks seem just theoretical. But on the web you can just write some Javascript and victims will happily run it for you on their computers.
3. Dean Coclin of Symantec and eventually the various banks/ payment providers etcetera that had hidden behind Symantec explaining that such institutions really _needed_ security, unlike mere cat blogs and search engines, but of course they couldn't be expected to react to notice of serious issues with an obsolete hash algorithm in a timely fashion, and so surely they ought to get an extra year or five to upgrade from SHA-1, and if they didn't there'd be dire consequences.
4. ETSI's work on the "Middlebox Security Protocol" aka ETSI TS 103 523. Obviously most of this happens out of view, so we have no idea if there's something productive being discussed - but they kindly (?) shared their work in progress documents with outsiders including the TLS Working Group and er... yuck. I mean... see for yourself:
https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts
IMHO they should have gone with J-PAKE (https://en.wikipedia.org/wiki/Password_Authenticated_Key_Exc...) which is one of the few PAKE protocols that is not patent encumbered and decently peer-reviewed. In fact, that's why Thread (https://www.threadgroup.org/) selected J-PAKE as their authentication protocol.
What about (EC)DHE_PSK, is it also patented? If so, the software patent is fricking insane...
This is highly reminiscent of WPS. The language indicates that they've learned their lesson and focused on making the standard secure, at least in theory. Time will tell how well it's implemented, but history says to be skeptical and disable it for the time being.
WPA2, when properly implemented, is very secure. I'm not sure of WPA3's real purpose. Is strong encryption of wifi signals of any benefit? The days of banking passwords being send in html gets should be behind us. Anything important will be protected by other encryption layers than wifi. Is WPA3 meant to protect unauthorized network access? WPA2 isn't exactly easy to crack. Do we really need a new scheme, and the inevitable new flaws that come with it? Or is this really about streamlining the user experience, about making wifi that little bit less complicated, so that people can attached their smart toasters to the home network without having to actually remember the password.
To clarify for those who obviously do not understand the difference between protocol and concept implementation: Errors in the protocol would have been inconsequential if WPS was implemented properly. Had it not been left on 24/7, the temporary use of shorter keys would have been a good thing. It would have allowed home networks to adopt much more complex keys without having to type them into every new device (a big deal on things like printers which didn't have keyboards). WPS could have contributed to greater WPA2 security. But instead the concept was improperly implemented, allowing the inevitable errors discovered in the adopted protocol to be leveraged.
> With Wi-Fi Easy Connect, a network owner chooses one device as the central point of configuration.
https://www.wi-fi.org/discover-wi-fi/wi-fi-easy-connect
Though with WPA2 (personal, at least), isn't it already possible for "any permitted device" to "vouch for new devices" by simply giving those new devices the Wi-Fi password?
https://www.krackattacks.com/
This is really why they went with WPA3, but I've noticed the Wi-Fi Alliance goes to great lengths to avoid any mentions of KRACK. So now, many, like you, are scratching their heads wondering what's the point of WPA3.
Not sure about that since it has a key space of 10,000.
Implementations without a timeout were super-easy to crack while those with a timeout just took time to figure out how long the timeout was and to not exceed it. I have a Netgear wifi bridge that doesn't turn of WPS (even if you click the button) with no timeout and is trivial to get the password out of while another case it took a couple weeks once I determined the timeout.
*of course I only tested on my own devices and never engaged in wifi thievery from my neighbors
Not really:
https://github.com/d33tah/call-for-wpa3/
Nope, WPA2 has a number of security issues. Let me introduce you to the Wi-Fi deauthentication attack [1].
I'm not sure any IoT devices ever used WPS.
Some thoughts on WPA2: https://github.com/d33tah/call-for-wpa3/
It disgusts me to see that in order to improve something that a crapton of people use daily to protect them self, that’s currently broken, you’d have to pay. I didn’t see any mention that individuals can become members on the website of the Wi-Fi Alliance seems to be only businesses can participate.
I’d be alright with some open-source implementation instead.
/rant
"Early 802.11 products suffered from interoperability problems because the Institute of Electrical and Electronics Engineers (IEEE) had no provision for testing equipment for compliance with its standards."
https://en.wikipedia.org/wiki/Wi-Fi_Alliance#History
I'd love to see a system similar to what Wi-Fi is already doing with Easy Connect, where users can scan a public key embedded in a QR Code or NFC tag to securely connect to a Wi-Fi network. (Or does Easy Connect already allow that? It'd be great if it does.)
see also: 3GPP.
Is that their term for PAKE?
Also I hope they have finally included an actual error message for incorrect passwords, rather than just "connection failed" which is the best that seems to be possible at the moment.