[5009] in Kerberos
Re: Secure telnet/PPP/Kerberos/STEL/... (was Re: STEL: Secure TELnet -- Call for Beta Testers)
daemon@ATHENA.MIT.EDU (Jeff A Licquia)
Fri Apr 21 11:24:46 1995
To: kerberos@MIT.EDU
Date: 21 Apr 1995 15:02:02 GMT
From: jalicqui@firefly.prairienet.org (Jeff A Licquia)
Joe Kovara <joek@kerby.ocsg.com> writes:
>One purpose of the KDC is to manage keys. Assuming there is a shared
>secret, STEL will have the same requirement. (And even if you're using
>public key, you need a CA.) The question is then: What key management
>facilities does STEL provide? I don't know, but something will be needed.
>(All Kerberos implementations that I am aware of provide key management
>capabilities.) Saying that key management is someone else's problem is
>not an option.
Wasn't it said in the call for beta testers that STEL uses Diffie-Hellman
key exchange? If so, there's your key management, done without a KDC. Not
needing a KDC may be the big feature STEL provides over Kerberos.
>What about the security of the authentication scheme? Diffie-Hellman was
>suggested as solving the need for secure authentication to the host
>(licensing issues aside). Nope. Diffie-Hellman allows two strangers to set
>up a secure channel. It does not authenticate either end (unless we add
>certificates, CA's, etc.; but remember, we're trying to keep this simple).
>Well, since I've got a secure channel, why not send my password? Ok, who
>goes first? If you're talking to a bad guy, whoever goes first has just
>given away their password. This does NOT imply that the host has already
>been compromised. It simply means that someone has been able to fool you
>(using DNS/IP spoofing) into talking to them instead of the real host.
>Very doable, very probable. And it doesn't require me to compromise the
>host or your workstation. This means you still need a strong
>authentication mechanism even if you use Diffie-Hellman. Ah ha! I'll use
>token based authentication as well. This will help. But then, you need
>cards, you need an authentication server to go with it, ... Remember,
>we're trying to keep this simple. (And, yes, our Kerberos supports
>token-based authentication.)
It was said that STEL will support S/Key authentication, which might work
better than a password scheme.
I think STEL is intended for a level of security below Kerberos but above
regular telnet. As you say, there are complexity issues in setting up
Kerberos, not to mention the licensing stuff. If your threat model doesn't
require that much security, why go through the overhead?
>We can (and have) made things very simple for the Kerberos clients/users.
>We can (and have) made things as simple as is reasonable (which is pretty
>simple) for the Kerberos KDC and server, and the administration thereof.
>Again, implementations vary _tremendously_ in their level of convenience.
>(I can't speak for others, but it's not unusual for a competent sysadmin
>who understands basic Kerberos concepts to be up and running "out of the
>box" in a matter of hours...your mileage may vary.) However, no matter
>what system you use (Kerberos, STEL, Fred's security, ...) -- all other
>things being equal -- the whole package is going to have an equivalent
>level of complexity, or it is going to give up something.
That's true. The question is whether what you give up gains you other
benefits without a big loss according to your needs. There is a place for
rot13, after all.
--
----------------------------------------------------------------------
Jeff Licquia (lame .sig, huh?) | Finger for PGP 2.6 public key
jalicqui@prairienet.org | Me? Speak for whom? You've got
licquia@cei.com (work) | to be kidding!
