[2596] in Kerberos
Re: Re: Kerberos 5 & login
daemon@ATHENA.MIT.EDU (Dean Anderson)
Thu Feb 25 12:36:45 1993
From: dean@ksr.com (Dean Anderson)
To: bf4grjc@bell-atl.com
Cc: tytso@Athena.MIT.EDU (Theodore Ts'o), kerberos@Athena.MIT.EDU
In-Reply-To: Your message of "Thu, 25 Feb 93 11:12:54 EST."
Date: Thu, 25 Feb 93 12:22:33 EST
Actually, login bases its authentication on the "fact" that it
got a real ticket, and the ticket could be decrypted by the
users password. This implies that one can tell (must be able to tell)
that the ticket has been successfully decrypted. This in itself
is a weakness, because a cracker can also tell that it has successfully
decrypted the ticket.
Better, is to consider the ticket completely opaque.
The login program should request a ticket for the user which comes back in
the normal way encrypted in the users private key. The login program
sets up the initial key file (shared memory), and requests a ticket
for the authorization server.
(The implementation of the authorization server just sends back a yes
if the ticket presented to it (and the session key used to encrypt the
session) are valid. The login/xdm program accepts this and permits access.
The authorization server can also decide if a given user should be
permitted access on a given machine at a given time, etc.
This is similar to what the OSF DCE does, though the authorization
part is combined with the kerberos server. They really should be
different services so that they can be changed independently.
--Dean
