[1004] in Kerberos
Re: Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (smb@ulysses.att.com)
Thu Jun 14 22:02:31 1990
From: smb@ulysses.att.com
To: bcn@cs.washington.edu (Clifford Neuman), kerberos@ATHENA.MIT.EDU
Cc: mischu@allegra.att.com (Michael Merritt)
Date: Thu, 14 Jun 90 21:24:14 EDT
Michael Merritt and I have just finished a paper on the limitations and
weakness of Kerberos. We're doing a rewrite now, and will make it
available via anonymous ftp as soon as possible. For the moment, let
me list our recommendations. The last point is quite relevant to this
discussion, and the paper discusses a number of alternatives.
A challenge/response protocol should be offered as an optional
alternative to time-based authentication.
Use a standard message encoding, such as ASN.1, which includes
identification of the message type within the encrypted data.
Alter the basic login protocol to allow for handheld
authenticators, in which {R}KC, for a random R, is used to
encrypt the server's reply to the user, in place of the key KC
obtained from the user password. This allows the login
procedure to prompt the user with R, who obtains {R}KC from the
handheld device and returns that value instead of the password
itself.
Mechanisms such as random initial vectors (in place of
confounders), block chaining and message authentication codes
should be left to a separate encryption layer, whose
information-hiding requirements are clearly explicated.
Specific mechanisms based on DES should be validated and
implemented.
The client/server protocol should be modified so that the
multi-session key is used to negotiate a true session key,
which is then used to protect the remainder of the session.
Support for optional extensions should be included. In
particular, an option to protect against dictionary attacks on
/etc/passwd may be a desirable extension.
It is, however, worth stating loudly and clearly that even without
these changes, we do think that Kerberos is vastly superior to the
current situation. We just think it could be better still.
--Steve Bellovin
