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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
pasi.ero...@nokia.com
Sent: Tuesday, February 03, 2009 3:54 AM
To: ch...@open1x.org; emu@ietf.org
Subject: Re: [Emu] Potential Issues with EAP-FAST
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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
