Vendor comments on plan to remove telnet, ftp and eventually appl/bsd
hartmans at MIT.EDU
Mon Jul 22 09:06:00 EDT 2002
>>>>> "Darren" == Darren Reed (Optimation) <darrenr at optimation.com.au> writes:
Darren> From: "Sam Hartman" <hartmans at mit.edu> [...]
>> We'd like to completely get rid of the BSD applications
>> (including login.krb5, rsh, rlogin and rcp). I believe that we
>> should wait until draft-ietf-secsh-gsskeyex is a proposed
>> standard fully implemented by at least one free Ssh
>> implementation before dropping rsh, rlogin and rcp. Others
>> have prop.proposed that we simply drop the BSD applications
>> I'm seeking vendor and site integrater comments on this
>> comments on this proposed direction.
Darren> Presently, MIT Kerberos ships with its own crypto library
Darren> and is effectively "standalone", as is. This is a good
Darren> thing. The SSL which comes to mind most readily is
Darren> OpenSSH. This depends on OpenSSL. Are you intending on
Darren> replacing the crypto API in Kerberos with OpenSSL or
Darren> changing something like OpenSSH to use the Kerberos crypto
Darren> API ?
No. Kerberos is unlikely to adopt OpenSSL because it would mean that
there would be no GPL-compatible Kerberos implementation.
We do not plan on bundling an ssh implementation so we do not plan to
change what crypto library any ssh implementation uses. We plan to
make sure there is an ssh implementation that works with our GSSAPI
Darren> So far as rlogin/rcp/rsh go, a basic requirement would be
Darren> that the command line syntax does not change. We have *a
Darren> lot of* scripts, documents, etc, which explicitly use
Darren> encrypted sessions.
OK. I don't know whether we plan on meeting this requirement; I
rather suspect not. We'll try to keep command line compatibility for
ftp and telnet, but our assumption is that no one actually wants to
maintain a Kerberos bsd application set for us to recommend and that
we'll be dropping that technology as soon as there is a viable
Of course the advantage of open-source software is that the community
can write software to fill voids and distribute this software. If
someone contributed migration scripts we'd certainly consider taking
them and if we decided against they could be maintained by their
author as a package for the community to use.
Darren> Another minor issues is it will require changes to
Darren> firewalls to allow ssh through and block r*. One could
Darren> well argue that letting ssh through is less secure than r*
Darren> - tunnelling via ssh allows you to let through almost
O, I can run ppp over rsh just as easily as ppp over ssh. Once I have
an encrypted channel in both directions I can tunnel whatever I like.
More information about the krbdev