Subject: [eap] More details on issue 40

From: [email-masked] (Mohan Parthasarathy)
Date: Wed, 30 Oct 2002 10:24:01 -0800

This is a multi-part message in MIME format.

------_=_NextPart_001_01C28041.85631FCF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The paper by N. Asokan et. al. "Man-in-the-middle in Tunneled
Authentication", section 3,
states the following as one of the reasons as to why this attack is
possible :

1. The legacy client authentication protocol is used in other
environments, e.g., plain
   EAP without any tunnelling, or without any encapsulation at all,
e.g., direct use of
   one-time passwords, or cellular authentication protocols.

   The current IETF drafts do not provide any means for the inner
protocol to verify if it
   is used with tunnelling or not. In the drafts it is considered as a
major benefit of the
   protection protocols that no changes are required in the legacy
protocols to be tunnelled.

And I did not see such a clear statement (may be I missed it) in the
draft that was sent
out earlier.  If you read section 3 of the draft, it talks about
"inducing" the client
to authenticate using one of the methods permitted in the tunnel i.e if
the MiTM used TLS, it
expects the client to use EAP. From this can we conclude, that the
attack is possible mainly
because we still have clients that just use plain EAP etc. ?

One more basic question regarding the draft. In the third step, the
client connects to
the rogue NAS or AP and the attacker tunnels the authentications method
between the client
and server. Isn't there a shared secret (which is pre-configured and
different from
the tunnel keys established in step 1) between NAS and the back-end AS
that protects
all the messages between NAS and AS ? 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

thanks
-mohan

>=20
> > BTW, I would like to make sure that the problem is=20
> essentially due to=20
> > combining multiple authentication methods without cryptographically=20
> > co-relating them, not due to lack of mutual authentication=20
> in some of=20
> > the methods.
>=20
> We have set aside some time in the second session at IETF 55=20
> to discuss the problem and potential solution approaches in=20
> more detail. If anyone would like to make a presentation on=20
> the subject, send mail to myself and Jari.
>=20
> The attack can still be perpetrated even if the methods that=20
> are tunneled support mutual authentication. This is because=20
> the ends that are authenticated are the client and server,=20
> but the man-in-the-middle still obtains the keys from the=20
> tunnel authentication which is only one-way. The=20
> man-in-the-middle cannot necessarily decrypt the traffic sent=20
> by the real client, but this is not necessary since the=20
> attacker is already authenticated to the network and in=20
> possession of the keys required to authentication and/or=20
> encrypt data traffic. Thus the client has served its purpose=20
> and the attacker can drop traffic arriving from it.
> =20
> Note that some of the proposed solutions (e.g. compound MAC=20
> and/or compound keys) require that the tunneled methods=20
> generate keys. Thus these solutions do not apply to methods=20
> such as EAP MD5, OTP or GTC. Since these methods are well=20
> established, it does not seem practical to modify them so as=20
> to incorporate previously derived keys either.
>=20
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>=20

------_=_NextPart_001_01C28041.85631FCF
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 -->

<P><FONT SIZE=3D2>The paper by N. Asokan et. al. &quot;Man-in-the-middle =
in Tunneled Authentication&quot;, section 3,</FONT>

<BR><FONT SIZE=3D2>states the following as one of the reasons as to why =
this attack is possible :</FONT>
</P>

<P><FONT SIZE=3D2>1. The legacy client authentication protocol is used =
in other environments, e.g., plain</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; EAP without any tunnelling, or without =
any encapsulation at all, e.g., direct use of</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; one-time passwords, or cellular =
authentication protocols.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The current IETF drafts do not provide =
any means for the inner protocol to verify if it</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; is used with tunnelling or not. In the =
drafts it is considered as a major benefit of the</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; protection protocols that no changes are =
required in the legacy protocols to be tunnelled.</FONT>
</P>

<P><FONT SIZE=3D2>And I did not see such a clear statement (may be I =
missed it) in the draft that was sent</FONT>

<BR><FONT SIZE=3D2>out earlier.&nbsp; If you read section 3 of the =
draft, it talks about &quot;inducing&quot; the client</FONT>

<BR><FONT SIZE=3D2>to authenticate using one of the methods permitted in =
the tunnel i.e if the MiTM used TLS, it</FONT>

