Subject: [Emu] Potential Issues with EAP-FAST

From: Chris Hessing <[email-masked]>
Date: Fri, 23 Jan 2009 15:57:03 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Josh Howlett" <[email-masked]>
Date: Sat, 24 Jan 2009 15:37:42 -0000

Chris,
 
> What is the advantage of seeding MS-CHAPv2 with data from the 
> outer tunnel?

I'm not at all familiar with EAP-FAST but I expect this is intended to
establish a cryptographic binding between EAP-MSCHAPv2 and the outer
tunnel, per section 7.2.1 of RFC 3748.

See also RFC5247 & RFC5056 for fuller discussions of the subject.

HTH, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: Alan DeKok <[email-masked]>
Date: Sun, 25 Jan 2009 09:37:35 +0100

> 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.

> 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.

> derivation in MS-CHAPv2 different for FAST than for a non-FAST MS-CHAPv2

  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.

> confusing is why this would happen when the end result is something far

  That would seem to have been a better design choice, yes.

> 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.

> 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.

> like that make it difficult to develop an implementation that is fully

  Do you have feedback on the EAP-FAST-GTC draft?  Comments directly to
the author would seem appropriate.

> provide the server with its credentials.

  That is a problem with anonymous provisioning.

> provisioning and the clear text credentials are handed over to the

  Something similar can happen with EAP-TTLS / PAP, if the supplicant
does not validate the server certificate.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 25 Jan 2009 15:04:08 -0800 (PST)

Hi Alan,

> distract from charter requirements.

  A tunnel method is definitely in our charter and we have had much
discussion on what that would look like. If you re-read the notes from
IETF 71 there was a long discussion about choosing an existing one to
update and not necessarily rolling a new one from scratch. The candidates
sure seem to be TTLS and FAST, given the presentations on them we've had.

  So I think a discussion about issues with either one of the potential
candidates is valuable and can help the WG in our choice.

  regards,

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Jan 2009 11:38:31 +0100

> sure seem to be TTLS and FAST, given the presentations on them we've had.

  Discussing the applicability, cost, benefit, etc. of EAP-FAST is a
good idea.  Re-visiting its architectural choices isn't something we
have time for.

  Alan DeKok.

---

From: <[email-masked]>
Date: Mon, 26 Jan 2009 11:41:47 +0100

Chris Hessing wrote:

> 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?

This is something where TLS itself uses both orderings: when
calculating the master secret from the pre-master secret, client
random is first; when calculating the key block from master secret,
server random is first. (I have no idea why, but it's been this way
since the -00 draft from 1996.)

Since EAP-FAST's "session_key_seed" comes from the end of the key
block, it does not change the order (so server random is first,
like in TLS).

Best regards,
Pasi

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 26 Jan 2009 12:24:51 -0800 (PST)

Hi Alan,

  Once this group gets around to selecting a protocol for advancement
is it your view that we just have a coronation followed immediately
by publication or do we actually get to update the selected protocol
to meet our needs? If the former, then yes, we don't have the time. If
the latter, then understanding architectural issues with a protocol
that may impact any updating the WG decides is necessary can only be
A Good Thing (tm).

  It is certainly my understanding that the WG would update the selected
