[5684] in Kerberos
Re: SSL as Kerb replacement
daemon@ATHENA.MIT.EDU (Bob Kelley)
Fri Aug 11 17:28:48 1995
To: kerberos@MIT.EDU
Date: 11 Aug 1995 20:54:30 GMT
From: bkelley@cup.hp.com (Bob Kelley)
Donald T. Davis (don@cam.ov.com) wrote:
> to be sure, these alternate approval channels would do the
> trick, and that has always been the public-key industry's
> assumption. however, how well does such an approach scale
> up to the internet as a whole? will joe sixpack check a
> paper copy of his ca-key's fingerprint? for that matter,
> will even a sophisticated user do it every day? if they
> don't, it's worthwhile to attack their systems so as to
> corrupt their stored copies of the ca keys. this is why my
> attack matters: to block it, users need either smartcards,
> or eternal vigilance. if you're not 100% sure of the top-
> level ca key, rsa's guarantees won't be 100%, either;
> it's like using a kryptonite lock to lock your bike to a
> picket fence.
Well, let's consider the picket fences involved in Kerberos,
because I think they exist and may be of the same magnitude
as the ones you cite re SSL.
Your primary concern with SSL is this: the public certs of
the CAs are stored on the system of a user and are required
to be 100% correct for the system to work. Even if they
are 100% correctly proven (through alternate channels), the
average user is susceptable to intrusion because an intruder
may modify those certs, if the intruder gets access to
the users system and has root capabilities. To be 100%
effective, I am extrapolating from your comments above, the
user should check the ca keys every day to ensure they have
not been corrupted by unauthorized users on the system with
root capability to do such corruption.
In a kerberos system, if I had root access on the system,
I could do equivalent damage. I would just rewrite /bin/login
or kinit to capture the typed in password of the user. Once
I had that I could do what I want. I could rewrite the tty
code to capture keystrokes and find out the password. I could
rewrite sum and ps and md5 and all the utilities to mask these
changes. Ever hear of the hacker utility 'rootkit'? It does
exactly this, and it compiles on a Sun in about 30 seconds.
Appears to me that both kerberos and SSL are equally open to attacks
where a malicious user has got root access to the client system.
