[1607] in Kerberos
Re: DCE kerberos vs. MIT
daemon@ATHENA.MIT.EDU (Bill Sommerfeld)
Wed Oct 9 16:14:49 1991
Date: Wed, 9 Oct 91 13:20:54 EDT
From: sommerfeld@apollo.com (Bill Sommerfeld)
To: kerberos@Athena.MIT.EDU
It is also worth pointing out that there is nothing stopping a host
from running both DCE services and non-DCE services, or being a client
of both DCE and non-DCE services.
I've seen a fair bit of confusion on this list regarding the relation
of kerberos V5 with DCE security.
We've "sandwiched" kerberos V5 inside DCE -- DCE security is, strictly
speaking, layered on, not "an extension to", kerberos V5, as some
people at OSF have mistakenly claimed.
We have layered the kerberos ticket granting protocol on top of DCE
RPC, to allow DCE security to be used on systems which don't support
UDP/IP; our implementation of the kerberos library allows you to use
either DCE RPC or UDP/IP to get tickets.
Currently, we are not including any of the kerberos applications from
the MIT distribution in the sources we're shipping at the moment. DCE
source licensees should be able to extract these from the MIT
distribution. build them, and bind them with the DCE libraries, and
have them "just work", although we don't have the horsepower at the
moment to actually test this.
Binary licencees are up to the discretion of their supplier as to
whether they have access to the raw kerberos API; if you don't, you'll
have to get and port the full MIT distribution yourself, and it should
be able to communicate with the DCE implementation of the KDC (if it
doesn't, it's a bug).
Note that if we do bundle the kerberized applications from MIT with
the DCE source tree, that doesn't really make them "DCE
applications" -- we'll just be passing them through modulo makefile
rewrites and porting fixes for our reference platforms.
- Bill
