[22] in Kerberos
integration with old protocols
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:16:06 1987
From Saltzer@ATHENA.MIT.EDU Tue Jul 22 20:35:32 1986
Date: Tue, 22 Jul 86 20:32:35 EDT
To: kerberos
Subject: integration with old protocols
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Yet another proposal (in this case the example is POP) for
integration of kerberos by assigning a new well-known TCP port for a
protocol variant leads me to want to explore possible alternatives.
Here is a proposal that might eliminate the need to make any changes
at all in old protocols that we want to authenticate with Kerberos.
The idea is to assign one new well-known TCP port, exclusively for
the purpose of compatible authentication in preexisting protocols.
Any server that ran one or more of the old protocols would also run a
listener on this port, known as the Ksetup server (better name
proposals are welcome.)
The scenario, say for POP, would go as follows:
1. The POP client, modified to use Kerberos, would track down a POP
ticket and authenticator and send them together with the service
name for POP in a single UDP datagram, to the Ksetup server's port.
(Using a standard time-out/retry procedure for reliability.) The
authenticator part of the packet would include in one field,
encrypted, the identity of this client, in exactly the form the
POP protocol expects to receive it.
2. The Ksetup server would look in /etc/servtab for the appropriate
key, examine the ticket and authenticator, and if all looks OK,
create an entry in a new table, /etc/Kconnections. This entry would
contain all the interesting information in the original ticket--client
identification, expiration date, temporary key, etc., plus the
IP address of the client that sent it. It would return a
datagram reporting success or failure in this endeavor.
3. The POP client, upon receipt of a success response, would then
proceed to invoke the POP protocol according to the present
specification.
4. The POP server, upon receiving a request for connection, would
collect the requester's claimed identity (in the form provided
as part of the standard protocol) and the IP address
of the requester (may be tricky--is that information easily
available?) and call to a Kerberos library routine named
is_this_one_OK(). That routine returns 0 for failure and the
value of the temporary key for success.
5. The routine is_this_one_OK() operates by comparing the
information supplied by the POP server with the information in
/etc/Kconnections. If the IP address and identity both match,
it returns the temporary key.
6. The POP server can now accept the connection, and if wanted
it might even encipher the data with the temporary key before
sending it back to the POP client.
I think the same pattern would work for rlogin, rsh, rexec, lpr, POP,
and even NFS and RVD. Protocols such as tftp, which do not attempt
to identify their clients, require a different strategy, though
authentication based only on IP address would probably suffice. New
protocols such as notify would have the option of including the
initial exchange as part of their definition rather than by relying
on the Ksetup server.
Any comments?
Jerry
