Re: Summary of MITM attacks with legacy authentication

[David Jablon <dpj@xxxxxxxxxxxx>]

At 04:04 PM 12/31/02 -0500, Michael Richardson wrote:
>   Charlie> My reading of the SLA proposal is that the mechanisms supported are:
>    Charlie> (1) password sent to Bob,
>
>  note that for MD5/DES/Unix-style /etc/passwd, Bob doesn't have a secret,
>just a way to check a value.

In a responsible implementation, Bob *does* have a secret: 
the hashed password.  Exactly how he might use it to verify
that Alice knows the password depends on the method.

SLA (1) simply sends the password to the server, so what a
smarter server might be able to do in another protocol is somewhat
irrelevant.  But it is important to consider when discussing a more
general framework for handling legacy credentials.

>    Charlie> (2) OTP password sent to Bob, [...]
>   Charlie> (3) Challenge-Response Card [...]
>   Charlie> (4) SecurID [...]
>   Charlie> For all of these mechanisms, MITM protection is impossible because those
>    Charlie> protocols require that the secret value (and not just a hash of it) be
>    Charlie> available on the server for verification.
>
>  If it were possible to include some non-transmitted value into the
>SKEYSEED, 
>we might be able to cause the MITM to be unable derive the same
>sessions keys. This could be accomplished in X9.9 and SecurID by not
>transmitting the entire displayed value - both ends can derive it in
>theory. In practice, Bob will use Radius or some such to verify the value,
>and the standard protocols do not return the "correct" value to Bob.

Without commenting on this specific approach, it is one example
of how a more general framework could take advantage of added
keying material.

>   Charlie> OK, guys. How much of this did I get wrong.
>
>  I think that you got it perfectly correct.
>  But, I think that this is why Legacy Auth is a pain. This is why we must
>make it easy to bootstrap into public key authentication, permitting it to
>be deployed easily - this starts by not tying it to PK*I*.

I don't understand that reasoning. The option to tie legacy credentials
to an IKEv2 key may be an important step to make it easy for some
to bootstrap into public key authentication.  When one can establish
a secure connection based soley on a legacy credential, one can
find ways to use that connection to securely transfer other
necessary information.

-- David