Subject: Re: [Emu] Potential Issues with EAP-FAST

From: <[email-masked]>
Date: Tue, 3 Feb 2009 12:53:58 +0100

Chris Hessing wrote:

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

The supplicant also verifies the MS-CHAPv2 Success packet, which
contains a MAC -- so there is mutual authentication (some kind of),
and the provisioning exchange won't finish successfully unless the
attacker can spoof this MAC.

The attacker doesn't know the password (and an't compute the MAC
himself), and deriving the challenges from the TLS key block means
the attacker can't just "cut-and-paste" MS-CHAPv2 messages from the
real authentication server.

It's true that the bad guy gets the MS-CHAPv2 response, and can do an
off-line dictionary attack. This is described in Section 6.2, which
also suggests some possible countermeasures (not perfect, but
something).

But if your password is reasonably strong, it seems this can
be reasonably OK (unless I'm missing something here)...

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

The specification doesn't allow using GTC when doing anonymous
provisioning, so the worst case doesn't happen if you follow
the spec.

Best regards,
Pasi
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 3 Feb 2009 14:02:15 -0800

Thank you for the accurate description Pasi!

It is also important to note that there are different modes of EAP-FAST
provisioning, anonymous was provided to appease to customer requirements
for an in-band solution.  To minimize the security risks in the
anonymous mode, additional measures were included to provide some level
of mutual authentication which are described in Section 3.2.3 and its
security risks are further described in Section 6.2.  It is also noted
in Section 3.2.2 that only EAP-MSCHAPv2 is supported in anonymous
provisioning mode. But again, it is one mode that need not be used if
the deployment requires stronger security.

Since there seems to be interest in EAP-FAST, and some confusion in the
different modes provided by the method, I could present an EAP-FAST
tutorial at the next EMU session.

Thanks again, 
	Nancy.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, February 03, 2009 3:54 AM
To: [email-masked]; [email-masked]
Subject: Re: [Emu] Potential Issues with EAP-FAST

Chris Hessing wrote:

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

The supplicant also verifies the MS-CHAPv2 Success packet, which
contains a MAC -- so there is mutual authentication (some kind of), and
the provisioning exchange won't finish successfully unless the attacker
can spoof this MAC.

The attacker doesn't know the password (and an't compute the MAC
himself), and deriving the challenges from the TLS key block means the
attacker can't just "cut-and-paste" MS-CHAPv2 messages from the real
authentication server.

It's true that the bad guy gets the MS-CHAPv2 response, and can do an
off-line dictionary attack. This is described in Section 6.2, which also
suggests some possible countermeasures (not perfect, but something).

