Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!ames!ig!bionet!agate!shelby!ctt.bellcore.com!lunt
From: lunt@ctt.bellcore.com (Steve Lunt)
Newsgroups: comp.protocols.kerberos
Subject: Re: Why is initial user authentication done the way it is?
Message-ID: <9006141836.AA11688@dduck.ctt.bellcore.com>
Date: 14 Jun 90 18:36:04 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 51

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 -----