Summary of MITM attacks with legacy authentication

[Charlie_Kaufman@notesdev.ibm.com]

There has been a lot of traffic about avoiding MITM attacks when
incorporating legacy authentication into IKEv2. For a long time, I didn't
understand it. Now I think I do. That does not imply I really do. I'm
writing this note both to summarize the other notes here and to find out
whether I really understand it by giving everyone a chance to stomp on me
if I don't.

Q: What is a man-in-the-middle (MITM) attack?

A: This is where someone gets between the two communicating parties in an
IPSec connection, impersonates each end to the other, and ends up with
connections to both such that he can read and/or modify messages as they
pass while the two parties think they are talking only to one another.

Normally in IPSec, the MITM attack is avoided by having each end of the
connection authenticate in a means that is tied to the keys used to protect
the connection. The AUTH payload in IKEv2 is computed over data including
the Diffie-Hellman numbers used to derive the keys.

The challenge with legacy authentication is somehow cryptographically
entangling the authentication data with the keys used to encrypt the
connection. With some forms of legacy authentication, it is impossible.
With others, it's possible but not easy. With still others, it's not
necessary. A lot of the discussion on this list concerns making sure that
we do it when it's possible. A lot of the confusion concerns knowing when
it's possible and when it's not.

An example when it's not necessary to protect against MITM:

Alice has a SecurID card that she uses to authenticate to server Bob. When
the connection is set up, Bob first authenticates to Alice using an X.509
certificate. Alice verifies that she is connected to Bob before typing the
number from the SecurID card, which is sent over the encrypted channel.
Alice knows she is talking directly to Bob because he authenticated with a
certificate. Bob knows he is talking directly to Alice because he knows
Alice would never give her SecurID number to anybody but him.

An example when it's not possible to protect against MITM:

Same as the above except that Alice uses her SecurID number to authenticate
to lots of servers besides Bob. If Alice connects to Carl, verifies his
identity and then sends her SecurID number, Carl could use that number to
impersonate Alice to Bob. Anyone who learns Alice's SecurID number of the
minute can impersonate Alice to any server accepting that form of
authentication. The cryptographic trick we would like to play is sending
Carl a hash of the SecurID number and his name. If he could present such a
hash to the SecurID server and have it verify the hash, then Carl would
never have to learn the raw number and hence would not be able to
impersonate Alice to Bob. But the very nature of "Legacy Authentication" is
that we can't assume that we can change what the verification routine is
willing to accept. Today, the SecurID server will only verify a raw number
and we're not likely to get them to change it for IKE. Note that in this
case, Alice is not fooled... she knows that she's not talking to Bob. But
Bob is fooled and there is no fancy crypto that can prevent it.

An example when we might be able to protect against MITM:

Suppose Alice has a password, and she uses that password to authenticate to
many servers. If the authentication protocol consists of sending the
password over an encrypted channel to the server, then it has the same
problem as the case above... anyone who learns Alice's password can
impersonate Alice. But if the authentication protocol is based on
Challenge-Response, where the server sends Alice a challenge, Alice
cryptographically combines it with her password and sends the result back,
then the protocol would resist MITM if the challenge had to include Bob's
name or some function of the IKE session key.

So what does this mean for Legacy Authentication in IKEv2?

My reading of the SLA proposal is that the mechanisms supported are:
(1) password sent to Bob,
(2) OTP password sent to Bob,
(3) Challenge-Response Card where Bob generates full challenge
(4) SecurID card where Alice sends the displayed number to Bob.

For all of these mechanisms, MITM protection is impossible because those
protocols require that the secret value (and not just a hash of it) be
available on the server for verification.

If we were to add stronger legacy authentication mechanisms (e.g. CRAM-MD5,
Kerberos, SRP), we should at that time design MITM protection. There are
several plausible mechanisms. My favorite would be to generate some sort of
key identifier for the IKE connection and wind that in to the legacy
authentication mechanism rather than taking a key generated by the legacy
authentication and winding it into IKE. But either would work.

OK, guys. How much of this did I get wrong.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).