[972] in Kerberos_V5_Development
Re: rlogin authenticator attacks
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Jan 22 15:38:14 1996
To: "Richard Basch" <basch@lehman.com>
Cc: hartmans@MIT.EDU (Sam Hartman), krbdev@MIT.EDU
From: hartmans@MIT.EDU (Sam Hartman)
Date: 22 Jan 1996 15:37:34 -0500
In-Reply-To: "Richard Basch"'s message of Mon, 22 Jan 1996 13:46:44 -0500
>>>>> "Richard" == Richard Basch <basch@lehman.com> writes:
Richard> 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.
This would be cool except for the fact that rlogin uses kcmd
to do its sendauth, and I want to generate the checksum in kcmd for
krsh. So, what I do is checksum the port number of the remote side
of the connection into the checksum. This breaks compatability with
Friday's krshd, but somehow I don't see a major problem breaking
compatability with something I did late last week, so long as I
maintain compatability with released code, which I will do.
>> >>
>> 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?
Richard> My concern with the encryption of constant strings is that the checksums
Richard> are well known for a given key, and can be replayed differently with a
Richard> later authenticator. If you want to truly be secure, make sure the
Richard> generated checksum gets factored into the authenticator checksum, so
Richard> that no intercept & replay attack is possible.
Richard> --
Richard> Richard Basch
Richard> Sr. Developer/Analyst URL: http://web.mit.edu/basch/www/home.html
Richard> Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
Richard> 101 Hudson St., 33rd Floor Fax: +1-201-524-5828
Richard> Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
I thought the entire authenticator was encrypted in the
session key. I am using the indata argument to krb5_mk_req,
indirectly through krb5_sendauth.
--Sam
