[6316] in Kerberos
Re: Help about Kerberos (TGT request)
daemon@ATHENA.MIT.EDU (Richard Basch)
Tue Dec 5 07:41:27 1995
Date: Tue, 5 Dec 1995 07:25:10 -0500
To: aldini@zeus.csr.unibo.it (Alessandro Aldini mat.1193)
Cc: kerberos@MIT.EDU
In-Reply-To: <49uita$o5i@sirio.cineca.it>
From: "Richard Basch" <basch@lehman.com>
On , 4-December-1995, "Alessandro Aldini" wrote to "kerberos@MIT.EDU" saying:
> I read from "Firewalls and Internet Security" about the Kerberos
> Authentication System :
> Kerberos principals may obtain tickets for services from a special server
> known as the Ticket Granting Server (TGS).
> The client "speaks" to TGS with a private key and he obtains this key at
> session-start time from KDC (key distribution centre). The client
> makes a request to the KDC to obtain this key (and other information for
> the TGS) and the KDC reply with an encrypted messagge; the key used for this
> messagge is
> the client private key, so the KDC must know the private key of every user.
> The client key is derived from a noninvertible transform of the user's
> typed password. I suppose that KDC uses a secret algorithm to obtain the
> private key from the password and every client knows his own password and
> key but not the algorithm password-to-key. Is it true ? Otherwise how can
> KDC know every client private key ?
> Please answer me in e-mail. Thank you for your help.
> CIAO, Alessandro.
The algorithm for converting the password into the key is well known.
The way it works is:
User issues a request to the KDC saying send me a ticket with which I
can present you with other tickets without needing my password again.
The KDC responds with a TGT encrypted in the user's key (derived from
his password). The user can then decrypt the KDC response which gives
him a TGT and a ticket granting session key. All future ticket requests
are done by sending the TGT (which has his authentication name and the
ticket granting session key encoded in it and which only the KDC can
unravel because it is encrypted in a key known only to the KDC) along
with whatever other tickets he needs. These ticket requests are always
authentic because only the user who had the original password could have
possibly gotten the TGT. The new tickets are encrypted in the ticket
granting session key, so only the user can decrypt it.
I have oversimplified some things when it comes to Kerberos V5, as the
above attack allows one to make one TGT request, and keep trying to
decrypt the TGT offline with lots of keys (this is possible in V4). In
V5, there are also pre-authentication routines that can be enforced.
So, basically, think of Kerberos as being a set of envelopes that can be
opened only if you know the seal... Here is a quick picture:
[password/TGT session key]
---------------------------------------------------------
| |
| session key |
| |
| |
| [service key] |
| ----------------------------------------- |
| | | |
| | authentication name | |
| | session key | |
| | | |
| ----------------------------------------- |
| |
| |
---------------------------------------------------------
There is more information. However, this model does show how a session
key is sent to the user and the service that the user is sending the
ticket to, without the session key being disclosed. Each service also
has a key associated with it, just like each user. From the KDC
perspective (in V4), in fact, they are equivalent.
--
Richard Basch URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 33rd Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
