[3422] in Kerberos
Re: Kerberos and DCE
daemon@ATHENA.MIT.EDU (Dave Crocker)
Thu Jun 16 14:16:07 1994
To: pato@apollo.hp.com (Joseph N. Pato)
Cc: eric@atrium.com (Eric J. Rothfus), kerberos@MIT.EDU
Cc: dcrocker@Mordor.Stanford.EDU
In-Reply-To: Your message of Thu, 16 Jun 94 12:30:26 -0400.
<9406161630.AA20896@relay.hp.com>
Date: Thu, 16 Jun 94 11:04:56 -0700
From: Dave Crocker <dcrocker@Mordor.Stanford.EDU>
Joseph,
---- Included message:
You should not think of a DCE Kerberos server and an MIT Kerberos server.
You should think of a DCE Security server and a Kerberos server. DCE
You are suggesting terms of higher-level abstraction. That's a good idea,
I think. But in one case, you just use the term 'security' and in the
other you specify 'Kerberos' rather than, for example, "MIT Security server"
or "MIT Kerberos Security server". We should try to have the terms be
comparable.
security does more than just Kerberos authentication - but it does include
I was very much avoiding any discussion about the particular differences
between the two and especially not wanting to get into questions of
goodness. I took the original query to be about compatibility.
As Beta releases come from MIT, and product offerings come in the DCE,
there will be some differences in client machine file formats etc - but the
Simple summary: DCE Kerberos and MIT Kerberos are different and
use non-interoperable protocols. All of the rest is detail. The fact that
there are similar or even identical components/formats/etc. between the
two is irrelevant if they don't interoperate.
With respect to clients accessing the environment, they don't care which
system has been deployed. The AS and KDS are abstract servers that provide
Wrong. A client using DCE security cannot talk with an MIT Kerberos
server, unless the DCE client is ALSO supporting MIT Kerberos. This is
called 'dual stack' rather than "compatible".
authentication and can be accessed over the RFC 1510 protocol. It does
matter from an administration perspective which one has been deployed, but
In other words, the software doesn't care, but the people running things
need to? First, I consider that important, and second I consider it
wrong. The software needs to know which protocol set to use, MIT or DCE.
Applications don't have to support either DCE Kerberos or MIT Kerberos.
Applications have an application protocol. IF that protocol is based on
DCE RPC, then the application gets protected messages and authentication
Oh, gee. You mean that the application is unaware of the security model that
is in force? You mean that if the associated security service supports
authentication but not authorization, the application doesn't need to know
that? Then how the heck are differential security policies put into force
for different applications?
In either case, if the security
protocol is based on Kerberos, then the DCE Security server can be used as
the AS and TGS. An in either case - if the RPC authorization protocol is
Yup. The DCE Security Server from OSF supports both security protocol
sets. It is a dual stack server. That has nothing to do with protocol
compatibility and in fact means that product choices are limited.
Dave
