[2321] in Kerberos
Re: kerberizing xlock ???
daemon@ATHENA.MIT.EDU (Greg Wohletz)
Fri Oct 30 16:40:31 1992
To: Barry Jaspan <bjaspan@Athena.MIT.EDU>
Cc: Jim Hendrick <hendrick@neptune.ctron.com>, kerberos@Athena.MIT.EDU
In-Reply-To: Your message of "Thu, 29 Oct 92 12:11:08 EST."
Date: Thu, 29 Oct 92 10:28:27 -0800
From: Greg Wohletz <greg@duke.cs.unlv.edu>
>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.
Another solution is to run a kerberized server on some physically secure
machine (the kerberos server for example) which the login process attempts
to do mutual authentication with using the tgt it got, if this succedes
then the user is allowed to login. Only the machine running this server
need be physically secure.
--Greg
