Path: utzoo!attcan!uunet!ogicse!uwm.edu!bionet!agate!shelby!ulysses.att.com!smb
From: smb@ulysses.att.com
Newsgroups: comp.protocols.kerberos
Subject: Re: Why is initial user authentication done the way it is?
Message-ID: <9006150124.AA14075@ATHENA.MIT.EDU>
Date: 15 Jun 90 01:24:14 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 42

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