[Gllug] Kerberos resources

[Bruce Richardson]

Talk followup:

Kerberos FAQ:  http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html

Designing an Authentication System: a Dialogue in Four Scenes:
	http://web.mit.edu/kerberos/www/dialogue.html

Heimdal (Kerberos V5) resources at that Swedish place:
	http://www.pdc.kth.se/heimdal/

Kerberos V4 resources:
	http://www.pdc.kth.se/kth-krb/doc/kth-krb_toc.html
(Much of this is also relevant to V5 - use V5!)

"Kerberos for Morons" by Brian Tung:
	http://www.isi.edu/gost/brian/security/kerberos.htm

Brian Tung's book, "Kerberos: a Network Authentification System",
ISBN 0-201-37924-4


And an excerpt from my notes that didn't make it onto the high-tech
display screen:

Fred wants to use a kerberised telnet client to telnet to server.org.uk,
which is running a kerberised telnet daemon.

1.  Fred sends a request (using his Ticket Granting Ticket) to the KDC:
"I want to talk to the telnet daemon on server.org.uk" (well, the
kerberised telnet client does it but let's keep this simple.)

2.  The KDC generates a new session key which Fred and the telnet daemon
will use to secure their communication.

3.  The KDC sends two messages to Fred: the first contains a copy of the
new key and the name of the remote telnet daemon and is encrypted using
Fred's key.  The second contains a copy of the new key and Fred's name
and is encrypted using the telnet daemon's key (and is Fred's "ticket"
to talk to the telnet daemon).

(The KDC is not involved from this point on).

4.  Fred decrypts the first message (he can't decrypt the second as he
doesn't have the key) and extracts the new session key.

5.  Fred creates a message containing the current time (the
"authenticator) and encrypts it using the session key.

6.  Fred sends the new message and the ticket he received from
the KDC to the telnet daemon.

7.  The telnet daemon decrypts the ticket from the KDC (passed on to it
by Fred) and extracts the session key and Fred's name.

8.  The telnet daemon uses the session key to decrypt the authenticator from
Fred and checks the time.

At this point, Fred has authenticated himself to the telnet daemon and
they can use the session key for further communication.  But Fred may
want the telnet daemon to authenticate itself to him, in which case:

9.  The telnet daemon takes the timestamp from Fred's authenticator,
adds its name and encrypts the result with the session key to create its
own authenticator, which it sends back to Fred.

Some notes on this process:

Step 3:  You might ask why the KDC sends both messages to Fred and
doesn't just send the ticket directly to the daemon.  One answer is that
if, for some reason, Fred aborts the process before contacting the
daemon then the daemon's time isn't wasted waiting for a request that
never appears.  Another is that Fred's presenting the ticket himself is
another validation of his identity.

Steps 5 and 8:  This depends on clocks being in sync across the realm.
A certain amount of drift ("skew") is permitted, by default a maximum of
5 minutes.

Fred's authenticator: this usually contains additional information such
as a checksum and possibly extra keys.

-- 
Bruce

What would Edward Woodward do?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 261 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20011111/88d22fda/attachment.pgp>