Subject: [eap] More details on issue 40

From: [email-masked] (Mohan Parthasarathy)
Date: Wed, 30 Oct 2002 13:49:46 -0800

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2805E.43148E44
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
>=20
> On Wed, Oct 30, 2002 at 10:47:55AM -0800, Bernard Aboba wrote:
> > If there is mutual authentication within the tunnel, then=20
> the real NAS=20
> > knows the identity of the attacker. It can then make a=20
> decision about=20
> > whether to allow the tunneled authentication method or not.
> >=20
> > L2TP is a good example. This protocol was designed to allow=20
> tunneling=20
> > of PPP authentication. However, this is not a "man in the middle"=20
> > attack because the two ends of the L2TP tunnel are=20
> authenticated using=20
> > IPsec. If the L2TP server doesn't want to accept PPP=20
> authentications=20
> > from a given L2TP client, it can choose not to.
>=20
> That scenario would be safe because there seem to be an=20
> assumption that the identity used for IPsec and the identity=20
> used for PPP are tied at the same authentication server.  But=20
> I'm not sure the assumption should always hold for all=20
> possible multi-method authentication scenarios.  In general,=20
> different authentication methods=20
> in a single authentication conversation may use different identities=20
> that are authenticated at different authentication servers and=20
> a different kind of MiTM attack is possible, I think.
>=20
I am not sure which particular case is problematic here :

1) Tunneled authentication method using a different identity
   going to the same authentication server.
2) Tunneled authentication method using a different identity
   going to a different authentication server.

In case (1), I think we need the ability to restrict what identities
can be used on a secure channel that was established using some
identity. It looks like it is possible to do it in L2TP case as
Bernard explained.

In case (2), you still need to mutually authenticate with the new
AS. Am I missing something ?

-mohan

> Yoshihiro Ohba
>=20
>=20
> >=20
> > _______________________________________________
> > eap mailing list
> > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
> >=20
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>=20

------_=_NextPart_001_01C2805E.43148E44
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>&nbsp;</FONT>

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

<BR><FONT SIZE=3D2>&gt; On Wed, Oct 30, 2002 at 10:47:55AM -0800, =
Bernard Aboba wrote:</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; If there is mutual authentication within =
the tunnel, then </FONT>

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

<BR><FONT SIZE=3D2>&gt; &gt; knows the identity of the attacker. It can =
then make a </FONT>

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

<BR><FONT SIZE=3D2>&gt; &gt; whether to allow the tunneled =
authentication method or not.</FONT>

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

<BR><FONT SIZE=3D2>&gt; &gt; L2TP is a good example. This protocol was =
designed to allow </FONT>

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

<BR><FONT SIZE=3D2>&gt; &gt; of PPP authentication. However, this is not =
a &quot;man in the middle&quot; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; attack because the two ends of the L2TP =
tunnel are </FONT>

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

<BR><FONT SIZE=3D2>&gt; &gt; IPsec. If the L2TP server doesn't want to =
accept PPP </FONT>

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

<BR><FONT SIZE=3D2>&gt; &gt; from a given L2TP client, it can choose not =
to.</FONT>

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

<BR><FONT SIZE=3D2>&gt; That scenario would be safe because there seem =
to be an </FONT>

<BR><FONT SIZE=3D2>&gt; assumption that the identity used for IPsec and =
the identity </FONT>

<BR><FONT SIZE=3D2>&gt; used for PPP are tied at the same authentication =
server.&nbsp; But </FONT>

<BR><FONT SIZE=3D2>&gt; I'm not sure the assumption should always hold =
for all </FONT>

<BR><FONT SIZE=3D2>&gt; possible multi-method authentication =
scenarios.&nbsp; In general, </FONT>

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

<BR><FONT SIZE=3D2>&gt; in a single authentication conversation may use =
different identities </FONT>

<BR><FONT SIZE=3D2>&gt; that are authenticated at different =
authentication servers and </FONT>

<BR><FONT SIZE=3D2>&gt; a different kind of MiTM attack is possible, I =
think.</FONT>

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

<BR><FONT SIZE=3D2>I am not sure which particular case is problematic =
here :</FONT>
</P>

<P><FONT SIZE=3D2>1) Tunneled authentication method using a different =
identity</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; going to the same authentication =
server.</FONT>

<BR><FONT SIZE=3D2>2) Tunneled authentication method using a different =
identity</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp; going to a different authentication =
server.</FONT>
</P>

<P><FONT SIZE=3D2>In case (1), I think we need the ability to restrict =
what identities</FONT>

<BR><FONT SIZE=3D2>can be used on a secure channel that was established =
using some</FONT>

<BR><FONT SIZE=3D2>identity. It looks like it is possible to do it in =
L2TP case as</FONT>

<BR><FONT SIZE=3D2>Bernard explained.</FONT>
</P>

<P><FONT SIZE=3D2>In case (2), you still need to mutually authenticate =
with the new</FONT>

<BR><FONT SIZE=3D2>AS. Am I missing something ?</FONT>
</P>

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

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

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

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

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

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

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

<BR><FONT SIZE=3D2>&gt; &gt; [email-masked] <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; &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_01C2805E.43148E44--

---

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

> identity. It looks like it is possible to do it in L2TP case as

Yes.

> AS. Am I missing something ?

In this case, _either_ inner and outer authentication methods need to
be cryptographically bound _or_ the inner and outer identities need to
be statically tied, regardless of whether mutual authentication is 
performed with the new AS.