Re: low-overhead encrypted telnet

>1) Kerberos *does* work between corporate entities.

In practice, no, it doesn't.  This is not a technical problem,
but it's nevertheless quite real.  You will never see inter-realm
Kerberos set up at places line netcom, because netcom's sysadmins
have better things to do than manage secret keys for every
organization that wants to connect.  Only a system with completely
automated configuration and operation has a chance.

>2) Using your example, a user on host A telnets to host B, and from
>host B they telnet to host C, if the A<->B link is encrypted, then so
>long as the user trusts host B, then A<->C is secure as well (assuming
>B<->C is encrypted).

Yes, of course, if the A<->B link is encrypted then subsequent logins
are secure.  The point is to find a way to secure those logins *without*
full encryption of the A<->B link.

>3) Just encrypting from client->server will not necessarily reduce the
>load on the server.

In practice, almost all of the time, it will.

>Also, doing something like DES is really not a
>very high CPU operation, IMHO.

Personally I agree with this.  Most sysadmins will not.

>4) Charon, which is based upon Kerberos, was developed exactly for
>this type of problem: you want to authenticate securely over links
>which may not otherwise be secure, but you trust the CPU in front of
>you!  The paper describing Charon is available via anonymous ftp:
>	ftp://toxicwaste.mit.edu/pub/charon/thesis.ps.Z

I'll check this out, but if it's based on Kerberos it's probably
useless for the reasons mentioned above.
---
Jef

> I'll check this out, but if it's based on Kerberos it's probably
> useless for the reasons mentioned above.

Charon does not require any shared kerberos.  All it does require is
that the destination server have an rcmd srvtab, and the user have a
kerberos principal that can authenticate to that server in some form.

To use your netcom example, if netcom had their own kerberos realm,
and if they were running the Charon server, then anyone with a Charon
client and a netcom account could securely authenticate to their
netcom account, no matter where they were actually coming from.

-derek