[6014] in Kerberos

home help back first fref pref prev next nref lref last post

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


home help back first fref pref prev next nref lref last post