[995] in Kerberos
Re: Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Steve Lunt)
Thu Jun 14 16:12:17 1990
Date: Thu, 14 Jun 90 14:36:04 -0400
From: Steve Lunt <lunt@ctt.bellcore.com>
To: apollo.com!pato@bellcore.bellcore.com
Cc: athena.mit.edu!kerberos@bellcore.bellcore.com
Joe,
Correct. I should have mentioned this.
This requires that the workstation make two requests of the Kerberos server. An alternative would be for the workstation to use *its* TGT (which it
could get at boot time) to request a ticket for the user, which it could then try to decrypt with the user's password. Of course, the user wouldn't get a TGT. This opens a whole other can of worms with the question: should the user himself or the workstation itself authenticate to other network services?
-- Steve
----- Begin Included Message -----
From pato@apollo.com Thu Jun 14 14:25:13 1990
From: pato@apollo.com (Joe Pato)
Date: Thu, 14 Jun 90 14:12:24 EDT
Subject: Re: Why is initial user authentication done the way it is?
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
-------
----- End Included Message -----
