Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!stanford.edu!MIT.EDU!jon
From: jon@MIT.EDU (Jon A. Rochlis)
Newsgroups: comp.protocols.kerberos
Subject: Re: Verifying passwords without getting new tickets
Message-ID: <9105171544.AA12520@delwin.MIT.EDU>
Date: 17 May 91 15:44:36 GMT
References: <9105170210.AA03097@steve-dallas.MIT.EDU>
Sender: news@shelby.stanford.edu (USENET News System)
Organization: Internet-USENET Gateway at Stanford University
Lines: 36


   
      Is there a way to verify a userid and password without getting a
      new ticket-granting-ticket?
   
   By definition, no.  "Verifying a userid and a password" under Kerberos
   is defined as asking the Kerberos server for a tgt and having it
   successfully decrypted by the kinit/login program, using the password
   provided by the user.  

This is not true.  Think about it.  If you ask Kerberos for a initial
ticket (it need not be a TGT) and decrypt it, you have only made use
of *one* secret (the user's password).  Kerberos is based upon shared
secrets.  To identify a principle you need to have *two* secrets.

This is an example of the old ksu bug, where spoofing the KDC actually
buys you something.  (I.e. I want to fool you into thinking I'm
George.Bush@WhiteHouse.GOV, so I tell you that's my name. You request
a TGT (or whatever) from Kerberos, but before Kerberos can respond
with a real ticket, I reply with a well formed ticket encrypted in the
password "millie", which I type in when your program asks.  It will
decrypt just fine and dandy.  If you tried to actually use the ticket,
the service you're trying to fool would reject it.)  This is pretty
easy to do and has been demonstrated.

To be safe you must ask Kerberos for a ticket and then *use* it by
sending it to a service with it's own secret (service key) registered
with kerberos.  Check out the sources for ksu.  In order to be secure
you need to have a srvtab with rcmd.hostname for ksu to use (since ksu
is setuid it can keep the service key secret).

This is perhaps subtle, but very important.  There is at least one
commercial implementation of Kerberos which is vulnerable to this
attack.

		-- Jon