Subject: [eap] Issue 65: Downgrade attacks

From: [email-masked] (Puthenkulam, Jose P)
Date: Mon, 24 Mar 2003 14:36:22 -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.CBC3E470
Content-Type: text/plain

Some comments/proposed resolution to this issue marked <jp>..</jp>. 
Issue 65: Downgrade attacks
Submitter name: Dan Simon
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/2003-January/000485.html
<http://mail.frascone.com/pipermail/eap/2003-January/000485.html> 
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

My main concern with the document is that it doesn't seem to say
anything about the legacy/rollback issue. If both fixed and legacy
"clients (authenticators) and "servers" (verifiers)
have to interoperate with each other, then a
signaling mechanism *incorporated into, and detectable in, legacy
instances* is necessary to allow fixed clients and servers to recognize
each other and avoid a rollback. Moreover, this signaling mechanism has
the additional advantage of solving the MITM problem completely, all by
itself, since it can be used to distinguish tunnelled from untunnelled
authentications.
<jp>
version 2 draft text that addresses this to some degree:
"For non-key deriving methods, if they are modifiable, then using a signal
to indicate when they are running inside a tunnel would also prevent the
attack. This works because the server is able to distinguish between an
attacker diverting a method into a tunnel versus a client method
intentionally initiated inside a tunnel. However such signals need
protection from spoofing."
We treat it as not just as legacy/rollback issue but for all non-key
deriving methods that can be modified. On the same note one of our solution
requirements is that we do not require changes to existing EAP
authentication methods (not tunneled ones). 
</jp>

Now, if one side of the authentication can be assumed not to include
legacy instances (e.g., all servers being upgraded simultaneously), then
a carefully designed fixed protocol may suffice, without any signaling
(e.g., an extra MAC is thrown into the protocol in both directions, and
the fixed client will detect an attempted rollback attack when it
doesn't receive the expected returned MAC from the fixed server). But
if both sides must interoperate with both fixed and legacy counterparts,
then signaling within the legacy protocol must be used if rollback is to
be prevented.
<jp>
Rollback attacks cannot be completely avoided. Usage of policies to prevent
rollbacks from being requested by unknown clients is one-way to approach
this problem. For clients that are known, then some amount of out of band
trust will have to be established to guarantee that such an attack does not
occur.
</jp>

For example, if, say, a compound key derivation solution is
used, then in the presence of both fixed and legacy clients and servers,
some mechanism has to be found to negotiate whether to use the "pure"
tunnel keys or compound keys. That mechanism needs to be such that,
say, fixed clients' messages can't be fiddled with to make them look
like legacy clients' messages, or the MITM can do the conversion and
force the server to roll back to the legacy protocol. On the other
hand, the fixed clients' messages must look enough like legacy clients'
messages that legacy servers can accept and respond to them according to
the legacy protocol. Hence the fixed clients' messages have to be
legacy-compatible messages with an indelible "signal" in them that a
fixed server will recognize as indicating a fixed client.
<jp>
In the version 2 draft, there is 'version' information included in the
binding phase exchange to prevent a fixed client from masquerading and
performing an attack.
</jp>

But the presence of this signal also obviates the need for the compound
key negotiation altogether; if fixed clients simply use the signal
whenever not tunnelling, then a tunnelling protocol server can reject
all tunnelled authentications containing the signal, thus protecting the
fixed client from MITM attacks even without any other protocol change.
<jp>
Proposed points to capture in version 3 draft update:
- Call out downgrade attacks more succinctly
- Call out the two options to prevent it
   1) If legacy methods are modifiable, then use signals
   2) If binding phase exchange is supported by the tunnel client and
server, then prevent any downgrade negotiation using policy
   For complete prevention 1 or 2 must be supported.
</jp>
Is this acceptable?
best regards,
jose

------_=_NextPart_001_01C2F255.CBC3E470
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 65: Downgrade attacks</TITLE>
</HEAD>
<BODY>

