[3163] in Kerberos
Re: Kerberos Users' Frequently Asked Questions 1.9
daemon@ATHENA.MIT.EDU (Joseph N. Pato)
Fri Apr 22 14:20:30 1994
Date: Fri, 22 Apr 1994 13:32:00 -0400
To: bjaspan@cam.ov.com (Barry Jaspan), kerberos@MIT.EDU
From: pato@apollo.hp.com (Joseph N. Pato)
At 12:27 4/22/94 -0400, Barry Jaspan wrote:
>
>(1.7) How/why is OSF DCE Security different from MIT Kerberos V5?
> Can they interoperate?
>
>DCE Security is based on Kerberos V5, and uses the same wire protocol.
>However, applications from two systems use the protocol in different
>ways, so the actual interoperability is limited. Furthermore, DCE
>Security started from an early alpha release of V5 and the two
>versions have developed independently; there are therefore some minor
>incompatibilities that MIT and the OSF have agreed to resolve. [Time
>frame?]
>
>The DCE Security Server, secd, listens on UDP port 88 for standard
>Kerberos requests and responds appropriately. Therefore, clients of
>MIT Kerberos can operate in a DCE environment without modification,
>assuming the DCE Security database contains the appropriate principals
>with the correct keys.
>
>An MIT Kerberos V5 server cannot replace the DCE Security Server,
>however. First, DCE applications communicate with secd via the DCE
>RPC. Second, the DCE layers additional functionality on top of the
>standard application request/response protocol exchange and uses
>ticket semantics that are nonsensical in a strict Kerberos
>environment. The MIT Kerberos server does not understand either of
>these changes, and therefore cannot support them.
>
>As an additional complication, the DCE does not officially export the
>Kerberos V5 API; it only exports a DCE Security-specific API.
>Individual vendors are capable of providing the Kerberos V5 API if
>they wish, but unless they all do (which seems unlikely) Kerberos V5
>API applications will not be compile-time portable to pure DCE
>environments; only binaries will continue to work.
>
>[Does secd provide all features of the MIT Kerberos server? Is it
>guaranteed to do so?]
>
Barry,
"nonsensical" ticket semantics is a little severe. DCE clients obtain
normal TGTs with normal Kerberos principal names. In addition, DCE
applications will generally obtain other tickets that contain information
for use in a DCE authorization information (called a PAC - Privilege
Attribute Certificate). These tickets are forwarded tickets from a
privilege server that use the standard V5 authorization data field to
record privileges (including identity information represented via universal
unique identifiers (UUIDs)) for the user.
A DCE client requires the presence of a privilege server in the environment
when it uses DCE authorization (which is used for access to base DCE
services like the naming service, file system, security database, etc.) It
is possible to implement a Privilege Server (PS) that is independent of the
KDC (there is a well defined protocol for how to do this using the standard
V5 protocol for communication between the PS and the KDC - which is
described in the DCE Security AES which is currently under review by
X/OPEN). There are, however, no implementations of a split PS/KDC that I am
aware of.
I am working on getting the OSF to commit to inter-operability testing with
vanilla Kerberos and will let you know about dates when that is approved.
- joe
p.s., hope things are going well for you in Cambridge. I have seen that you
have gone through Beta with OV*Secure - congratulations!
- joe
