Path: utzoo!attcan!uunet!lll-winken!ames!eos!shelby!APOLLO.COM!pato
From: pato@APOLLO.COM (Joe Pato)
Newsgroups: comp.protocols.kerberos
Subject: Re: Why is initial user authentication done the way it is?
Message-ID: <9006141812.AA01911@xuucp.ch.apollo.com>
Date: 14 Jun 90 18:12:24 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 30


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