protocol (please correct me if I'm wrong!). Therefore *discussing* the
architectural choices a protocol made is something we certainly should
not discourage as it will guide our choice and, possibly, prepare us for
work ahead.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Jan 2009 21:48:33 +0100

Dan Harkins wrote:
> to meet our needs?

  Portions of any protocol will likely need to be updated.  The tunnel
requirements draft lists a number of issues that have to be addressed in
any protocol before it is accepted as the agreed-upon method.

  Any *other* changes unrelated to security and/or the tunnel
requirements are out of scope.

> not discourage as it will guide our choice and, possibly, prepare us for

  Some issues are less important.  e.g. The TLS PRF being dependent on
(client + server), or (server + client) random.  Unless there are
security issues related to a particular choice of order, the use of one
order or another shouldn't be factor in choosing a tunneled EAP method.

  Alan DeKok.

---

From: Chris Hessing <[email-masked]>
Date: Mon, 26 Jan 2009 14:53:02 -0700

> requirements are out of scope.
Then I must ask a stupid question.  Who is the group that decides what 
should and shouldn't be allowed?  While I understand that the changes 
EAP-FAST makes to existing EAP methods are already published and have 
many implementations, it seems that allowing future EAP methods to make 
random changes is something that will ultimately lead to 
interoperability problems.  It is just a bad precedent to allow to 
continue. I would be happy to raise this issue on a different list if 
there is one more appropriate.  But where this is an EAP related issue 
this seemed to be the right list.

As for security, I think the majority of the Internet community expects 
all of the standards setting bodies to put good security high on their 
list of things to care about.  While the comment that EAP-TTLS can be 
just as dangerous in letting credentials out, there is one major 
difference from my point of view.  No where that I have seen in the 
EAP-TTLS specifications did I ever see any hint that the supplicant 
could (or should) operate in a mode where the certificate isn't 
verified.  For EAP-FAST provisioning anonymous provisioning is clearly 
spelled out as a possible mode of operation.  By allowing things to be 
published like that without anyone calling attention to the related 
security issues seems like a bad idea.  Further it bothers me more when 
I see a NIST document that indicates that EAP-FAST is the best choice 
for a secure, but easy to deploy, EAP method.
> order or another shouldn't be factor in choosing a tunneled EAP method.

I agree.  It was not my intention to claim that all issues were of equal 
importance.  There are obviously cases where decisions were made and 
released to the wild.  My goal by listing all of the issues I did was to 
attempt to start a conversation and allow the important issues to rise 
to the top.  Ultimately I want to see the use of EAP continue to be 
successful, but also to be secure.  I figured I either had to put the 
issues (as I see them) out there and try to be part of the solution, or 
ignore them and just hope it works out.   I would prefer to be part of 
the solution where possible.

However, again, if I am trying to get this discussion going in the wrong 
forum, please point me to a better one.
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Stefan Winter <[email-masked]>
Date: Tue, 27 Jan 2009 07:57:58 +0100

Hi,

> As for security, I think the majority of the Internet community
> expects all of the standards setting bodies to put good security high
> on their list of things to care about.  While the comment that
> EAP-TTLS can be just as dangerous in letting credentials out, there is
> one major difference from my point of view.  No where that I have seen
> in the EAP-TTLS specifications did I ever see any hint that the
> supplicant could (or should) operate in a mode where the certificate
> isn't verified.  For EAP-FAST provisioning anonymous provisioning is
> clearly spelled out as a possible mode of operation.  By allowing
> things to be published like that without anyone calling attention to
> the related security issues seems like a bad idea.  Further it bothers
> me more when I see a NIST document that indicates that EAP-FAST is the
> best choice for a secure, but easy to deploy, EAP method.

I agree with Chris here. There is a substantial difference between TTLS
and FAST. In TTLS, the server will present a certificate and the user
*can* verify his EAP peer unambiguously (whether or not he actually does
that is another question). With FAST, and Chris' description of the
possibility of sniffing and faking A-IDs etc., the user *can not* verify
that his EAP peer is genuine. This is a qualitative difference, and I am
very much against ignoring it. With Chris' claims I can not, for
example, suggest eduroam participants to use EAP-FAST for their mutual
authentication needs.

> I agree.  It was not my intention to claim that all issues were of
> equal importance.  There are obviously cases where decisions were made
> and released to the wild.  My goal by listing all of the issues I did
> was to attempt to start a conversation and allow the important issues
> to rise to the top.  Ultimately I want to see the use of EAP continue
> to be successful, but also to be secure.  I figured I either had to
> put the issues (as I see them) out there and try to be part of the
> solution, or ignore them and just hope it works out.   I would prefer
> to be part of the solution where possible.

My top list definitely has "problems in genuinely identifying the EAP
peer" as a major bullet point.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Jan 2009 08:47:09 +0100

Chris Hessing wrote:
> should and shouldn't be allowed?

  The chairs determine the focus of the group, guided by the WG charter.

>  While I understand that the changes

  While this is the currently the only EAP WG in the IETF (IIRC), it has
a charter that specifies WG work items.  Re-visiting EAP-FAST is not a
work item.

  That being said, a discussion of EAP related issues *is* welcome on
this list, so long as it does not distract from work items.  In relation
to EAP-FAST, the RFC was not a WG work item (from any WG).  It did not
follow the normal WG review process, and may have issues caught by
additional reviewers.

>...  For EAP-FAST provisioning anonymous provisioning is clearly
> spelled out as a possible mode of operation. 

  i.e. A "possible" mode of operation.  Provisioning is not part of the
scope of this WG (see the charter).  If EAP-FAST is chosen as the
tunneled method, it would be appropriate to forbid anonymous
provisioning in the EMU document describing the tunneled method.

>  Further it bothers me more when

  Do the NIST documents permit anonymous provisioning?

> forum, please point me to a better one.

  Discussions as to how EAP-FAST meets (or does not) the tunneled method
requirements are needed on this list.  However, discussions of the
tunneled method requirements document are a higher priority right now,
because that document is unfinished.

  Alan DeKok.

---

From: Katrin Höper <[email-masked]>
Date: Tue, 27 Jan 2009 08:28:09 -0600

>Alan DeKok replied:
[KH]: No.
But I'll check whether the draft needs further clarifications in that
regard.
btw everybody is welcome to submit comments to
[email-masked]<[email-masked]?Subject=Comments%20SP%20800-120>with
"Comments on SP 800-120" in the subject line. The comment period
closes
on January 30, 2009. The draft can be accessed at:
http://csrc.nist.gov/publications/PubsDrafts.html.

Katrin Hoeper

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 27 Jan 2009 08:56:27 -0800

[KH]: No. 

Unfortunately w/o anonymous provisioning the "easy to deploy" part kind of
goes out the window…

btw everybody is welcome to submit comments to [email-masked]
<mailto:[email-masked]?Subject=Comments%20SP%20800-120>  with
"Comments on SP 800-120" in the subject line. The comment period closes on
January 30, 2009. The draft can be accessed at:
http://csrc.nist.gov/publications/PubsDrafts.html.

Katrin Hoeper

---

From: Katrin Höper <[email-masked]>
Date: Tue, 27 Jan 2009 11:12:42 -0600

> Unfortunately w/o anonymous provisioning the "easy to deploy" part kind of
The NIST draft never claimed that EAP-FAST is easy to deploy, neither does
it say it is the best choice.....That was a misquotation of the draft.

Katrin Hoeper

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 27 Jan 2009 18:00:58 -0800

Hi,

This is certainly an interesting thread and one I have a deep interest
in :-) I understand that we are still solidifying the method
requirements for this group so it is timely to be raising and discussing
requirements. 

I also agree with Alan that we can discuss how EAP-FAST meets (or does
not) the requirements, though, without having an agreed upon
requirements document, the discussion seems premature.  I greatly
appreciate the discussion on EAP-FAST thus far and welcome the continued
feedback directly to me (or my co-authors) as I understand the use of
EAP-FAST in provisioning mode is not in this group's scope and charter;
especially if you find issues with the current documents and in
particular, discrepancies between specifications and implementation.

	Nancy. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alan DeKok
Sent: Monday, January 26, 2009 11:47 PM
To: Chris Hessing
Cc: [email-masked]
Subject: Re: [Emu] Potential Issues with EAP-FAST

> many implementations, it seems that allowing future EAP methods to 
> make random changes is something that will ultimately lead to 

> However, again, if I am trying to get this discussion going in the 
> wrong forum, please point me to a better one.

  Alan DeKok.