[5644] in Kerberos
Re: SSL as Kerb replacement?
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Wed Aug 9 16:32:15 1995
To: Bob Kelley <bkelley@cat.cup.hp.com>
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "Wed, 09 Aug 1995 09:39:37 PDT."
<199508091639.AA133486378@cat.cup.hp.com>
Date: Wed, 09 Aug 1995 16:26:00 -0400
From: "Donald T. Davis" <don@cam.ov.com>
bob kelley wrote:
>> * it cannot assure the appl server that the client-
>> generated session-key is fresh and randomly-generated.
>
> I think this weakness is an implemenation detail that could
> equally affect kerberos.
bob,
kerberos uses a cryptographic random number generator,
based on des; it's sound. i'll look at the ssleay rng,
but "looks more unpredictable" doesn't sound great;
you'd be surprised by what can be predicted.
at any rate, key-freshness remains to be addressed. when the
client chooses the session-key, the appl-server has no reason
to believe that the session-key is fresh. to see why freshness
guarantees matter, see the paper, "a logic of authentication,"
by mike burrows, martin abadi, and roger needham (proc. r. soc.
lond. A 426 (1989) pp. 233-271).
>> * it's vulnerable to a man-in-the-middle attack, because
>> there is no way for the user to authenticate his top-
>> level certification authority keys.
>>
> If I have a recent CRL and I require 2 way authentication,
> and we require certs to be signed by a trusted list of CA's,
> I don't think man-in-the-middle attack can happen.
it's not enough to trust the ca's; you have to authenticate
their public keys, all the way up the chain. to do that, you
have to make sure your top-level ca key is authentic, either
by hand-checking it, or by making sure that your local copy
of it is incorruptible.
if the attacker replaces one of the client software's
top-level ca keys (they're stored in the executable),
then the attacker can cause the client to accept forged
certificates. unhappily, when executables come as freeware
and from fileservers, this key-substitution is easy to do.
once the user accepts a forged certificate, the attacker
can pose as the application server.
to perform the m-i-t-m attack (so as to escape detection),
the attacker then needs to impersonate the client in a
simultaneous session with the real application server.
to block this, the client must first encrypt, then sign
his messages, so that the attacker can't replace the
forged server key's encryption with the real server's key.
but, it turns out that this too is broken; for details,
see the paper,
"security defects in ccitt recommendation x.509 - the
directory authentication framework," by colin i'anson &
chris mitchell (acm comp. comm. rev., apr '90, pp. 30-34).
rsa's security rests on users getting their top-level ca
keys out-of-band. for example, paper distribution from a
trusted source is ok, as is electronic communication that's
secured with something other than rsa; a smartcard's
rom would be ok, too, as long as the smartcard can't be
forged. just putting the ca keys into the client-side
executable isn't good enough; they have to be authenticated.
it doesn't suffice to sign the executable, either;
the signing key still has to be authenticated.
> Can you send me a copy of your paper?
sure, i'll send it in private e-mail.
after your reply, i'd like to take the rest of this discussion
to e-mail, if you don't mind.
-don davis, boston
