[3420] in Kerberos
Re: Kerberos and DCE
daemon@ATHENA.MIT.EDU (Joseph N. Pato)
Thu Jun 16 13:15:29 1994
Date: Thu, 16 Jun 1994 12:30:26 -0400
To: dcrocker@mordor.stanford.edu (Dave Crocker),
eric@atrium.com (Eric J. Rothfus)
From: pato@apollo.hp.com (Joseph N. Pato)
Cc: kerberos@MIT.EDU, eric@atrium.com
I don't share Dave's interpretation below.
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.
At 18:36 6/15/94 -0700, Dave Crocker wrote:
>I, too, am interested in hearing the details of actual use.
>
>For reference...
>
>At 9:00 AM 6/15/94, Eric J. Rothfus wrote:
>>connecting Kerberos clients to DCE cells. That is,
>
>In reality, the client is not connecting to a "DCE cell". The
>client is connecting to a server that performs dual functions,
>one as a DCE Kerberos server and the other as an MIT Kerberos V5
>server. They really should be treated as independent services,
>in spite of the fact that the functionality is shared within
>a single code/machine set.
>
>>allowing non-DCE, but kerberos "enabled", clients to
>>connect to a DCE cell (and the underlying kerberos)
>>to obtain authentication tix. The goal is to allow
>
>Except that it also requires that the application server (i.e., the
>OTHER Kerberos client) to do one or the other. If a given application
>chooses to support both DCE Kerberos AND MIT Kerberos, fine, but
>again, that server is simply running a dual stack of security stuff.
>
>
>Dave
>
>+1 408 246 8253 (fax: +1 408 249 6205)
- Joe Pato
Hewlett-Packard Co.
pato@apollo.hp.com
