[6013] in Kerberos
Re: kerberos v4 or v5 on osf 3.2
daemon@ATHENA.MIT.EDU (Dieter Muller)
Tue Oct 17 09:15:39 1995
To: Sam Hartman <hartmans@MIT.EDU>
Cc: kerberos@MIT.EDU
Return-Receipt-To:
In-Reply-To: Your message of Sat, 14 Oct 1995 20:33:19 EDT
Date: Tue, 17 Oct 1995 07:01:26 -0600
From: Dieter Muller <dworkin@suod.cs.colorado.edu>
Sam Hartman writes:
: >>>>> "Dieter" == Dieter Muller <dworkin@suod.cs.colorado.edu> writes:
:
:
: Dieter> plays well on a homogeneous network, there are some
: Dieter> definite problems on multi-platform networks, particularly
:
: I find this somewhat hard to believe. I have been establishing encrypt
: ed 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 somethin
: g very close to CNS. Our KDC is on a decstation, and it works from architec
: tures of varying byte order and word size.
The problems we were seeing were the inability to establish encrypted
sessions to the Alphas from non-Alpha systems (Solbournes, to be
precise, but the problem should also happen with sun4s). The bug is
several instances of `long' in various over-the-wire data structures.
The change was to change the longs to KRB_INT32s. The resulting code
works between sun4s, Solbournes, and Alphas, as well as with
1992-based CNS machines. Note that there never was any problem with
encrypted sessions *from* the Alphas, just to them (which usually
failed with complaints about time being out of sync, but not always).
: 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 t
: o have a multi-homed KDC, but multi-homed clients create some significant pr
: oblems (solved in Kerberos 5) that you can't easily address without knowing
: what interface packets will travel over.
I made no protocol changes. Instead, I bind client sockets to the
`primary' address of the machine. The primary address is adefined as
the first network interface returned by the SIOCGIFCONF ioctl that
doesn't have the address 127.0.0.1. The KDC simply makes sure that
its reply packets come from the address that the request was sent to
(i.e., it has a socket-per-interface, each bound to its interface, and
selects on them, very similar to what named does).
:
: 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.
How is supporting TCP, in addition to UDP, not backwards compatible?
We send a UDP packet, and try a TCP connection. Whichever gets a
response first wins.
If/when we convert to V5, a similar change will probably have to be
made to keep the firewall happy.
: Also, you should be able to only allow packtes to/from p
: orts 750, 751 and 88 and you should be fine.
Most packet filters are incapable of filtering based on both source
and destination port (particularly the high-speed ones, like Ciscos).
For authenticating to an outside realm, the UDP protocol requires that
we allow in UDP to random high-unnumbered ports. That's not an
acceptable answer when applied to all of our systems.
: 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
I am assuming that the Kerberos-aware rdist from the BSD distribution
is secure (if it isn't, please let me know). The only changes I'm
making are to resolve differences due to the CNS DES and KRB libraries
having a slightly different set of function names (but the same
functionality). The differences are not v4 vs v5, btw.
I wouldn't dream of trying to come up with a complete, secure protocol
on my own.
Dieter Dworkin Muller
