[2601] in Kerberos
Kerberos 5 & login
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Thu Feb 25 16:58:12 1993
Date: Thu, 25 Feb 93 08:34:05 PST
From: Clifford Neuman <bcn@ISI.EDU>
To: bf4grjc@bell-atl.com
Cc: tytso@Athena.MIT.EDU, kerberos@Athena.MIT.EDU
In-Reply-To: Ganesan's message of Thu, 25 Feb 1993 11:12:54 -0500 (EST) <9302251612.AA04629@tommylab.wash.bell-atl.com>
From: bf4grjc@socrates.MIT.EDU (Ganesan)
Date: Thu, 25 Feb 1993 11:12:54 -0500 (EST)
Realizing that Kerberos was NOT intended for initial login/xdm
authentication, it is still true, that in MANY environments, the
overhead of maintaining both /etc/passwd (or whatever for non-UNIX
systems) AND a Kerebros database is completely impractical, and
Kerberos WILL end up getting used for login/xdm.
Given above, why cannot there be an OPTION ADDED (not change) to
the protocol such that the initial TGT is sent to the login/xdm
programs "additionaly" encrypted with a service key known only to
the KDC and the login/program.
I believe this was discussed before and there were some other proposals. Why
cant any ONE of these proposals be made part of the standard as an OPTION
(not change).
I do not know if your comments is related to the message to which it
is a followup. However, it is important to distinguish between the
protocol, and the software that implements it. The Kerberos protocol
as it stands is quite capable of supporting initial login. In
particular, you use the password entered by the user to decrypt
initial credentials, and you then use those credentials to obtain
subsequent credentials for logging into the local machine. Only one
password needs to be entered by the user, and only one password/key
database need be maintained (that for Kerberos). No protocol changes
are required.
The discussion you responded to centers on whether this is supported
by the login program on the client. The issues had to do with
replacing the login program with one that does what I just described,
and the fact that by doing so, you may miss some important vendor
specific actions in login. I agree that such a login program would be
useful as an option (i.e. the warning is that you replace your vendor
supplied login at your own risk). Again, however, not changes are
needed to the protocol.
~ Cliff
