[3427] in Kerberos
Re: Kerberos and DCE
daemon@ATHENA.MIT.EDU (Dave Crocker)
Thu Jun 16 19:22:24 1994
Date: Thu, 16 Jun 1994 16:05:10 -0700
To: pato@apollo.hp.com (Joseph N. Pato)
From: dcrocker@mordor.stanford.edu (Dave Crocker)
Cc: eric@atrium.com (Eric J. Rothfus), kerberos@MIT.EDU
Joseph,
The beginning of your most recent message went on at some length about
nomenclature and explaining that DCE security has more functionality than
MIT's base Kerberos system. Let me reiterate that none of that has
anything to do with the question of interoperability; hence, there's no
benefit in pursuing such detail.
At 1:13 PM 6/16/94, Joseph N. Pato wrote:
>Both the DCE security server and the MIT Kerberos server include
>implementations of the RFC 1510 protocol. As of DCE 1.0.3 and MIT Kerberos
There is a difference between specifications and implementations. What is
true is that OSF's implementation of a security server supports both the
DCE security service and the MIT Kerberos service. These are two services,
not one.
>V5 Beta 3, we believe both implementations use the same protocol and
>interoperate.
This belief is understandable, but it is incorrect. The fact that the DCE
service runs over RPC, while the MIT services runs over raw UDP, and that
the DCE service added the authorization parameter information makes the two
services non-interoperable. It's really that simple. Change syntax and/or
semantics and you render a protocol non-interoperable.
>I was a little imprecise here. I meant a client using the MIT distribution
>does not care (since the DCE server listens to the RFC 1510 protocol over
>UDP port 88)
As I said, the OSF DCE security server supports two security services, one
for DCE and the other for MIT Kerberos. Dual stack isn't interoperable.
>As I went on to describe, a DCE client that does not request PACs can also
>communicate over the UDP port 88 to a "vanilla" MIT Kerberos server. The
As I said, a client that talks both the DCE security protocol (e.g., using
RPC) might also be able to talk raw MIT Kerberose (e.g., using UDP) but
that is dual-stack pure and simple. The client is aware of two protocols
and must choose betwen them.
>If that
>fails, it retains all of the conventional code for communicating with the
...(I believe that the line above this contradicts the line below)...
>Software does not need to know which protocol to use - there is only one
>application protocol for communicating with the KDC and that is defined in
>RFC 1510. Both environments support this protocol over UDP port 88. In
I guess you believe that the authorization enhancement isn't part of the
"protocol". I disagree. The "protocol" is the collection of formats,
exchange rules and semantics required for two parties to interoperate.
Authorization isn't in MIT's stuff and IS in DCE's, hence there is an
incompatiblity at the application level, as well as one at the
transport/session level.
>I'm afraid I don't understand your issue here. For the functionality
>defined by the RFC 1510 protocol, there are no differences.
Right. As long as the application doesn't use the DCE enhancement
(authorization) things are the same. But what if it does use the
enhancement?
Dave
+1 408 246 8253 (fax: +1 408 249 6205)