But if your password is reasonably strong, it seems this can be
reasonably OK (unless I'm missing something here)...

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

The specification doesn't allow using GTC when doing anonymous
provisioning, so the worst case doesn't happen if you follow the spec.

Best regards,
Pasi

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 6 Feb 2009 16:29:24 +0700

Alan DeKok [mailto:[email-masked]] writes:

> Dan Harkins wrote:
> >   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.
> 
>   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.

In other words, no technical review.  OK, great, how about we just let the
Cisco & Juniper marketing departments slug it out & let us know who wins?  

>   Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 06 Feb 2009 14:08:56 +0100

> Cisco & Juniper marketing departments slug it out & let us know who wins?  

  A technical review of EAP-FAST as it applies to the charter work items
is relevant.  This WG is also a reasonable place to discuss the status
of the current EAP-FAST document.  However, re-designing EAP-FAST is not
 on the charter of this WG.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 8 Feb 2009 08:32:18 +0700

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 8 Feb 2009 09:25:53 +0700

Alan DeKok [mailto:[email-masked]] writes:

> is relevant.  

Thanks for the clarification.  However, it's hard for me to understand how
the architectural choices of EAP-FAST could be irrelevant to the charter
work items.  

> This WG is also a reasonable place to discuss the status

OK, great.  Just out of curiosity, though, would you mind explaining the
criteria upon which these policies are based since EAP-FAST is not
specifically mentioned anywhere in the charter?

---

From: Alan DeKok <[email-masked]>
Date: Sun, 08 Feb 2009 07:44:31 +0100

> the architectural choices of EAP-FAST could be irrelevant to the charter

  They are not irrelevant.  See below.

> specifically mentioned anywhere in the charter?

  The charter requires us to extend an existing TLS-based tunneled
method.  Hence the tunneled requirements draft.

  Both EAP-TTLS and EAP-FAST have been proposed as choices for the
tunneled method.  One or the other may have particular architectural
choices that prevents it from satisfying the tunneled requirements.  In
that case, those architectural choices would be relevant.

  Architectural choices that are "unusual", but which also do not impact
the methods ability to satisfy the tunnel requirements are out of scope
of the charter.  They can be discussed here with respect to the EAP-FAST
documents && the current IESG review, but they should have no impact on
the choice of tunneled method.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 7 Feb 2009 23:00:35 -0800 (PST)

Hi Alan,

> the choice of tunneled method.

  What if some architectural decision(s) make(s) one worse than the other
as a tunneled method of choice, even though _technically_ they both
satisfy the requirements? Are we forbidden from discussing that?

  If it comes down to a beauty contest, we're only allowed to discuss
whether both contestants for Miss EMU are technically female but not
whether one is a gimp hunchback with worts?

  Dan.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 8 Feb 2009 14:26:34 +0700

Alan DeKok [mailto:[email-masked]] writes:

> method.  

I can't see that in the charter.  This is what it says (in part):

- Enable TLS-based EAP methods to support channel bindings. This item
will not generate a new method; rather, it will focus on adding
support for EAP channel bindings to the tunneled method (described
below), and if possible, other TLS-based EAP methods. Potential
mechanisms for adding channel binding support will be investigated,
including tunneling of channel binding parameters, or a TLS extension,
or other standard TLS mechanism

- A mechanism to support extensible communication within a TLS
protected tunnel. This mechanism will support meeting the requirements
of an enhanced TLS mechanism, a password based authentication
mechanism, and additional inner authentication mechanisms. It will
also support channel bindings (as described above) in order to meet
RFC 4962 requirements.

Note that while it does say that the enabling of support for channel
bindings will not generate a new method it says nothing of the sort about
the tunneled method itself,

> Hence the tunneled requirements draft.
> 
> tunneled method.  

Although their promoters have (apparently quite effectively ;-) positioned
the question as a choice between EAP-TTLS & EAP-FAST, I can find nothing in
the charter that actually requires us to take that path.

> One or the other may have particular architectural

---

From: Alan DeKok <[email-masked]>
Date: Sun, 08 Feb 2009 08:43:50 +0100

> satisfy the requirements? Are we forbidden from discussing that?

  No.

> whether one is a gimp hunchback with worts?

  Ease of implementation and deployment is one useful criteria out of many.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 08 Feb 2009 08:47:10 +0100

> the tunneled method itself,

  Yes.

> the charter that actually requires us to take that path.

  We discuss what has been proposed.  If there is another TLS-based EAP
method that should be included in the above list, feel free to propose it.

  Until another method is proposed, and/or a more in-depth review
happens, the TLS-based EAP methods that *may* satisfy the tunnel
requirements are currently TTLS and FAST.

  I encourage people to review the EAP methods against the tunnel
requirements document.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 8 Feb 2009 15:02:14 +0700

> method that should be included in the above list, feel free to propose

This thread is not about what is being discussed or proposed, it's about
what the charter says.

...

---

From: Alan DeKok <[email-masked]>
Date: Sun, 08 Feb 2009 09:42:13 +0100

> This thread is not about what is being discussed or proposed, it's about

  The charter does not require us to choose a particular method.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 9 Feb 2009 11:19:45 +0700

Alan DeKok [mailto:[email-masked]] writes:

> >> method that should be included in the above list, feel free to
> propose
> >> it.
> >

The point is that you stated that the charter "requires us to extend an
existing TLS-based tunneled method" when in fact it does nothing of the
sort.  Either this was just an error that for some reason you refuse to
admit or you and Joe are interpreting the charter to mean that.  Such
interpretation is w/i your purview as WG Chairs but since it is at least
unobvious, a non-null rationale would be appreciated.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 09 Feb 2009 08:30:17 +0100

> unobvious, a non-null rationale would be appreciated.

  You are free to propose *any* TLS-based EAP method that satisfies the
tunneled requirements document.  This includes new methods of your own
invention.

  So far, only TTLS and FAST have been discussed.  In the absence of
additional proposals, we will likely be extending an existing method.

  Alan DeKok.