<P><FONT FACE=3D"Times New Roman">Some comments/proposed resolution to =
this issue marked &lt;jp&gt;..&lt;/jp&gt;. </FONT>
<BR><B><FONT FACE=3D"Times New Roman">Issue 65: Downgrade =
attacks</FONT></B><BR>
<FONT FACE=3D"Times New Roman">Submitter name: Dan Simon<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/2003-January/000485.html"=
><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New =
Roman">http://mail.frascone.com/pipermail/eap/2003-January/000485.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>
My main concern with the document is that it doesn't seem to say<BR>
anything about the legacy/rollback issue. If both fixed and legacy<BR>
&quot;clients (authenticators) and &quot;servers&quot; (verifiers)<BR>
have to interoperate with each other, then a<BR>
signaling mechanism *incorporated into, and detectable in, legacy<BR>
instances* is necessary to allow fixed clients and servers to =
recognize<BR>
each other and avoid a rollback. Moreover, this signaling mechanism =
has<BR>
the additional advantage of solving the MITM problem completely, all =
by<BR>
itself, since it can be used to distinguish tunnelled from =
untunnelled<BR>
authentications.</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">version 2 draft text that addresses =
this to some degree:</FONT>
<BR><FONT FACE=3D"Times New Roman">&quot;For non-key deriving methods, =
if they are modifiable, then using a signal to indicate when they are =
running inside a tunnel would also prevent the attack. This works =
because the server is able to distinguish between an attacker diverting =
a method into a tunnel versus a client method intentionally initiated =
inside a tunnel. However such signals need protection from =
spoofing.&quot;</FONT></P>

<P><FONT FACE=3D"Times New Roman">We treat it as not just as =
legacy/rollback issue but for all non-key deriving methods that can be =
modified. On the same note one of our solution requirements is that we =
do not require changes to existing EAP authentication methods (not =
tunneled ones). </FONT></P>

<P><FONT FACE=3D"Times New Roman">&lt;/jp&gt;<BR>
<BR>
Now, if one side of the authentication can be assumed not to =
include<BR>
legacy instances (e.g., all servers being upgraded simultaneously), =
then<BR>
a carefully designed fixed protocol may suffice, without any =
signaling<BR>
(e.g., an extra MAC is thrown into the protocol in both directions, =
and<BR>
the fixed client will detect an attempted rollback attack when it<BR>
doesn't receive the expected returned MAC from the fixed server). =
But<BR>
if both sides must interoperate with both fixed and legacy =
counterparts,<BR>
then signaling within the legacy protocol must be used if rollback is =
to<BR>
be prevented.</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">Rollback attacks cannot be =
completely avoided. Usage of policies to prevent rollbacks from being =
requested by unknown clients is one-way to approach this problem. For =
clients that are known, then some amount of out of band trust will have =
to be established to guarantee that such an attack does not occur.</FONT=
></P>

<P><FONT FACE=3D"Times New Roman">&lt;/jp&gt;<BR>
<BR>
For example, if, say, a compound key derivation solution is<BR>
used, then in the presence of both fixed and legacy clients and =
servers,<BR>
some mechanism has to be found to negotiate whether to use the =
&quot;pure&quot;<BR>
tunnel keys or compound keys. That mechanism needs to be such that,<BR>
say, fixed clients' messages can't be fiddled with to make them =
look<BR>
like legacy clients' messages, or the MITM can do the conversion =
and<BR>
force the server to roll back to the legacy protocol. On the other<BR>
hand, the fixed clients' messages must look enough like legacy =
clients'<BR>
messages that legacy servers can accept and respond to them according =
to<BR>
the legacy protocol. Hence the fixed clients' messages have to be<BR>
legacy-compatible messages with an indelible &quot;signal&quot; in them =
that a<BR>
fixed server will recognize as indicating a fixed client.</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">In the version 2 draft, there is =
'version' information included in the binding phase exchange to prevent =
a fixed client from masquerading and performing an attack.</FONT></P>

<P><FONT FACE=3D"Times New Roman">&lt;/jp&gt;<BR>
<BR>
But the presence of this signal also obviates the need for the =
compound<BR>
key negotiation altogether; if fixed clients simply use the signal<BR>
whenever not tunnelling, then a tunnelling protocol server can =
reject<BR>
all tunnelled authentications containing the signal, thus protecting =
the<BR>
fixed client from MITM attacks even without any other protocol =
change.<BR>
&lt;jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">Proposed points to capture in =
version 3 draft update:</FONT>
<BR><FONT FACE=3D"Times New Roman">- Call out downgrade attacks more =
succinctly</FONT>
<BR><FONT FACE=3D"Times New Roman">- Call out the two options to =
prevent it</FONT>
<BR><FONT FACE=3D"Times New Roman">&nbsp;&nbsp; 1) If legacy methods =
are modifiable, then use signals</FONT>
<BR><FONT FACE=3D"Times New Roman">&nbsp;&nbsp; 2) If binding phase =
exchange is supported by the tunnel client and server, then prevent any =
downgrade negotiation using policy</FONT></P>

<P><FONT FACE=3D"Times New Roman">&nbsp;&nbsp; For complete prevention =
1 or 2 must be supported.</FONT>
<BR><FONT FACE=3D"Times New Roman">&lt;/jp&gt;</FONT>
<BR><FONT FACE=3D"Times New Roman">Is this 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.CBC3E470--