[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Summary of MITM attacks with legacy authentication



-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Charlie" == Charlie Kaufman <Charlie_Kaufman@notesdev.ibm.com> writes:
    Charlie> An example when it's not necessary to protect against MITM:

    Charlie> Alice has a SecurID card that she uses to authenticate to server Bob. When
    Charlie> the connection is set up, Bob first authenticates to Alice using an X.509

  If the client can be configured to never do SecurID with anything other
than Bob - i.e, a config file that says:
     Use SecurID SLA when speaking to public key X.

  then we can administratively prevent Alice from giving herself away. This
isn't very strong, I agree, and doesn't help Bob defend himself.
  As you say, Alice is never fooled. Only Bob is. 

    Charlie> Same as the above except that Alice uses her SecurID number to authenticate
    Charlie> to lots of servers besides Bob. If Alice connects to Carl, verifies his

  The major concern is if Alice uses her card to authenticate into multiple
realms. This is fundamentally not a supported method with SecurID - those
other realms can *already* impersonate her. Same with every system where Bob
has to know the entire secret value! (Kerberos, NT-domain authentication,
X9.9 and SecurID)

    Charlie> So what does this mean for Legacy Authentication in IKEv2?

    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.

    Charlie> (2) OTP password sent to Bob,

  i.e. S/Key. Bob doesn't have the secret here either.

    Charlie> (3) Challenge-Response Card where Bob generates full challenge

  i.e. X9.9. 

    Charlie> (4) SecurID card where Alice sends the displayed number to Bob.

    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.
  
    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*.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPhIGVoqHRg3pndX9AQHDzAP/SOnRyEc6DvjZTSI86LlntywEtq7M5CMR
HUSTWSslfbZxvcJgN1qyxsiFGFWyoH7HcDBlwvqh5gGwPpKU69Bi7eoP2F85F8PS
eHhvlPf8UEfz4bE4YCYd8bCfmiT3/XF1lKPZArgwsiOTKpfUmyXPrNPouSfD+9oH
3y4P6TTEbhA=
=Qj9t
-----END PGP SIGNATURE-----