[991] in Kerberos_V5_Development
Re: removing user-user authentication from rcp client
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Feb 2 16:00:04 1996
To: "Donald T. Davis" <don@cam.ov.com>
Cc: Sam Hartman <hartmans@MIT.EDU>, krbdev@MIT.EDU
From: hartmans@MIT.EDU (Sam Hartman)
Date: 02 Feb 1996 15:59:41 -0500
In-Reply-To: "Donald T. Davis"'s message of Thu, 01 Feb 1996 21:25:48 -0500
>>>>> "Donald" == Donald T Davis <don@cam.ov.com> writes:
Donald> sam, i was the coauthor (with ralph swick) of v5's
Donald> user-to-user protocol, which i intended in part to support
Donald> client-to-client rcp (as well as secure x service). so,
Donald> i'm perplexed by your subject line; your message seems not
Donald> to refer to the "two tgt" protocol we wrote. i'm hoping
Donald> that your message isn't about removing "two tgt" support
Donald> from rcp. please, can you clarify my confusion?
Yes; I'm proposing to remove the two TGT protocol from the rcp
client, maintaining support in the server for backward compatability.
I agree that this protocol is a reasonable solution for X but think
that using the native encryption support in the krshd is much
preferable to requiring the TGT on both sides of the rcp. Here are
the reasons I think this is preferable:
1) The Athena operations people I talked to indicated that requiring
two TGTs was unacceptable. They want to be able to avoid having any
unnecessary root tickets, and want to be able to copy a file from a
more trusted machine to a less trusted machine without getting
credentials on the less trusted machine. Athena and the
Re-engineering team are our two primary customers; it's sometimes a
good idea to list to the requirements of your customers.
2) I fail to see any situations where the two-TGT protocol can be
applied that the rsh encryption protocol cannot be applied to. (Well,
you construct things to work for machines not running a kshd, but
having an encrypted connection to something that will trust network
addresses for authentication is less than ideal, and the current
implementation will not fall back to rcmd if kcmd fails anyway.)
I have talked to several memebers of the Kerberos team here,
and no one has been able to figure out why a two-TGT protocol is
preferable for rcp; it's possible we're missing something.
--Sam
Donald> -don davis, boston
Donald> ----------------------------------------------------------------------
Donald> you wrote: There is no good reason for rcp not to use rsh
Donald> -x and there are several good reasons for it to do so. In
Donald> particular, the current implementation requires the user
Donald> to have tickets on both sides of the connection. I will
Donald> investigate using a protocol compatible with rsh -x, and
Donald> if it looks fairly easy, implement the change. I will
Donald> retain server support for the old method at the current
Donald> time, although I think we should consider it depricated.
Donald> Also, since I haven't heard any objections to removing
Donald> the TGS enctypes check on the cccache code, I wil go ahead
Donald> and do so. This means that if a specific enctype is not
Donald> request, any ticket of any enctype found in the ccache
Donald> will satisfy the request.
Donald> --Sam
