> From: Rodney Thayer [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 05, 2001 6:01 PM
> given the recent noise about "the S word" (ssh, which may or may
> not be a trademark in some places), I think the whole question of
> SSH vs. Telnet with TLS should be reconsidered.
>
> What's the state of the art? STUNNEL with Telnet?
Telnet through Stunnel is more work than necessary, now that there are
SSL-enabled Telnet implementations available.
And as always with security questions, there's no universal best solution.
For (Telnet-style) remote access, there are really two authentication
scenarios, and which one you implement (or you might choose to provide both)
depends on your needs.
1. Shared-secret. This is the classic Telnet model: the user authenticating
to a server that knows the user already. Simple implementations, like
classic Telnet plain-text password transmission, have obvious problems.
What you'd really like is something that minimizes password exposure.
Ideally, only the user knows the password (though it'll have to exist at
least ephemerally on the client workstation). Nothing that goes over the
wire can be used to reconstruct the password, and nothing on the server can
be used to reconstruct or substitute for the password (in case the server is
compromised). That's what SRP gives you: the server has only a verifier for
the password, and the authentication protocol is a zero-knowledge proof.
(There are other protocols in the EKE family which offer similar benefits,
including the relatively new PAK-RY from Bell Labs which has been proven
secure under certain assumptions, but SRP is the most readily available.)
2. Public. This is the model you use when it's not practical to have every
user securely set a password on every server they might use: use any decent
asymmetric ("public key") protocol to authenticate and negotiate a session
key. What you most want to avoid here is anonymous key exchange, because
that offers you no authentication and leaves you open to MITM and
compromised or malicious servers. And that means you need a public key
infrastructure of some sort, whether it's certificates and well-known CAs or
authenticated keyservers or PGP-style web of trust or what have you. PKI
will always be an additional administrative burden (unless and until a
trustworthy PKI becomes ubiquitous). That's the price you pay for not
having established shared secrets through an alternate secure channel ahead
of time, as you do with the shared-secret model. This is the model that SSL
is most often used for, though it can be used for many other things as well.
The advantage of Telnet implementations that support a decent set of AUTH
extensions is that you can deploy one set of programs and support both
models. The same is true of SSH, now that SSH implementations support a
wide variety of authentication schemes. But Telnet has the advantage of
supporting legacy Telnet implementations. (On the other hand, Telnet
doesn't come with a file-transfer application, while SSH does; but there are
FTP implementations that support a variety of authentication schemes,
including the one that comes in the SRP distribution.)
There's also Kermit, which these days offers a very impressive range of
features for both remote access and file transfer.
And these things are not mutually exclusive, of course. If I were in charge
of a remote-access infrastructure, I'd be strongly inclined to set up Telnet
and FTP with multiple authentication modes, the SRP Java Telnet client
served from a web page so remote users could get a secure session from any
Java-equipped browser, SSH, and Kermit, and the infrastructure necessary to
support public authentication. Give the users some options and gradually
transition them away from the unsafe ones.
Michael Wojcik [EMAIL PROTECTED]
MERANT
Department of English, Miami University
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
