[967] in Kerberos_V5_Development
proposed krshd option
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Jan 19 22:17:15 1996
Date: Fri, 19 Jan 1996 22:17:05 -0500
From: Sam Hartman <hartmans@MIT.EDU>
To: krbdev@MIT.EDU
As people will notice from my commit tonight, I added
checksumming to the krshd authenticator. Currently, I do not consider
it an error for a request to come in without a checksum on the
authenticator in order to prevent breaking compatibility with older
rsh clients. This is reasonable because it still provides increased
security. If a new client is used to generate a request, a new server
will not allow the request to execute a commnd other than the one
intended by the request. I.E. Unless a user chooses to produce an
insecure authenticator by using an old client, the use of rsh will
not produce authenticators that can be used to spoof the command
line. However, other clients can be used to produce these
checksumless authenticators; in particular, an encrypted (or
unencrypted) rlogin connectin will not add a checksum value to an
authenticator.
I propose two new options to krshd: an option (-e if not
taken) to require that the rsh connection be encrypted to be accepted,
and an option (-k if not taken) to require that the connection include
a checksum Either of these options would effectively require a v5 rsh
client be used, as they are both features not found in the v4 clients.
Also, I have received at least one question about what attack
I am trying to prevent from someone who thought the replay cache would
do what I'm trying to do. I'm trying to prevent active attacks that
either prevent an authenticator from reaching the server, or
substitute part of the tcp stream to change the request. Yes, these
are much harder than passive replay attacks, but It's only about 45
lines on code, so I think it's worth it.
--Sam
