Re: Summary of MITM attacks with legacy authentication

[Michael Richardson <mcr@xxxxxxxxxxxxxxxxxxxxxx>]

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


>>>>> "David" == David Jablon <dpj@xxxxxxxxxxxx> writes:

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

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

  For Unix-style /etc/passwd, dictionary attacks (i.e. "crack") aside, the
hashed value is actually not a secret. Unix systems get additional defense
against "crack" by keeping is secret. The important point is that Bob has
no way to generate the same value as Alice. If they could, they could just
use that as a PSK, or we could use CHAP. We can not do either with
/etc/passwd style passwords. 

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

    David> I don't understand that reasoning. The option to tie legacy credentials
    David> to an IKEv2 key may be an important step to make it easy for some
    David> to bootstrap into public key authentication.  When one can establish

  No, you are missing my point. A common reason for sticking to a legacy
authentication method, such, as for instance, NT-domain authentication (which
involves no investment in physical tokens, for instance), is because of the
very real fact that the only way to move beyond it with many products is to
move to a full blown PKI. 

  This makes no sense in a 20 person office. There needs to be things in
between PSK/legacy auth, and full-blown PKI. Those things are:
       1) raw RSA keys			(pre-exchanged)
       2) self-signed certificates	(pre-exchanged)
       3) signed certificates by an untrusted party
		 (signed by, e.g. Verisign's free CA, but pre-exchanged)

  Note that pretty much all of the legacy auth proposals want the client to
authenticate the server using a public key. Yet, many clients/gateways are
too locked into their PKIs to even permit a self-signed certificate to be
easily loaded in as a trusted key.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@xxxxxxxxxxxxxxxxxxxxxx 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

iQCVAwUBPhMrgIqHRg3pndX9AQGecAP6A1mmD8P2NULk7RntTeAV0MFbozwX+Ouo
7aqeqY2F1T9Z/KIA3+FoIjBs9zcwoMtT4v5O4w1XnOE1Lpy5CizMATe93XYXYacP
+DBxidC/Qpm6SDx13J4SmMF8rjiqRXYvIPWxXuY1KZc4ZnOrTlQyBSg2jO4x82GS
NiWaJ6JJFAg=
=8tO0
-----END PGP SIGNATURE-----