[118] in Kerberos
authentication forwarding; X servers
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:30:36 1987
From miller%erlang.DEC@decwrl.DEC.COM Thu Oct 16 03:39:14 1986
Date: 15-Oct-1986 1518
From: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
To: kerberos@athena.mit.edu (Distribution list @KERB)
Subject: authentication forwarding; X servers
The recent messages from both Jerry and Jeff point out that Kerberos
was not initially designed to support such "authentication forwarding".
I believe Jeff's suggestions can provide a reasonable workaround,
analogous to poor-man's-routing. Note that the address is sealed in
the ticket to provide an inexpensive means of detecting certain replay
attempts when using one-way authentication. Unless we go to a 3-way
handshake for mutual authentication, and eliminate the one-way
authentication, it should stay there.
To address Jerry's question using the X client example, Jeff's suggestion
could be further extended such that a client on host A can request tickets
that would be valid from host B. Then the client safely transports the
tickets from host A to host B, and uses them on host B as if they were
originally obtained there.
I would suggest a couple of minor changes-
a) Only the session key needs to be secret, since the
ticket is only valid in conjunction with the session
key to create an authenticator. (could even change
a future version of Kerberos to not encrypt the tickets
returned from the Kerberos server, but merely the
session keys and a checksum of the tickets.)
b) modify the ticket-granting ticket to allow requesting
more than one ticket at a time, only restricted by
the minimum length limits of a UDP datagram. This makes
the network and server transactions more efficient when you
know you need more than one ticket at a time.
The original auth_request allowed this, but has since been
limited to only 1 ticket request at a time.
c) guarantee that a new krbtgt ticket created from an existing
krbtgt ticket expires no later than the original.
The X problem, where the X server comes and goes with different owners
on a workstation, is not readily solved using the Kerberos server.
It would require frequent changes to the Kerberos database, and to the
"owner" of an entry in the database. The current batch update of the
database, as well as its administrative restrictions, make this unreasonable.
Make your own ticket--
----------------------
However, if you view the role of the Kerberos server as securely distributing
a session key between a client and server, other possibilities arise.
The secrets that Kerberos maintains are the master keys.
A user logging into a workstation is in a perfect position to securely
distribute a session key to the server, i.e. the X server on the workstation,
and the client, i.e. themself! For example, the user could use their own
password as the temporary X server master key, and construct their own ticket
for the X service automatically at login time! Local X client applications
would use the ticket thus constructed. If you wanted to rlogin to another
system then run an X application to the original host, do as suggested
by Jeff, but making your own ticket.
I havent thought through all the details for the X server problem, but
I think this type of approach is feasible.
Comments?
