[3429] in Kerberos
Re: Kerberos and DCE
daemon@ATHENA.MIT.EDU (Eric J. Rothfus)
Thu Jun 16 21:18:05 1994
Date: Thu, 16 Jun 94 19:22:47 CDT
From: eric@atrium.com (Eric J. Rothfus)
To: pato@apollo.hp.com
Cc: kerberos@MIT.EDU, eric@atrium.com
Joe,
First off, thanks for the input. I couldn't quite pull the answer
I was looking for from your message (although it looks suspiciously
like the answer is "yes"). Let me formulate the question a little
better:
Given that the DCE "includes" kerberos, the idea is NOT to have
to install "another" kerberos server on my network. That is,
I'd like to use the kerberos embedded in DCE with my programs
which do not use DCE.
Assuming that:
- my non-DCE clients know how to talk to "a" kerberos server
- that there are no (hopefully) incompatibility issues
- the clients are smart enough to embed the kerberos info in their
own protocols
then is it possible to satisfy their kerberos needs with the kerberos
embedded in DCE (and used by the Security server)? In other words,
is the "DCE" kerberos also listening in the standard way to requests
coming from the outside non-DCE world.
Many issues come to mind, including "(if this works) does the "DCE"
kerberos get the passwords from the registry?"...
Eric
> 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
> security does more than just Kerberos authentication - but it does include
> kerberos authentication as a subset of its function.
>
> The only time you should think of these as different "Kerberos Servers" is
> when considering compatibilty. The DCE code is base on the MIT beta 1 code
> with changes to the protocol to be compatible with the format in RFC 1510.
> 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
> intention is to rationalize these as soon as possible. (e.g., DCE 1.1 has
> some MIT beta 3 code in it)
>
> 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
> authentication and can be accessed over the RFC 1510 protocol. It does
> matter from an administration perspective which one has been deployed, but
> it should not matter to an application.
>
> 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
> for free. If not, the application determines how to integrate the security
> protocol into its communication protocol. 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
> based on names instead of Privilege Attribute Certificates (PACs) - then
> the MIT Kerberos server can be used as the AS and TGS.
>
> Frequently we say that DCE requires the DCE Security server. This is true
> to support the DCE integrated login facilities and applications that choose
> the DCE authorization prtocols (using PACs) - but if neither of these cases
> apply, then the MIT server should be fine.
>
> **Caveat, at times bugs in either the MIT implementation or the DCE
> implementation have prevented inter-operability. As far as I know, DCE
> 1.0.3 works with MIT Kerberos V5 Beta 3 on the wire.
