[1606] in Kerberos
Re: DCE kerberos vs. MIT
daemon@ATHENA.MIT.EDU (Joe Pato)
Tue Oct 8 18:27:05 1991
From: pato@apollo.com (Joe Pato)
Date: Tue, 8 Oct 91 17:45:47 EDT
To: smb@ulysses.att.com
Cc: kerberos@Athena.MIT.EDU
In-Reply-To: smb@ulysses.att.com, tue, 8 oct 91 16:48:48
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.
I'm not quite sure how to interpret what you just said. There are three
players -- the client, the service, and the KDC. Are you saying that
DCE services will only accept tickets prepared by DCE KDCs? Can a
vanillia client request a ticket from a DCE KDC? Can it do so through
inter-realm authentication? Can a DCE client request a ticket for
a vanilla service from a vanilla KDC? I'm trying to understand the
compatibility matrix here...
First a digression. It is important to remember that all DCE services use
DCE-RPC. So, to communicate with base DCE services you will need to use
DCE-RPC. DCE-RPC supports two types of authorization models - name based or
PAC (Privilege Attribute Certificate) based. Name based authorization uses a
conventional V5 ticket. PAC based authorization places the user's identity
information inside a PAC sealed in the authorization data area of the V5
ticket. The ticket used in this case is a forwarded ticket in the name of the
privilege server - it is not a direct ticket from the initiating principal.
The initiating principal's identity appears in the authorization data area.
The DCE protocol is designed to allow a vanilla MIT KDC to do this in
conjunction with a free standing privilege server, but there is no
implementation available that uses a vanilla MIT KDC in this way. Therefore,
you need a DCE KDC (which has the privilege server rolled into it) to do this.
The point of the digression is that vanilla applications dont talk to DCE
services. They need to use both DCE-RPC and the DCE Security service.
Vanilla applications, however, can use either an MIT KDC or a DCE KDC. Both
implementations export the same wire protocol (DCE applications communicate
with the DCE KDC using RPC, but the DCE KDC also listens to MIT protocol
messages over the "standard" MIT UDP port. DCE clients will also use the MIT
UDP protocol when talking to a vanilla KDC.) Either flavor of KDC can be used
for inter-realm authentication.
- joe
-------
