[2312] in Kerberos
Re: kerberizing xlock ???
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Thu Oct 29 12:51:35 1992
Date: Thu, 29 Oct 92 12:11:08 -0500
From: "Barry Jaspan" <bjaspan@Athena.MIT.EDU>
To: Jim Hendrick <hendrick@neptune.ctron.com>
Cc: kerberos@Athena.MIT.EDU
Date: Wed, 28 Oct 92 21:56:48 EST
From: Jim Hendrick <hendrick@neptune.ctron.com>
I am trying to figure out how to "correctly" kerberize
xlock.
Be careful; Kerberos was not designed to do what you want. Here is an
answer from the FAQ that will explain why.
Barry Jaspan
--- snip snip ---
Extracted from: Kerberos Users' Frequently Asked Questions
October 6, 1992
Compiled by: Barry Jaspan, <bjaspan@athena.mit.edu>
Geer Zolot Associates
(2.1) Can I use Kerberos for local password validation?
Yes, but only under certain circumstances and only if you are
careful.
Requests for Kerberos ticket granting tickets (tgts) (e.g. from kinit
or login) are sent in plaintext to the Kerberos server, which then
responds with credentials encrypted in the requesting principal's
secret key. The program then attempts to decrypt the data with the
supplied password and considers the authentication "successful" if the
decryption appears to yield meaningful results (such as the correct
principal name).
The problem here is that the requesting program cannot know for sure
whether the decryption succeeded or, more importantly, whether the
response actually came from the Kerberos server. An attacker could,
for example, walk up to an unattended machine and "log in" as a
non-existent user. Kerberos will eventually respond with an
appropriate error, but the attacker can arrange for another program to
deliver a fake response to login first; he then types the correct
password (which he knows because he created the fake response in the
first place) and succeeds in spoofing login.
The solution to this problem is for login to verify the tgt by using
it to acquire a service ticket with a known key and comparing the
results. Typically, this means requesting an rcmd.<hostname> ticket,
where <hostname> is the local hostname, and checking the response
against the key store in the machine's /etc/srvtab file. If the keys
match then the original tgt must have come from Kerberos (since the
key only exists in the srvtab and the Kerberos database), and login
can allow the user to log in.
The solution works only so long as the host has a srvtab containing an
rcmd.<hostname> (or any other standard principal) entry. This is fine
for physically secure or single-user workstations, but does not work
on public workstations in which anyone could access the srvtab file.
