Vendor comments on plan to remove telnet, ftp and eventually appl/bsd

[Darren Reed (Optimation)]

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 now.
> 
> I'm seeking vendor and site integrater comments on this
> comments on this proposed direction.

Presently, MIT Kerberos ships with its own crypto library and
is effectively "standalone", as is.  This is a good thing.
The SSL which comes to mind most readily is OpenSSH.  This
depends on OpenSSL.  Are you intending on replacing the crypto
API in Kerberos with OpenSSL or changing something like
OpenSSH to use the Kerberos crypto API ?  A change to the
crypto API in Kerberos will impact our use of those libraries.
(I mention OpenSSH because it is the only real alternative - FreSSH
 doesn't yet do version 2 of the protocol.)

In integrating Kerberos on site, we don't use login.krb5, rather
we run kinit directly from a custom login application, so I can't
say I (we) would have a problem there.

So far as rlogin/rcp/rsh go, a basic requirement would be that the
command line syntax does not change.  We have *a lot of* scripts,
documents, etc, which explicitly use encrypted sessions.

Another minor issues is it will require changes to firewalls to allow
ssh through and block r*.  One could well argue that letting ssh
through is less secure than r* - tunnelling via ssh allows you to
let through almost anything.