[21077] in Athena Bugs
Re: Login puzzle
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Nov 14 16:45:19 2002
From: Greg Hudson <ghudson@MIT.EDU>
To: Tom Cavin <cavin@mit.edu>
Cc: SIPB Linux Help <linux-help@mit.edu>, Athena Bugs list <bugs@mit.edu>
In-Reply-To: <15828.5904.15736.489720@lap1-wccf.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 14 Nov 2002 16:45:15 -0500
Message-Id: <1037310315.1248.371.camel@error-messages.mit.edu>
Mime-Version: 1.0
On Thu, 2002-11-14 at 16:35, Tom Cavin wrote:
> 1. If I understand this correctly, the srvtab/keytab file is used to tie
> the host to the issuing KDC. A public Athena workstation -- without
> a srvtab -- could conceivably be spoofed by a fake KDC and the user
> could then login with tickets that were not valid for the real KDC.
> How would a user be able to determine whether they had been spoofed?
The risk is not to the user, but to the machine. In order for the
attack to work, the attacker has to know what password the user is going
to type. So if I have control of the network, I could log into a public
machine as "cavin" without knowing your password. But I wouldn't have
valid cavin@ATHENA.MIT.EDU tickets.
Since public machines have no interesting data on them, the ability to
break into them in this fashion isn't very interesting.
> 2. When a user gets a new system, passes their old host down the food
> chain, and keeps their old hostname for their new system, the old
> host with a srvtab/keytab is renamed by making a change in the
> rc.conf file and rebooting. Will this cause problems on the old
> system at login? Is the solution to simply get new srvtabs from
> accounts for both systems?
It shouldn't cause a problem for the old system; xlogin will try to get
a service ticket for rcmd.newhostname and fail, since the machine
doesn't have that particular key in srvtab/keytab.
The world is, naturally, a better place if both the old and new machines
have proper srvtab/keytab files with fresh keys.
> 3. If a host has a bad srvtab/keytab file for any reason, will removing
> both /etc/athena/srvtab and /etc/krb5.keytab temporarily fix things
> to allow console login until a new srvtab is received from accounts?
> Or will the fact that a srvtab/keytab record exists in the KDC cause
> difficulties when there is no matching local record?
Yes, that will fix things to allow console logins.
> 4. If a srvtab/keytab for a host changes on the host and the KDC (so
> that they both now agree), are there any other copies of the old
> srvtab/keytab information or any tickets or other keys that are
> derived from the old srvtab/keytab that would remain active and need
> to be fixed? (This might be an existing ssh session, a KNFS mount,
> or a token for an AFS file server.) And if so, how can these
> problems be fixed?
Existing sessions will be fine. An attempt to establish a new ssh
session might experience problems for a user who has existing
credentials with a stale service ticket in them. You fix this problem
by running "renew" as the user (or "kinit" outside of Athena), which
forces a fresh credential cache.
> 5. If both a srvtab and a keytab file exist on the same system, which
> one is checked first? Does this depend on the application? And are
> they ever directly compared to verify that they agree?
The keytab is checked first. Doesn't matter which the application is.
They are never directly compared.
