[6160] in Kerberos
Re: How to make V5 and V4 work together
daemon@ATHENA.MIT.EDU (Jonathan Chinitz)
Tue Nov 7 21:59:16 1995
Date: Tue, 7 Nov 1995 21:42:35 -0400
To: "Theodore Ts'o" <tytso@MIT.EDU>
From: jec@isoft.com (Jonathan Chinitz)
Cc: Jie Wang <jiewang@leland.Stanford.EDU>, kerberos@MIT.EDU, walt@osf.org
At 4:08 PM 11/7/95, Theodore Ts'o wrote:
> Date: Thu, 26 Oct 1995 19:18:42 -0700 (PDT)
> From: Jie Wang <jiewang@leland.Stanford.EDU>
>
> We will install DCE for our systems. Since we are
> currently using Kerberos 4 for our AFS, we need to let DCE security
> (which is of Kerberos 5 type) to work compatibly with our Kerberos 4.
> Would you please tell me who is the best person to ask for
> these information?
>
>Unfortunately, as far as I know --- you don't. When I complained to OSF
>about this several months ago, they explained that they didn't think
>there was enough of a market to worry about this kind of backwards
>compatibility. Unfortunately, that means if you're Transarc customer,
>or have your own Kerberos V4 realm, you're Sadly Out of Luck. The only
>thing you can really do is complain to your vendors --- loudly. If
>there's enough complaints, maybe OSF will change their mind.
>
Doug Engert from ANL gave a very inspiring presentation today at the DCE
SIG about his work in this area. He has managed to put together some
interesting interoperability scenarios involving V4, V5, AFS, DFS, and DCE.
If you chat with him you will find that this whole area is not just as
simple as it is made to sound in this note.
>As far as I'm concerned, if OSF had but made two simple design
>decisions, long ago, this situation would have been much simpler to deal
>with. (1) DCE applications currently use the DCE RPC to get their
>Kerberos tickets, and their Privelege Tickets. They should have used
>the standard, RFC-1510-defined UDP port 88 protocol. (2) OSF should
DCE Security is defined in an AES document. Today it uses private key based
on V5. Tomorrow it might be something else. Communication in DCE is based
on DCE RPC with interoperability acorss a wide spectrum of transports, UDP
being just one of them. The DCE security server listens to vanilla V5
requests off of 88 so that it can be used as the KDC for V5 clients that do
not wish to use DCE RPC.
>have released the code necessary to cons up a Privlege ticket and made
>it freely available. If both of this were true, it would have been
>possible for someone who wanted V4 backwards compatibility to simple use
>a MIT-supplied Kerberos V5 KDC, and it could serve as a drop-in
>replacement for a DCE security server. (After all, OSF/DCE is
>theoretically an open architecture, right?)
>
Again, a slight oversimplification. Privilege tickets and their
authorization data are based on uuids, not names. I fail to see where this
has anything to do with open architectures. My definition of open (and lord
knows there are quirte a few floating around) is a common source base that
has an AES and is licensable. DCE complies with that definition to the
letter.
>Unfortunately, that's not the way the world works, and so life is a lot
>more complicated for people who actually care about keeping AFS and
>other legacy Kerberos V4 apps running. (Besides, everyone is supposed
>to use DFS, the greatest thing since sliced bread --- right? :-)
>
Yeah, try it -- you actually might like it :-)
-Jonathan
Jonathan Chinitz E: jec@isoft.com
IntelliSoft Corp. URL: http://www.isoft.com
P.O. Box 2645 V: (508) 635-9070
Acton, MA 01720 F: (508) 635-9210
