Subject: [eap] Review of draft-puthenkulam-eap-binding-01.txt (fwd)

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 10:56:42 -0800 (PST)

---------- Forwarded message ----------
Date: Fri, 3 Jan 2003 16:57:32 -0800
From: Dan Simon <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Review of draft-puthenkulam-eap-binding-01.txt

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.

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.

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.

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.

Do you agree that the legacy problem is a real one?  If so, then the
solution approach needs to be changed, because the proposals presented
so far don't solve it.

					Thoughts?

					  Dan