Newbie question on keytab -- no need for this on clients, right?

[Jeffrey Hutzelman]

On Monday, April 12, 2004 08:17:15 -0400 Wyllys Ingersoll 
<wyllys.ingersoll at sun.com> wrote:


> Clients do not typically use the keytab file, they either prompt for
> name/password and then request initial creds or read the initial
> credentials from the user's cache.

True, in most cases.  It's perhaps clearer to think about this this way...

First, try to think of clients and servers as processes, not machines. 
Several processes may be running on the same machine in both roles.

In any Kerberos authentication exchange, both entities involved (client and 
server) share a key with the KDC.  For the most part, when the entity is a 
human, that key is derived from a password the human types.  When the 
entity is a daemon, the key is normally read from a keytab.

So, telnetd or sshd is going to read its key from a keytab.  On the other 
hand, kinit is going to read a password from the user, and turn it into a 
key; in this case, a keytab is not needed.  However, an automated process 
that needs to access a Kerberos-authenticated service (for example, a cron 
job that needs to scp something from a remote machine or write to a file in 
AFS) will generally obtain Kerberos tickets using a key stored in a keytab, 
even though it is acting as a client.


Then there's the login program.  A Kerberos-aware login generally acts as 
both a client and server in the same process.  It accepts a username and 
password from a user, and uses them to obtain a TGT, just as kinit does. 
It then uses that TGT to obtain a service ticket for the login service 
(generally host/fully.qualified.host.name), and verifies the resulting 
service ticket against the service key, which is obtained from a keytab.

This step is essential to preventing unauthorized logins by an attacker who 
is cooperating with the operator of a bogus KDC.  Since the attacker and 
bogus KDC operator both know the password that will be typed, they could 
together trick a host into allowing a login, unless the host validates the 
obtained TGT against a service whose key is known only to it and to the 
real KDC.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA