[1603] in Kerberos
Re: DCE kerberos vs. MIT
daemon@ATHENA.MIT.EDU (Joe Pato)
Tue Oct 8 17:25:02 1991
From: pato@apollo.com (Joe Pato)
Date: Tue, 8 Oct 91 16:26:34 EDT
To: smb@ulysses.att.com
Cc: athey@lorien.ocf.llnl.gov (Charles L. Athey III), kerberos@Athena.MIT.EDU
In-Reply-To: smb@ulysses.att.com, tue, 8 oct 91 15:39:47
I'm not sure if you're allowed to answer this or not, but... Will DCE
provide ``over-the-wire'' compatibility with Kerberos V5? That is,
can a user on a stock MIT V5 system authenticate him/herself to a
DCE system?
Yes, DCE Kerberos V5 meets the "over-the-wire" protocol established in
the Kerberos V5 RFC draft #4+. Cliff Neuman recently distributed some small
protocol changes to draft 4 for MD5 and principal name type support. We have
included support for this change (and made some trivial corrections in the
ASN.1 that Cliff had sent out to the kerberos-protocol mailing list). N.B. that
this change in protocol prevents on-the-wire inter-operability with the current
MIT beta 1 code.
Yes a user on a stock MIT V5 system can communicate with the DCE KDC and obtain
tickets for target services on a DCE machine. Even an application running on a
DCE machine but bound with a stock MIT client library is "likely" to
communicate with the local (or remote) KDC (n.b. my previous caveat about
evolving MIT code).
If by the term "authenticate him/herself to a DCE system" you mean that the
client will be able to authenticate to any of the basic DCE services (e.g.,
name service or file system or time service or user registration service)
or login to a machine, then no - a client using a vanilla MIT V5 system will
not be able to authenticate itself. The DCE Security service (privilege
server component) is needed to fill in authorization data in the tickets for
these servers. A client presenting a ticket without the proper authorization
data is interpreted as an unauthenticated client.
- joe
-------
