[941] in Kerberos_V5_Development
No subject found in mail header
daemon@ATHENA.MIT.EDU (Richard Basch)
Tue Oct 31 18:35:40 1995
Date: Tue, 31 Oct 1995 18:34:57 -0500
To: krbdev@MIT.EDU
From: "Richard Basch" <basch@lehman.com>
The approach you stated sounds good. I wanted to implement this back
when I added "encrypted rsh" support. However, at the time, there was
no interface by which I could modify the checksum. If the checksum is
ignored by old clients, as you said, then I see no problem. Back then,
I would have had to change the interface (which was problematic), but it
sounds like it has been changed.
The -x option did not exist prior to Beta 5... so such a change is
probably safe...
Richard Basch
Lehman Brothers, Inc. Email: basch@lehman.com
101 Hudson Street 33rd Flr. Fax: +1-201-524-5828
Jersey City, NJ 07302 Voice: +1-201-524-5049
Date: Tue, 31 Oct 1995 01:49:28 -0400
From: Sam Hartman <hartmans@MIT.EDU>
To: krbdev@MIT.EDU
Currently, rshd does a fairly good job of authenticating a
user, but doesn't do a good job of authenticating their request. I
realize krshd is to be desupported, but honestly, I don't see that
happening just yet; it's going to take a lot of work before telnetd is
a plug-in replacement for rshd.
Anyway, I believe I have a way of making it secure without
breaking backward compatability--it involves changing the protocol
somewhat, but AFAIK rsh isn't standardized to the extent that any
formal process is required.
I propose that the kcmd function include a checksum of the
command line by using the indata argument to krb5_mk_req (well,
krb5_compat_sendauth, but the argument exists). This would cause the
authenticator sent over the net to contain a checksum. This
checksumwould get stuff into the auth context on the remote end. n
old krshd would ignore the checksum, but a new krshd could verify a
checksum if it exists, and execute only command lines that sum
correctly. Since the command line indicates the client's encryption
preference, this would allow the client to securely negotiate
encryption.
Since you can't pull fields out of an authenticator and expect
it to decrypt correctly, an active attack cannot try to substitute an
authenticator without a checksum for one containing a checksum. Thus,
from what I can tell, if a client only uses the new rsh and only
connects to hosts with the new rshd, an attacker cannot:
1) Force a different command line to be executed.
2) Force an encrypted session to be non-encrypted
3) Use TCP sequence number guessing attacks to take over a
encryp[encrypted stream successfully without breaking the session key.
--Sam
