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

[Sam Hartman]

>>>>> "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
    >> now.
    >> 
    >> 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
libraries.



    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
alternative.

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
    Darren> anything.

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.