[994] in Kerberos
Re: Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Joe Pato)
Thu Jun 14 15:38:43 1990
From: pato@apollo.com (Joe Pato)
Date: Thu, 14 Jun 90 14:12:24 EDT
To: lunt@ctt.bellcore.com (Steve Lunt)
Cc: athena.mit.edu!kerberos@bellcore.bellcore.com
In-Reply-To: lunt@ctt.bellcore.com (Steve Lunt), thu, 14 jun 90 13:59:49
In this case, the workstation is still vulnerable to someone spoofing the
authentication server. That is, the workstation has no way of knowing if it is
talking to the real Kerberos. The real Kerberos could be down, and the user
could simply send an appropriate reply to the workstation's TGT request as if
it were coming from Kerberos. You have this vulnerability with the current
Kerberos TGT request protocol if you configure your login program to use
the reply from Kerberos rather than the password in /etc/passwd for
authentication. The workstation needs some way of knowing that it is talking
to the real Kerberos. It could use it's secret (in /etc/srvtab) for this
purpose (requiring a change in the TGT request protocol.
-- Steve
Steven J. Lunt | lunt@ctt.bellcore.com | RRC 1L-213
Computer Security Technology |-------------------------| 444 Hoes Lane
Bellcore | (201) 699-4244 | Piscataway, NJ 08854
There is no need to change the TGT request protocol to work around this
problem. Simply have the login program request a ticket to the local machine
once the TGT has been acquired. It is the proper acquisition of this second
ticket that informs login that the user is valid and should be granted access
to the machine. The OSF DCE login code uses this strategy to validate both the
user and the KDC (I believe that this is also in the bsd4.4 login code)
-- Joe Pato
Cooperative Object Computing Operation
Hewlett-Packard Company
pato@apollo.hp.com
-------
