MIT Kerberos vs DCE-Kerberos
Mike Friedman
fairly soon; we already have a campus application that is V4-based and will
be using our Kerberos server. At some point, our plan is to upgrade to V5.
However, a new, large, application may be coming along that would require us
to support DCE-Kerberos. This is because the application vendor code isn't
itself kerberized; rather, it interfaces to another vendor's 'middleware'
platform, which talks to DCE services. In particular, authentication would
be done via DCE-Kerberos.
So, I'd like some (objective) information that would help me understand what
we'd be getting into if our management decides to acquire the aforementioned
application along with the DCE-oriented middleware interface to Kerberos.
For example,
o What are all the areas of incompatibility between DCE-Kerberos and MIT
Kerberos V5? I am familiar in general terms with some of them, but would
like as complete a picture as possible.
o None of us here has any experience with DCE at all. Given that (in the
near term at least), our only interest in DCE would be with respect to
Kerberos authentication, I'd like to know what kind of effort is involved
in supporting a DCE environment just to obtain the authentication services?
(a) Vendor issues. Who supplies DCE and what is the quality of support?
(b) Available platforms -- operating system and hardware.
(c) Expertise, training and ongoing staff resources required on our part
for ongoing support. Would we need to learn much about DCE as a
whole just to support the Kerberos part?
o With respect to my first item above, is anyone working on resolving the
technical incompatibilities between MIT K5 and DCE-Kerberos, so that, for
example, one could run MIT K5 servers and authenticate DCE-based clients
(as well as MIT K5 and K4 kerberized clients)?
Thanks for whatever information anyone can provide.
------------------------------------------------------------------------
Mike Friedman mi...@ack.Berkeley.EDU
Data Communication & Network Services +1-510-642-1410
University of California at Berkeley http://www.Berkeley.EDU/~mikef
------------------------------------------------------------------------
Jon Mauney
>o What are all the areas of incompatibility between DCE-Kerberos and MIT
> Kerberos V5? I am familiar in general terms with some of them, but would
> like as complete a picture as possible.
From the DCE FAQ:
Q 29: Does DCE Security interoperate with other Kerberos systems?
Basically, no, or maybe yes, depending on what you want to do.
To use authenticated DCE services, you must have credentials from
the DCE security service; vanilla Kerberos v5 tickets aren't sufficient.
But then, to use DCE services you must be using DCE RPC, so this
is not really a problem.
Going the other way, it is expected that a DCE security server
can issue tickets that can be used by vanilla Kerberos applications.
The OSF was wary of promising this until the Kerberos v5 specs were
published, but now that the Kerberos RFC has been published, OSF
anticipates guaranteeing interoperability sometime "soon".
In a little more detail, the way to think about this is as follows:
Kerberos offers 2 services (Authentication Service, Ticket
Granting Service) over 1 communication mechanism (UDP port 88).
DCE security offers 3 services (AS, TGS, Privilege Service) over
2 communication mechanisms (UDP port 88, RPC).
Where Kerberos and DCE security intersect (AS, TGS over UDP port
88), the services are identical.
> (a) Vendor issues. Who supplies DCE and what is the quality of support?
> (b) Available platforms -- operating system and hardware.
DCE is supported on most Unix platforms, as well as (Open)VMS,
OS/2, Windows NT, etc. General DCE is sold and supported by the OS vendor,
but Digital and Gradient have products for Windows NT, Transarc sells
DCE for Solaris.
It will cost you on the order of $5k for the DCE servers. Runtime client
licenses will be needed for all the hosts that run the DCE-based product;
runtime licenses are now fairly cheap and often bundled with the OS.
>o With respect to my first item above, is anyone working on resolving the
> technical incompatibilities between MIT K5 and DCE-Kerberos, so that, for
> example, one could run MIT K5 servers and authenticate DCE-based clients
> (as well as MIT K5 and K4 kerberized clients)?
You'll have to do it the other way around: DCE security providing
support for MIT k5 clients. DCE v1.1 supports the GSSAPI
(Generic Security Service Application Program Interface )
--
Jon Mauney j...@mauney.com
Mauney Computer Consulting (919) 828-8053
Raleigh NC
"Have TGT, will travel."
Mike Friedman
: mi...@ack.berkeley.edu (Mike Friedman) writes:
: >o With respect to my first item above, is anyone working on resolving the
: > technical incompatibilities between MIT K5 and DCE-Kerberos, so that,
: > for example, one could run MIT K5 servers and authenticate DCE-based
: > clients (as well as MIT K5 and K4 kerberized clients)?
: You'll have to do it the other way around: DCE security providing
: support for MIT k5 clients. DCE v1.1 supports the GSSAPI
: (Generic Security Service Application Program Interface )
So, I guess this means that if our campus acquires the aforementioned large
application, we must move to DCE. But we also need to run K4, because of
the other application I mentioned (which is based on Cornell's Mandarin
system and is currently K4-based). I'd like to avoid having to run DCE
*and* K4. If MIT K5 could authenticate DCE-based applications, then,
since K5 also can issue K4 tickets, one Kerberos could do the job. That's
why I asked the question the way I did. (I'm assuming that DCE security
can't support K4 clients; is this correct?).
I've seen your DCE FAQ, which is useful. Do you have any pointers to other
online introductory DCE material?
Thanks.
Rich Salz
>So, I guess this means that if our campus acquires the aforementioned large
>application, we must move to DCE.
Well, it depends on what you mean by "move to." If app requires DCE then you
must install DCE on all would-be client hosts, and create principals for everyone
who is going to use the app. (Or create one principal and have all users act
as one. Bad idea.) How much DCE you need to install depends on what the app uses.
You need the security server, probably the namespace server (CDS); you probably
do not need the time server.
What's the app; can you say?
>If MIT K5 could authenticate DCE-based applications, then,
Can't be done. DCE authentication uses way more then KRB tickets.
>(I'm assuming that DCE security
>can't support K4 clients; is this correct?).
Yup, you're correct.
Sounds to me like you've got a tricky problem if you don't want to
run both Krb4 and (krb5-based) DCE. There are many reasons why you
don't want to do that. You *might* be able to write some k4 gateway
that just forwards to the k5 server...
>Do you have any pointers to other
>online introductory DCE material?
Among other places, http://www.osf.org:8001/, look for the DCE reference(s).
/r$
Dave Crocker
compaction of the previous response...:
DCE Kerberos really is different from MIT Kerberos. It offers an
additional function (authorization) and it runs over a different stack (DCE
RPC, rather than "raw" TCP.) It does not "interoperate" with MIT Kerberos.
They are not compatible.
HOwever, DCE Kerberos KDCs can do both DCE Kerberos and MIT Kerberos. This
is simple, "dual stack" operation.
If you need to support DCE apps, you need a DCE KDC. If you don't, an MIT
Kerberos KDC ought to be just fine.
d/
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 dcro...@networking.stanford.edu