Subject: [eap] More details on issue 40

From: [email-masked] (Mohan Parthasarathy)
Date: Wed, 30 Oct 2002 11:33:21 -0800

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2804B.347863EA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bernard,

Thanks for the clarification.

>=20
> > expects the client to use EAP. From this can we conclude, that the=20
> > attack is possible mainly because we still have clients=20
> that just use=20
> > plain EAP etc. ?
>=20
> The attack can be perpetrated even against clients that don't=20
> support EAP at all. For example, if a client support CHAP (as=20
> most PPP implementations
> do) but not EAP, then if the server allows EAP-MD5 inside the=20
> tunnel, then the attacker can bring up a tunnel, get the=20
> EAP-MD5 challenge, and get the client to respond to it with a=20
> CHAP-Response.
>=20
Agreed. These attacks will happen as long as clients contiune
to use the untunneled legacy authentication protocols but the backend
server supports tunneled authentication protocols also which can be
used by the attacker. We assume that these clients will continue to
exist for sometime.=20

> In fact, I'd argue that the methods most likely to be used=20
> within tunnels (EAP-MD5/CHAP, SIM, OTP, GTC, SECURID,=20
> EAP-MS-CHAP-v2) are precisely those that are widely deployed=20
> today outside tunnels. After all, a large part of the appeal=20
> of tunnels is as a mechanism for improving the security of=20
> those methods, most of which do not generate keys.
>=20

> > One more basic question regarding the draft. In the third step, the=20
> > client connects to the rogue NAS or AP and the attacker tunnels the=20
> > authentications method between the client and server. Isn't there a=20
> > shared secret (which is pre-configured and different from=20
> the tunnel=20
> > keys established in step 1) between NAS and the back-end AS that=20
> > protects all the messages between NAS and AS ?
>=20
> There is a shared secret protecting messages sent between the=20
> *real* NAS and the AS. However, no shared secret or other=20
> mutual authentication is needed between the attacker and the=20
> real NAS -- the tunnel authentication is only one-way. In=20
> effect, by inventing EAP tunneling methods that only require=20
> one-way authenticated tunnel setup, we have created a AAA=20
> protocol without support for mutual authentication. This is=20
> what enables the vulnerability.
>=20
> > In that case, wouldn't the AS would discard the message
> > as it is coming from a rogue NAS. Why isn't this happening ?
>=20
> Because the rogue NAS is talking to the real NAS/AP, not the=20
> AAA server. The real NAS is taking the EAP messages it=20
> receives and tunneling them within AAA, and applying the=20
> required mutual authentication, so that the messages look=20
> just fine to the AAA server.
>=20
Ok. In Figure (1), not sure what the "tunnel keys" (that extend
from Auth server to NAS) refer to.

-mohan

>=20

------_=_NextPart_001_01C2804B.347863EA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: [eap] More details on issue 40</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Bernard,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for the clarification.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; expects the client to use EAP. From this =
can we conclude, that the </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; attack is possible mainly because we still =
have clients </FONT>

<BR><FONT SIZE=3D2>&gt; that just use </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; plain EAP etc. ?</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; The attack can be perpetrated even against =
clients that don't </FONT>

<BR><FONT SIZE=3D2>&gt; support EAP at all. For example, if a client =
support CHAP (as </FONT>

<BR><FONT SIZE=3D2>&gt; most PPP implementations</FONT>

<BR><FONT SIZE=3D2>&gt; do) but not EAP, then if the server allows =
EAP-MD5 inside the </FONT>

<BR><FONT SIZE=3D2>&gt; tunnel, then the attacker can bring up a tunnel, =
get the </FONT>

<BR><FONT SIZE=3D2>&gt; EAP-MD5 challenge, and get the client to respond =
to it with a </FONT>

<BR><FONT SIZE=3D2>&gt; CHAP-Response.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>Agreed. These attacks will happen as long as clients =
contiune</FONT>

<BR><FONT SIZE=3D2>to use the untunneled legacy authentication protocols =
but the backend</FONT>

<BR><FONT SIZE=3D2>server supports tunneled authentication protocols =
also which can be</FONT>

<BR><FONT SIZE=3D2>used by the attacker. We assume that these clients =
will continue to</FONT>

<BR><FONT SIZE=3D2>exist for sometime. </FONT>
</P>

<P><FONT SIZE=3D2>&gt; In fact, I'd argue that the methods most likely =
to be used </FONT>

<BR><FONT SIZE=3D2>&gt; within tunnels (EAP-MD5/CHAP, SIM, OTP, GTC, =
SECURID, </FONT>

<BR><FONT SIZE=3D2>&gt; EAP-MS-CHAP-v2) are precisely those that are =
widely deployed </FONT>

<BR><FONT SIZE=3D2>&gt; today outside tunnels. After all, a large part =
of the appeal </FONT>

<BR><FONT SIZE=3D2>&gt; of tunnels is as a mechanism for improving the =
security of </FONT>

<BR><FONT SIZE=3D2>&gt; those methods, most of which do not generate =
keys.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; One more basic question regarding the draft. =
In the third step, the </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; client connects to the rogue NAS or AP and =
the attacker tunnels the </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; authentications method between the client =
and server. Isn't there a </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; shared secret (which is pre-configured and =
different from </FONT>

<BR><FONT SIZE=3D2>&gt; the tunnel </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; keys established in step 1) between NAS and =
the back-end AS that </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; protects all the messages between NAS and =
AS ?</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; There is a shared secret protecting messages =
sent between the </FONT>

<BR><FONT SIZE=3D2>&gt; *real* NAS and the AS. However, no shared secret =
or other </FONT>

<BR><FONT SIZE=3D2>&gt; mutual authentication is needed between the =
attacker and the </FONT>

<BR><FONT SIZE=3D2>&gt; real NAS -- the tunnel authentication is only =
one-way. In </FONT>

<BR><FONT SIZE=3D2>&gt; effect, by inventing EAP tunneling methods that =
only require </FONT>

<BR><FONT SIZE=3D2>&gt; one-way authenticated tunnel setup, we have =
created a AAA </FONT>

<BR><FONT SIZE=3D2>&gt; protocol without support for mutual =
authentication. This is </FONT>

<BR><FONT SIZE=3D2>&gt; what enables the vulnerability.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; In that case, wouldn't the AS would discard =
the message</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; as it is coming from a rogue NAS. Why isn't =
this happening ?</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Because the rogue NAS is talking to the real =
NAS/AP, not the </FONT>

<BR><FONT SIZE=3D2>&gt; AAA server. The real NAS is taking the EAP =
messages it </FONT>

<BR><FONT SIZE=3D2>&gt; receives and tunneling them within AAA, and =
applying the </FONT>

<BR><FONT SIZE=3D2>&gt; required mutual authentication, so that the =
messages look </FONT>

<BR><FONT SIZE=3D2>&gt; just fine to the AAA server.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>Ok. In Figure (1), not sure what the &quot;tunnel =
keys&quot; (that extend</FONT>

<BR><FONT SIZE=3D2>from Auth server to NAS) refer to.</FONT>
</P>

<P><FONT SIZE=3D2>-mohan</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2804B.347863EA--

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 30 Oct 2002 10:50:40 -0800 (PST)

> from Auth server to NAS) refer to.

In the case of EAP, those are the keys derived by the EAP tunnel
method (e.g. EAP TTLS, PEAP), used to encrypt/authenticate subsequent data
traffic.