All -
I apologize if this has been hashed out before, but looking at the list
archives I couldn't see anywhere it had.
There seems to be an increasing push for people to deploy EAP-FAST.
But, as someone that has implemented EAP-FAST I am concerned about some
of the significant differences between FAST and other tunneled EAP
methods. In addition to that, it seems there is a massive security hole
in anonymous provisioning.
My concerns are as follows :
1. EAP-FAST feeds the client and server random in to the TLS PRF in the
opposite order that TTLS and PEAP do. I can't think of a good reason to
do this. Is there some security advantage to doing this? If not, why
require implementations to handle this case for no real gain?
2. EAP-FAST modifies the documented behavior of both MS-CHAPv2 and
GTC. For MS-CHAPv2 again it is unclear why the changes are needed.
What is the advantage of seeding MS-CHAPv2 with data from the outer
tunnel? It doesn't seem to add any additional security or value, but
does complicate the implementation for MS-CHAPv2. Also, why is the key
derivation in MS-CHAPv2 different for FAST than for a non-FAST MS-CHAPv2
authentication?
For GTC, I find the changes even more disturbing. Why overload GTC by
having the both ends of the conversation look in to a field that is
supposed to be a free-form string displayed to the user? Even more
confusing is why this would happen when the end result is something far
more suited to a TLV.
It seems like a bad precedent to set to allow an EAP method from one
organization to overload the behavior of an EAP method of another
organization. The end result is more complicated implementations, and
more user confusion when things go wrong due to minor differences
between different implementations.
3. During my implementation, I discovered some behaviors that are not
documented in the relevant drafts. To make it clear, I am making the
assumption that the software provided by the vendor backing the draft
would be the de-facto correct implementation. When working against
Ciscos ACS server I found that a username/password failure when using
GTC results in a new GTC challenge that contains a string that is in the
form of an MS-CHAPv2 failure message. Behavior like this further
overloads EAP-GTC in ways that provide little useful benefit. (To be
fair, I like EAP methods that give some sort of reason for the failure,
but overloading a free-form user displayable string in this way seems bad.)
4. Item #3 above was one of a few different places that I found
implementations that didn't match what the documentation said. Things
like that make it difficult to develop an implementation that is fully
compatible.
For anonymous provisioning, it also seems there is a pretty large
security hole. It is smaller than the security issues with LEAP, but is
still rather large.
With anonymous provisioning the supplicant has to implicitly trust the
authentication server it is talking to. The only piece of information
the supplicant has that it can use to attempt to verify the server is
the A-ID that is provided. But, in a provisioning mode the supplicant
doesn't really have a way to verify that the A-ID is valid. As a
result, the supplicant will continue on with the provisioning and
provide the server with its credentials.
In the best case scenario, the supplicant is configured to only allow
the user of MS-CHAPv2 for provisioning, so "all" the bad guy gets is the
resulting MS-CHAPv2 hash which can then be attacked directly and
off-line. In the worst case the supplicant allows GTC to be used for
provisioning and the clear text credentials are handed over to the attacker.
You could mitigate this to some extent by provisioning the supplicant in
advance with the A-IDs provided by the authentication servers. But,
since that value is sent in the clear an attacker would just need to be
patient enough for someone to provision a connection, and then they
would be able to pretend to be the authentication server.
However, if the A-ID isn't preconfigured in the supplicant, the problem
gets potentially worse. It is unclear how the supplicant is supposed to
know that it is "safe" to provision a new PAC. It seems that the answer
is that the server decides when to provision a new PAC, and does it
inside the authenticated tunnel during a reauthentication. However,
there are two issues with this method. If a user doesn't connect to the
network during the reprovisioning time, they will have to do a full
reprovision, which effectively brings us back to the scenario outlined
above. The other issue is it is unclear how to tell that you need to
reprovision a PAC versus an attacker trying to force you to
reprovision. An attacker could grab the A-ID out of the air, and force
a client to associate to them. By providing a valid A-ID, they can get
around preconfigured A-IDs in the supplicant. By providing an invalid
set of PAC data to the supplicant, the supplicant will likely believe
that it needs to reprovision. So reprovisioning inside a tunnel isn't
an effective way to protect the process. When I asked (off-list) for
clarification on what circumstances indicate you should reprovision
versus someone messing with the data, I didn't get an answer.
Of course, if you don't preconfigure an A-ID, then the attacker could
simply make one up, and execute the attack. The way you might mitigate
that is to pop up a dialog telling the user that a new A-ID was
presented and ask if they want to accept it. But, this really isn't
more secure as users will accept it because their desire to gain network
access will always trump ITs desire for security.
To keep everything on the up and up, I have not actually written a proof
of concept attack for this. It is based solely on observations while
implementing EAP-FAST support. However, assuming I am not missing some
critical detail, this attack would be easy to implement and could be
done with inexpensive hardware from any old big box electronics store.
Please let me know if I am missing something, or completely up-in-the-night.
Thanks!
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
