[3241] in Kerberos
Re: Kerberos and DCE
daemon@ATHENA.MIT.EDU (Jonathan Chinitz)
Thu May 5 17:41:38 1994
To: uunet!cs.umass.edu!doyle@uunet.UU.NET
Cc: kerberos@MIT.EDU
In-Reply-To: <2qb7tc$7oq@opine.cs.umass.edu>
Date: Thu, 05 May 94 15:50:58 -0400
From: Jonathan Chinitz <jec@isoft.com>
On 5 May 1994 16:46:36 GMT uunet!merlot.cs.umass.edu!doyle wrote:
[stuff deleted]
> In the not to distant future, the entire company will be running DCE on
> almost all of the HP, IBM RS6000 and Alpha machines. We would like to be
> able to modify the Kerberos-based administrative environment to work
> with DCE so that we can get tickets from the DEC secd. That is, we want to
> be able to use rlogin, rcp and rsh to get root access to hosts on the net
> for the sake of Unix system administration.
>
> Does anyone have such plans in the work? Should I be able to simply
> compile the Kerberos 5 distribution bsd applications and expect them to
> interoperate with the DCE security service?
>
> -- Jim Doyle <doyle@oec.com>
>
I noticed in your note that you said V4 - DCE secd does not listen to
the V4 port (750) but only to the V5 port (88), so I think you're out of luck there.
As far as getting tickets from a DCE (not DEC) secd and
interoperability of V5 with secd, I have attached a response from Joe
Pato (HP) to this list that he posted a few weeks back.
With respect to the modification of the administration tools, DCE secd
will support kerberos style principal names, etc. If your tools make V5
requests (and not V4 ones) then you should be able to get tickets for
them and use them. You would stil be working with the kerberized
versions of the servers (klogind, kshd) etc.
You might want to ask Transarc (your SunOS and Solaris DCE provider)
about their DCE version of rexecd, upon which a DCE'ized rlogin/rsh can be built.
Jonathan Chinitz
IntelliSoft Corp.
508-635-9070
jec@isoft.com
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
