[5993] in Kerberos
Re: kerberos v4 or v5 on osf 3.2
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sat Oct 14 20:48:33 1995
To: dworkin@suod.cs.colorado.edu (Dieter Muller)
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "13 Oct 1995 23:19:52 GMT."
<45ms6o$i5u@csnews.cs.colorado.edu>
Date: Sat, 14 Oct 1995 20:33:19 EDT
From: Sam Hartman <hartmans@MIT.EDU>
>>>>> "Dieter" == Dieter Muller <dworkin@suod.cs.colorado.edu> writes:
Dieter> I've been working with the January 1995 release of the
Dieter> Cygnus distribution for the last few months. Although it
Dieter> plays well on a homogeneous network, there are some
Dieter> definite problems on multi-platform networks, particularly
Dieter> when the word size varies amongst those platforms. Very
Dieter> soon I expect to be sending out diffs against that release
Dieter> that:
I find this somewhat hard to believe. I have been establishing encrypted sessions with Dec Alphas from 32-bit machines, where the 32-bit machines are running either CNS or Athena Kerberos, and the Alpha is running something very close to CNS. Our KDC is on a decstation, and it works from architectures of varying byte order and word size.
Dieter> - Allow DEC alphas, Sun sparcs, HP snakes, and SGI indigos
Dieter> to all play well together. Playing well is defined as
Dieter> being able to run a KDC on any of those architectures and
Dieter> having all architectures be able to take advantage of that
Dieter> KDC, and being able to do encrypted sessions (rcp and
Dieter> rlogin) between any combination of architectures.
Dieter> - Supports multi-homed clients and KDCs.
You cannot do this without violating the protocol or
significantly decreasing the security of Kerberos. It's actually possible to have a multi-homed KDC, but multi-homed clients create some significant problems (solved in Kerberos 5) that you can't easily address without knowing what interface packets will travel over.
Dieter> - Supports TCP-based authentication exchanges with the
Dieter> KDC, so that there is no need to allow unrestricted UDP
Dieter> through a firewall.
This change is significantly not backward compatible. Also,
you will break eventually when you have to convert to V5, which is a
UDP-only protocol. Also, you should be able to only allow packtes to/from ports 750, 751 and 88 and you should be fine.
Dieter> - Encrypted rdist (using the 4.4 BSD rsh/rshd modified to
Dieter> use the Cygnus libraries).
Unless you have significant experience designing secure
protocols, I strongly advise against this. You may develop a false
since of security, assuming that your connections are secure; it is
likely that the obvious schemes for doing encrypted rsh/rdist can be
compromised by man-in-the-middle attacks, etc. (There have been
enough bugs in the protocols designed for v4 by people with a
significant security background that this warning is worthwhile. You
may have a good solution to the problem; it certainly is possible and
can doesn't present any technical obstacles that haven't been overcome
before. However, it is easy to do wrong, and you should be very
careful before relying on your protocol.)
Dieter> I'm hoping to have these diffs out in the next month or
Dieter> so. We're running most of it right now in the CS
Dieter> department, but it's not all quite there yet.
Dieter> We've got plans for more than just the above, but this
Dieter> seems like a good release point.
Good luck.
Dieter> Since news tends to flow faster than I have the
Dieter> opportunity to read it, follow ups should probably be CC'd
Dieter> to me directly.
Dieter> Dworkin
