[6014] in Kerberos
Re: kerberos v4 or v5 on osf 3.2
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Oct 17 11:18:26 1995
To: Dieter Muller <dworkin@suod.cs.colorado.edu>
Cc: Sam Hartman <hartmans@MIT.EDU>, kerberos@MIT.EDU
In-Reply-To: Your message of "Tue, 17 Oct 1995 07:01:26 MDT."
<199510171301.HAA29066@suod.cs.colorado.edu>
Date: Tue, 17 Oct 1995 11:00:29 EDT
From: Sam Hartman <hartmans@MIT.EDU>
>>>>> "Dieter" == Dieter Muller <dworkin@suod.cs.colorado.edu> writes:
Dieter> Sam Hartman writes: : >>>>> "Dieter" == Dieter Muller
Dieter> <dworkin@suod.cs.colorado.edu> writes: : : : Dieter> plays
Dieter> well on a homogeneous network, there are some : Dieter>
Dieter> definite problems on multi-platform networks, particularly
Dieter> : : I find this somewhat hard to believe. I have been
Dieter> establishing encrypt : ed sessions with Dec Alphas from
Dieter> 32-bit machines, where the 32-bit machines : are running
Dieter> either CNS or Athena Kerberos, and the Alpha is running
Dieter> somethin : g very close to CNS. Our KDC is on a
Dieter> decstation, and it works from architec : tures of varying
Dieter> byte order and word size.
Dieter> The problems we were seeing were the inability to
Dieter> establish encrypted sessions to the Alphas from non-Alpha
Dieter> systems (Solbournes, to be precise, but the problem should
Dieter> also happen with sun4s). The bug is several instances of
Dieter> `long' in various over-the-wire data structures. The
Dieter> change was to change the longs to KRB_INT32s. The
Dieter> resulting code works between sun4s, Solbournes, and
Dieter> Alphas, as well as with 1992-based CNS machines. Note
Dieter> that there never was any problem with encrypted sessions
Dieter> *from* the Alphas, just to them (which usually failed with
Dieter> complaints about time being out of sync, but not always).
Were you using the latest CNS (95q1)? I know there were bugs,
but I thought Cygnus already released fixes? The reason I ask about
this is that version already includes a port of the BSD rdist. The
reason I thought you were doing something new as that the BSD rdist
code already had been ported to CNS.
Dieter> : Dieter> - Supports multi-homed clients and KDCs. : :
Dieter> You cannot do this without violating the protocol or :
Dieter> significantly decreasing the security of Kerberos. It's
Dieter> actually possible t : o have a multi-homed KDC, but
Dieter> multi-homed clients create some significant pr : oblems
Dieter> (solved in Kerberos 5) that you can't easily address
Dieter> without knowing : what interface packets will travel over.
Dieter> I made no protocol changes. Instead, I bind client
Dieter> sockets to the `primary' address of the machine. The
Dieter> primary address is adefined as the first network interface
Dieter> returned by the SIOCGIFCONF ioctl that doesn't have the
Dieter> address 127.0.0.1. The KDC simply makes sure that its
Dieter> reply packets come from the address that the request was
Dieter> sent to (i.e., it has a socket-per-interface, each bound
Dieter> to its interface, and selects on them, very similar to
Dieter> what named does).
Ok, I wasn't thinking: I generally look at things from
the viewpoint of the Kerberos library, which can't manage the client's
network connections. If you hack all the clients, this canwork.
Dieter> : Dieter> - Encrypted rdist (using the 4.4 BSD rsh/rshd
Dieter> modified to : Dieter> use the Cygnus libraries). : :
Dieter> Unless you have significant experience designing secure :
Dieter> protocols, I strongly advise against this. You may
Dieter> develop a false : since of security, assuming that your
Dieter> connections are secure; it is : likely that the obvious
Dieter> schemes for doing encrypted rsh/rdist can be
Dieter> I am assuming that the Kerberos-aware rdist from the BSD
Dieter> distribution is secure (if it isn't, please let me know).
Dieter> The only changes I'm making are to resolve differences due
Dieter> to the CNS DES and KRB libraries having a slightly
Dieter> different set of function names (but the same
Dieter> functionality). The differences are not v4 vs v5, btw.
I haven't looked at the code enough to comment. It did make it into CNS, possibly with changes; I would certainly look at their Changelog.
Dieter> Dieter Dworkin Muller