Subject: [eap] Issue 64: Problem statement issues

From: [email-masked] (Puthenkulam, Jose P)
Date: Mon, 24 Mar 2003 14:36:05 -0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F255.C16FD970
Content-Type: text/plain

Some comments/proposed resolution to this issue marked <jp>..</jp>. 
Issue 64: Problem statement issues
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 8, 2003
Document:
http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt
<http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt> 
Reference: http://mail.frascone.com/pipermail/eap/2002-December/000413.html
<http://mail.frascone.com/pipermail/eap/2002-December/000413.html> 
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

This draft describes aspects of MiTM attacks that can be mounted against
compound EAP methods. At IETF 55, there was consensus that this was a
problem that needed more work. The first step in that direction is to
complete the problem statement. This is the core of what this draft is
trying to do, I think.

However, in reading through it, I think it doesn't do a very good job in
several aspects:

a. Motivation for compound methods. One obvious solution to the problem of
compound method security is to say "don't use compound methods, use strong
simple methods instead." So some justification for the use of compound
methods needs to be included in the draft.
<jp>version 2 draft addresses this in sec 1.2 </jp>

b. Discussing vulnerabilities of EAP method sequences. Are the same
attacks launchable against sequences? In what scenarios? The discussion is
mostly focussed on tunneling.
<jp>
Currently we didn't study sequences in great detail. However the reasons we
did so are the following and hopefully will add some text in the version 3
draft on this
-Sequences are open-ended, unless they follow some well defined method that
describes the order and content of the sequence, it is hard to make them
interoperable and meaningful to study.
-For sequences, there has to be an umbrella method that defines the security
of the sequence in totality, before we can be sure what solutions for mitm
attacks can be provided.
-No well defined sequenced EAP protocol methods are available. (correct me
if I'm wrong here....).
</jp>

c. Discussing the circumstances in which the attack can occur. For
example, can the attack occur when the tunnel authentication is mutual? If
there is no credential reuse? What role can policy play?
<jp>
Plan to add some text on the mutual authenticated tunnel situation. The
attack that is possible in that case is due to a violation of trust by a
trusted man-in-the-middle.
Policy has already been considered in the version 2 draft as a possible
solution. However the bias is towards to automated solutions using
cryptographic binding.
</jp>

d. Discussing the *incremental* vulnerabilities created by compound
methods. This is very important in understand what problems are *created*
by compound methods, and which problems are inherent in the scenarios
being discussed. For example, when dealing with "legacy" methods (e.g.
methods which do one-way auth and don't derive keys) and wired networks
(e.g. PPP and IEEE 802) there is an inherent vulnerability to hijacking.
Therefore the scenario is inherently insecure from the start -- and so the
question is not whether security is present (it isn't) -- but how compound
methods make the situation *worse*.
<jp>
Section 1.2 provides the motivations for compound methods and the reality of
protocol adaptation for new environments due to several reasons. Not sure
whether compound methods make it worse though, because there are trade-offs
which are implementation feature dependent and its difficult to have a
solution that meets all criteria. 
Will add some text in the version 3 update about trade-off between chosing a
single method vs a compound method.
</jp>

e. Discussing the requirements for a solution. What would a "solution" to
the "problem" being defined look like? 
<jp> Hopefully section 3.2 addresses this </jp>
What should we expect from a "solution"? For example, would a solution
prevent offline attacks against
weak tunneled methods? 
<jp> Section 3.1 defines criteria for a solution. However, we do not call
out additional expectations explicitly. The implicit expectation is that the
solution doesn't bring in additional vulnerabilities. However offline
attacks that could be performed by an Mitm need mention and will propose the
following text for it to be added to the solution criteria.
"Man-in-the-middle Offline Attacks
                 The solution should not allow the man-in-the-middle from
being able to perform offline attacks on the weak inner method protocols
used within a tunnel.
"
Would it apply to all EAP methods, or just some
subset? If it only applies to a subset, why does this subset benefit from
tunneling?
<jp>
Section 3.2, 3.3 and 3.6 of the version2 draft partially cover this.  Policy
based solutions apply to all methods. However for key deriving methods,
cryptographic binding is possible. Now from section 1.2 we already explained
why tunnels have been in use and what the resulting benefits are for both
legacy and new methods
</jp>
Is this resolution acceptable?
best regards,
jose

------_=_NextPart_001_01C2F255.C16FD970
Content-Type: text/html
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 =
5.5.2653.12">
<TITLE>[eap] Issue 64: Problem statement issues</TITLE>
</HEAD>
<BODY>

<P><FONT FACE=3D"Times New Roman">Some comments/proposed resolution to =
this issue marked &lt;jp&gt;..&lt;/jp&gt;.<B> </B></FONT>
<BR><B><FONT FACE=3D"Times New Roman">Issue 64: Problem statement =
issues</FONT></B><BR>
<FONT FACE=3D"Times New Roman">Submitter name: Bernard Aboba<BR>
Submitter email address: [email-masked]<BR>
Date first submitted: January 8, 2003<BR>
Document: </FONT><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-bindin=
g-01.txt"><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New =
Roman">http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding=
-01.txt</FONT></U></A><BR>
<FONT FACE=3D"Times New Roman">Reference: </FONT><A =
HREF=3D"http://mail.frascone.com/pipermail/eap/2002-December/000413.html=
"><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New =
Roman">http://mail.frascone.com/pipermail/eap/2002-December/000413.html<=
/FONT></U></A><BR>
<FONT FACE=3D"Times New Roman">Comment type: T<BR>
Priority: S<BR>
Section: Various<BR>
Rationale/Explanation of issue:<BR>
<BR>
This draft describes aspects of MiTM attacks that can be mounted =
against<BR>
compound EAP methods. At IETF 55, there was consensus that this was =
a<BR>
problem that needed more work. The first step in that direction is =
to<BR>
complete the problem statement. This is the core of what this draft =
is<BR>
trying to do, I think.<BR>
<BR>
However, in reading through it, I think it doesn't do a very good job =
in<BR>
several aspects:<BR>
<BR>
a. Motivation for compound methods. One obvious solution to the problem =
of<BR>
compound method security is to say &quot;don't use compound methods, =
use strong<BR>
simple methods instead.&quot; So some justification for the use of =
compound<BR>
methods needs to be included in the draft.</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;jp&gt;version 2 draft addresses =
this in sec 1.2 &lt;/jp&gt;<BR>
<BR>
b. Discussing vulnerabilities of EAP method sequences. Are the same<BR>
attacks launchable against sequences? In what scenarios? The discussion =
is<BR>
mostly focussed on tunneling.</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">Currently we didn't study sequences =
in great detail. However the reasons we did so are the following and =
hopefully will add some text in the version 3 draft on this</FONT></P>

<P><FONT FACE=3D"Times New Roman">-Sequences are open-ended, unless =
they follow some well defined method that describes the order and =
content of the sequence, it is hard to make them interoperable and =
meaningful to study.</FONT></P>

<P><FONT FACE=3D"Times New Roman">-For sequences, there has to be an =
umbrella method that defines the security of the sequence in totality, =
before we can be sure what solutions for mitm attacks can be =
provided.</FONT></P>

<P><FONT FACE=3D"Times New Roman">-No well defined sequenced EAP =
protocol methods are available. (correct me if I'm wrong =
here....).</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;/jp&gt;<BR>
<BR>
c. Discussing the circumstances in which the attack can occur. For<BR>
example, can the attack occur when the tunnel authentication is mutual? =
If<BR>
there is no credential reuse? What role can policy play?</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">Plan to add some text on the mutual =
authenticated tunnel situation. The attack that is possible in that =
case is due to a violation of trust by a trusted =
man-in-the-middle.</FONT></P>

<P><FONT FACE=3D"Times New Roman">Policy has already been considered in =
the version 2 draft as a possible solution. However the bias is towards =
to automated solutions using cryptographic binding.</FONT></P>

<P><FONT FACE=3D"Times New Roman">&lt;/jp&gt;<BR>
<BR>
d. Discussing the *incremental* vulnerabilities created by compound<BR>
methods. This is very important in understand what problems are =
*created*<BR>
by compound methods, and which problems are inherent in the =
scenarios<BR>
being discussed. For example, when dealing with &quot;legacy&quot; =
methods (e.g.<BR>
methods which do one-way auth and don't derive keys) and wired =
networks<BR>
(e.g. PPP and IEEE 802) there is an inherent vulnerability to =
hijacking.<BR>
Therefore the scenario is inherently insecure from the start -- and so =
the<BR>
question is not whether security is present (it isn't) -- but how =
compound<BR>
methods make the situation *worse*.</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">Section 1.2 provides the motivations =
for compound methods and the reality of protocol adaptation for new =
environments due to several reasons. Not sure whether compound methods =
make it worse though, because there are trade-offs which are =
implementation feature dependent and its difficult to have a solution =
that meets all criteria. </FONT></P>

<P><FONT FACE=3D"Times New Roman">Will add some text in the version 3 =
update about trade-off between chosing a single method vs a compound =
method.</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;/jp&gt;<BR>
<BR>
e. Discussing the requirements for a solution. What would a =
&quot;solution&quot; to<BR>
the &quot;problem&quot; being defined look like? </FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;jp&gt; Hopefully section 3.2 =
addresses this &lt;/jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">What should we expect from a =
&quot;solution&quot;? For example, would a solution prevent offline =
attacks against<BR>
weak tunneled methods? </FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;jp&gt; Section 3.1 defines =
criteria for a solution. However, we do not call out additional =
expectations explicitly. The implicit expectation is that the solution =
doesn't bring in additional vulnerabilities. However offline attacks =
that could be performed by an Mitm need mention and will propose the =
following text for it to be added to the solution criteria.</FONT></P>

<P><FONT FACE=3D"Times New Roman">&quot;Man-in-the-middle Offline =
Attacks</FONT>
<BR><FONT FACE=3D"Times New =
Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The solution should not allow the =
man-in-the-middle from being able to perform offline attacks on the =
weak inner method protocols used within a tunnel.</FONT></P>

<P><FONT FACE=3D"Times New Roman">&quot;</FONT>
<BR><FONT FACE=3D"Times New Roman">Would it apply to all EAP methods, =
or just some<BR>
subset? If it only applies to a subset, why does this subset benefit =
from<BR>
tunneling?</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">Section 3.2, 3.3 and 3.6 of the =
version2 draft partially cover this.&nbsp; Policy based solutions apply =
to all methods. However for key deriving methods, cryptographic binding =
is possible. Now from section 1.2 we already explained why tunnels have =
been in use and what the resulting benefits are for both legacy and new =
methods</FONT></P>

<P><FONT FACE=3D"Times New Roman">&lt;/jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">Is this resolution =
acceptable?</FONT>
<BR><FONT FACE=3D"Times New Roman">best regards,</FONT>
<BR><FONT FACE=3D"Times New Roman">jose</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2F255.C16FD970--