Purpose of Server Public/Private Key??

[Russ Allbery]

Jake Mudau <someone at someplace.com> writes:

> What is the purpose of having a server public/private key architecture?
> I mean, when a user needs to be authenticated, the following is quite
> sufficient [or is it :)]:

Kerberos uses a secret key architecture and doesn't have public/private
key pairs, so I'm not entirely sure what you're asking.

> 1.  UserID passed in plain-text to server;
> 2.  Server submits an encrypted "challenge"-plus-unique-session_id with the
> user's password back to client;

This is what Kerberos calls pre-auth and is used to prevent off-line
dictionary attacks.  Kerberos v4 didn't have these steps; they were added
in Kerberos v5.  With Kerberos v4, you just asked the server for a TGT and
it gave you one, encrypted in the user's private key.  If you could
decrypt it, you could use it right away without authentication to the KDC.
Kerberos v5 added (optional, but generally should always be turned on)
pre-authentication before it would give you a TGT.

> 3.  Client decrypts challenge from server with password and conducts
> pre-defined scrambling (not encrypting) of plain-text;
> 4.  Client encrypts scrambled plain-text with unique session_id and sends
> back to server;

With Kerberos, this is instead a follow-up request to the KDC for what's
called a "ticket granting ticket" or TGT, which is the user credentials.

> 5.  Server decrypts with previously sent unique session_id and confirms
> correctness of scrambled challenge.  If ok, client authenticated and new
> session_id passed for rest of the client's operations.

Server sends the TGT back to the user encrypted in the user's password and
the user decrypts it.  Then, whenever that user wants to connect to
another network service, it sends a request to the KDC using that TGT and
gets back a service ticket for that particular service, which is a piece
of information encrypted in the private key of that service.  The client
then uses that service ticket to authenticate to the service, and the
service can check that the service ticket is valid by decrypting it with
its own private key.

Maybe what you're missing is that Kerberos isn't designed solely to
authenticate a user to a single service, but instead to provide the user
with a set of credentials which can then be used to authenticate to *any*
Kerberos service without requiring further authentication events in the
client?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>