Chris Hessing wrote:
> I apologize if this has been hashed out before, but looking at the list
> archives I couldn't see anywhere it had.
There have been hallway discussions about some of these issues, but
little on this list. EAP-FAST has been published as RFC 4851, and
revisiting it is not currently a charter item.
That being said, some discussion on this list is fine if it doesn't
distract from charter requirements.
> 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?
I have seen no reason for this, other than implementation choice.
Since this choice is part of the current specification, and is deployed,
changing it now will be difficult.
> 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?
The challenge for MS-CHAPv2 is calculated similarly in EAP-TTLS. See
RFC 5281, Section 11.1. This calculation enables implementations to
avoid certain kinds of attacks.
> 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.
That would seem to have been a better design choice, yes.
> 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.
RFC 4851 contains few references to EAP-GTC. The only ones I see are
in section A.2, as examples of failed authentication. It appears that
any changes to EAP-GTC are not part of this specification.
> 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.)
Since changes to EAP-GTC are not part of the published specification,
the behavior you see would best be labeled "vendor extensions".
There is an EAP-FAST GTC draft:
http://tools.ietf.org/html/draft-zhou-emu-fast-gtc-05
It documents the GTC implementation that is tunneled inside of
EAP-FAST. The document addresses the issue of overloading thge EAP-GTC
type (6), for use as EAP-FAST-GTC.
It may be best for implementations to treat EAP-FAST-GTC as an EAP
type that is completely independent of EAP-GTC. This may mean "hacks"
like internally mapping EAP type 6 inside of EAP-FAST to a different,
vendor-defined extended type.
This has the problem that it allocates one vendor type to
EAP-FAST-GTC, but it has the benefit that it does not require
modifications to the base EAP-GTC protoool.
> 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.
Do you have feedback on the EAP-FAST-GTC draft? Comments directly to
the author would seem appropriate.
> 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.
That is a problem with anonymous provisioning.
> 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.
Something similar can happen with EAP-TTLS / PAP, if the supplicant
does not validate the server certificate.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