<BR><FONT SIZE=3D2>expects the client to use EAP. From this can we =
conclude, that the attack is possible mainly</FONT>

<BR><FONT SIZE=3D2>because we still have clients that just use plain EAP =
etc. ?</FONT>
</P>

<P><FONT SIZE=3D2>One more basic question regarding the draft. In the =
third step, the client connects to</FONT>

<BR><FONT SIZE=3D2>the rogue NAS or AP and the attacker tunnels the =
authentications method between the client</FONT>

<BR><FONT SIZE=3D2>and server. Isn't there a shared secret (which is =
pre-configured and different from</FONT>

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

<BR><FONT SIZE=3D2>all the messages between NAS and AS ? In that case, =
wouldn't the AS would discard the message</FONT>

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

<P><FONT SIZE=3D2>thanks</FONT>

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

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

<BR><FONT SIZE=3D2>&gt; &gt; BTW, I would like to make sure that the =
problem is </FONT>

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

<BR><FONT SIZE=3D2>&gt; &gt; combining multiple authentication methods =
without cryptographically </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; co-relating them, not due to lack of mutual =
authentication </FONT>

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

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

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

<BR><FONT SIZE=3D2>&gt; We have set aside some time in the second =
session at IETF 55 </FONT>

<BR><FONT SIZE=3D2>&gt; to discuss the problem and potential solution =
approaches in </FONT>

<BR><FONT SIZE=3D2>&gt; more detail. If anyone would like to make a =
presentation on </FONT>

<BR><FONT SIZE=3D2>&gt; the subject, send mail to myself and =
Jari.</FONT>

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

<BR><FONT SIZE=3D2>&gt; The attack can still be perpetrated even if the =
methods that </FONT>

<BR><FONT SIZE=3D2>&gt; are tunneled support mutual authentication. This =
is because </FONT>

<BR><FONT SIZE=3D2>&gt; the ends that are authenticated are the client =
and server, </FONT>

<BR><FONT SIZE=3D2>&gt; but the man-in-the-middle still obtains the keys =
from the </FONT>

<BR><FONT SIZE=3D2>&gt; tunnel authentication which is only one-way. The =
</FONT>

<BR><FONT SIZE=3D2>&gt; man-in-the-middle cannot necessarily decrypt the =
traffic sent </FONT>

<BR><FONT SIZE=3D2>&gt; by the real client, but this is not necessary =
since the </FONT>

<BR><FONT SIZE=3D2>&gt; attacker is already authenticated to the network =
and in </FONT>

<BR><FONT SIZE=3D2>&gt; possession of the keys required to =
authentication and/or </FONT>

<BR><FONT SIZE=3D2>&gt; encrypt data traffic. Thus the client has served =
its purpose </FONT>

<BR><FONT SIZE=3D2>&gt; and the attacker can drop traffic arriving from =
it.</FONT>

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

<BR><FONT SIZE=3D2>&gt; Note that some of the proposed solutions (e.g. =
compound MAC </FONT>

<BR><FONT SIZE=3D2>&gt; and/or compound keys) require that the tunneled =
methods </FONT>

<BR><FONT SIZE=3D2>&gt; generate keys. Thus these solutions do not apply =
to methods </FONT>

<BR><FONT SIZE=3D2>&gt; such as EAP MD5, OTP or GTC. Since these methods =
are well </FONT>

<BR><FONT SIZE=3D2>&gt; established, it does not seem practical to =
modify them so as </FONT>

<BR><FONT SIZE=3D2>&gt; to incorporate previously derived keys =
either.</FONT>

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

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

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

