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