[971] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: rlogin authenticator attacks

daemon@ATHENA.MIT.EDU (Richard Basch)
Mon Jan 22 13:47:58 1996

Date: Mon, 22 Jan 1996 13:46:44 -0500
To: hartmans@MIT.EDU (Sam Hartman)
Cc: krbdev@MIT.EDU
In-Reply-To: <tslrawtkx56.fsf@tertius.mit.edu>
From: "Richard Basch" <basch@lehman.com>

On , 21-January-1996, "Sam Hartman" wrote to "krbdev@MIT.EDU" saying:

> 	I would like to propose a change to rlogin similar to the
> change I recently checked into krsh  Basically, I would like to see a
> Kerberos distribution where using a relatively secure client like
> encrypted rlogin did not create a security problem if the kerberized
> unencrypted rlogind was running on the server.  
> 
> 	Currently, I can grab the authenticator used to establish an
> encrypted connection, prevent it from getting to the server to avoid
> the replay cache, and use the same authenticator to establish an
> unencrypted connection.
> 
> 	I propose to include some data in the rlogin authenticator  to
> indicate whether the connection is encrypted; if the connection is
> encrypted, then the unencrypted rlogind would not accept the
> authenticator.
> 
> 	The obvious way of doing this is two checksum two different
> constant strings.    (rlogin would say checksum "rlogin" and encrypted
> rlogin would checksum "rlogin -x").  I would propose to provide an
> option to drop backward compatability and require the checksum, just
> as I proposed for krshd.
> 
> 	Question (Please excuse my lack of mathematical background in
> cryptography.)  Are there any problems associated with using a
> constant string (well, two constant strings) as data to be checksumed?

My concern with the encryption of constant strings is that the checksums
are well known for a given key, and can be replayed differently with a
later authenticator.  If you want to truly be secure, make sure the
generated checksum gets factored into the authenticator checksum, so
that no intercept & replay attack is possible.
-- 
Richard Basch                   
Sr. Developer/Analyst           URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc.           Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 33rd Floor      Fax:   +1-201-524-5828
Jersey City, NJ 07302-3988      Voice: +1-201-524-5049


home help back first fref pref prev next nref lref last post