[553] in Kerberos
Re: [Ted Anderson: principal name standards] and more
daemon@TELECOM.MIT.EDU (Bill Sommerfeld)
Thu Dec 15 18:33:50 1988
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: kfall@OKEEFFE.BERKELEY.EDU
Cc: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>,
In-Reply-To: Kevin Fall's message of Thu, 15 Dec 88 14:08:19 PST,
I am actually sort
of curious why the convention at Athena has become
person.root for a 'more priviledged version' of person. It seems to
me that for the super-user of a given machine, you really
want something more like root.machine1, root.machine2.
Two reasons:
1) it's easier to selectively grant and revoke access.
2) it's more secure for each user to have his or her own
superuser password.
It has been asserted (I think I read it in "Cardinal of the Kremlin"
or one of the other Tom Clancy books :-) ) that the probability that a
secret will "leak" is proportional to the square or cube of the number
of people who know it. We believe that it is inherently insecure for
more than one person to know a password, and that it is easier and
safer to delete someone from a /.klogin file than to change the root
password and propagate this to all the people who _should_ know
without telling anyone else.
Also, as the number of machines grows, it quickly becomes necessary
for people receiving the passwords to write them dowm, which is a very
major security hole. Most people can remember three or four passwords
which they chose and which they use frequently. How many can remember
ten or fifteen which were chosen by someone else and which change
often?
In fact, you may not want 'root instances' in the database
at all, keeping in mind that if the master key were compromised
you'd be that much worse off.
Every way I look at it, the amount by which you are "that much worse
off" is close to epsilon. If I know a server's secret key (obtained
either by stealing its /etc/srvtab or by stealing the kerberos
database and master key), I can impersonate any user of that service.
It seems inconvenient to have to administer
new (principal,instance) pairs for these people.
The administrative overhead is the same as for registering new users.
The krb.conf file currently contains the *name* of the machine(s)
we will use for contacting the Kerberos server. This implies
a later gethostbyname() [found in send_to_kdc.c].
If you are running the nameserver
it is possible to be spoofed into returning the incorrect
inet address. (This is currently a problem with ruserok as well).
Until something better comes along, this should be changed to
a inet address.
Even if this is the case, it's only a denial of service attack, which
this change won't fix because it's trivial to fill in the "from"
address of an IP packet with an arbitrary value.
Unless the spoofer knows your secret key and the secret key of the
server you're trying to contact, he can't come up with a ticket which
both you and the server will "like".
One way of getting around this problem is to have client
and server (e.g. for rdist and other 'system' processes)
have a common secret key and do encrypted updates. I am
using this currently to allow users to add themselves to the
kerberos system remotely if they have managed to log
in successfully.
Actually, what we are starting to do here is to have a program which
gets a ticket granting ticket based on a server's key (as stored in
/etc/srvtab), and then adding that server's key to the appropriate
"access control lists").
- Bill