<BR><FONT SIZE=3D2>&gt; [email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://mail.frascone.com/mailman/listinfo/eap">http://mail.frasco=
ne.com/mailman/listinfo/eap</A></FONT>

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

</BODY>
</HTML>
------_=_NextPart_001_01C28041.85631FCF--

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 30 Oct 2002 09:57:11 -0800 (PST)

> attack is possible mainly because we still have clients that just use
> plain EAP etc. ?

The attack can be perpetrated even against clients that don't support EAP
at all. For example, if a client support CHAP (as most PPP implementations
do) but not EAP, then if the server allows EAP-MD5 inside the tunnel,
then the attacker can bring up a tunnel, get the EAP-MD5 challenge, and
get the client to respond to it with a CHAP-Response.

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

> client connects to the rogue NAS or AP and the attacker tunnels the
> authentications method between the client and server. Isn't there a
> shared secret (which is pre-configured and different from
> that protects all the messages between NAS and AS ?

There is a shared secret protecting messages sent between the *real* NAS
and the AS. However, no shared secret or other mutual authentication is
needed between the attacker and the real NAS -- the tunnel authentication
is only one-way. In effect, by inventing EAP tunneling methods that only
require one-way authenticated tunnel setup, we have created a AAA protocol
without support for mutual authentication. This is what enables the
vulnerability.

> In that case, wouldn't the AS would discard the message
> as it is coming from a rogue NAS. Why isn't this happening ?

Because the rogue NAS is talking to the real NAS/AP, not the AAA server.
The real NAS is taking the EAP messages it receives and tunneling them within
AAA, and applying the required mutual authentication, so that the messages
look just fine to the AAA server.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 30 Oct 2002 14:17:15 -0500

> without support for mutual authentication. This is what enables the

That is not the actual enabler of the vulnerability, IMO.  Even if EAP
tunneling methods require mutual authenticated tunnel setup, the
attack is still possible if there is no cryptographic binding between
outer and inner authentication methods.  If that is true, combining
multiple authentication methods in a single authentication
conversation without cryptographically binding would be the actual
enabler of the vulnerability.  On the other hand, one-way
authentication would make it worse.

Yoshihiro Ohba

---

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

> authentication would make it worse.

If there is mutual authentication within the tunnel, then the real NAS
knows the identity of the attacker. It can then make a decision about
whether to allow the tunneled authentication method or not.

L2TP is a good example. This protocol was designed to allow tunneling of
PPP authentication. However, this is not a "man in the middle" attack
because the two ends of the L2TP tunnel are authenticated using IPsec. If
the L2TP server doesn't want to accept PPP authentications from a given
L2TP client, it can choose not to.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 30 Oct 2002 15:06:27 -0500

> L2TP client, it can choose not to.

That scenario would be safe because there seem to be an assumption
that the identity used for IPsec and the identity used for PPP are
tied at the same authentication server.  But I'm not sure the
assumption should always hold for all possible multi-method
authentication scenarios.  In general, different authentication methods 
in a single authentication conversation may use different identities 
that are authenticated at different authentication servers and 
a different kind of MiTM attack is possible, I think.

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 30 Oct 2002 11:39:12 -0800 (PST)

> tied at the same authentication server.

The L2TP server typically evaluates the IKE credentials, such
as certificates; the AAA server handles the validation of the PPP
credentials. So the authentications are typically *not* evaluated at the
same place.

However, based on the certificate mutual authentication, the L2TP server
can decide what PPP userIDs it will allow for a given L2TP client
identity. The L2TP client identity is a machineID and the
PPP clientID is a userID, so this provides the ability for the L2TP
server to decide which users can access the network from which machines.

Now, the L2TP server could recognize a particular L2TP client as a NAS
doing "compulsory tunneling" and decide to allow *any* PPP user to
authenticate to it via the L2TP client. That's the "attack" we're
discussing -- except that the "attacker" (L2TP client) has
identified itself and been granted the permission to tunnel
authentications from other users.

On the other hand, if the L2TP server recognizes a particular L2TP
client as just an ordinary VPN client (machine bernarda.bigco.com), then
it might decide only to forward PPP authentications for user
"[email-masked]" to the AAA server, and not any other user.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 30 Oct 2002 16:58:54 -0500

> credentials. So the authentications are typically *not* evaluated at the

OK, the assumption would be that the identity used for IKE and the
identity used for PPP are statically tied.

> authentications from other users.

Exactly.  The "attack" might be a _weaker_ MiTM attack in the sense that 
the attacker needs to have at least credentials for outer authentication.

> "[email-masked]" to the AAA server, and not any other user.

Yes.

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 30 Oct 2002 17:30:56 -0800 (PST)

> the attacker needs to have at least credentials for outer authentication.

Specifically, if the "attacker" is granted permission by the administrator
to act as an access server itself for specific users. Since this is under
the administrator's control, it seems more like a "feature" than a "bug".

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 30 Oct 2002 23:02:23 -0500

> the administrator's control, it seems more like a "feature" than a "bug".

If that is the feature, then yes, cryptographic binding is not necessary 
for that specific case.

Yoshihiro Ohba