From: Jef Poskanzer <jef@ee.lbl.gov>
To: Derek Atkins <warlord@mit.edu>
Message Hash: c6f4ed441e779d4d2e891f018fc799360dfada3068353c829ea9bca068c07a6a
Message ID: <9403012126.AA09307@hot.ee.lbl.gov>
Reply To: N/A
UTC Datetime: 1994-03-01 21:27:15 UTC
Raw Date: Tue, 1 Mar 94 13:27:15 PST
From: Jef Poskanzer <jef@ee.lbl.gov>
Date: Tue, 1 Mar 94 13:27:15 PST
To: Derek Atkins <warlord@mit.edu>
Subject: Re: low-overhead encrypted telnet
Message-ID: <9403012126.AA09307@hot.ee.lbl.gov>
MIME-Version: 1.0
Content-Type: text/plain
>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
Return to March 1994
Return to “Jef Poskanzer <jef@ee.lbl.gov>”