[3423] in Kerberos
Re: Kerberos and DCE
daemon@ATHENA.MIT.EDU (Joseph N. Pato)
Thu Jun 16 16:28:07 1994
Date: Thu, 16 Jun 1994 16:13:28 -0400
To: Dave Crocker <dcrocker@Mordor.Stanford.EDU>
From: pato@apollo.hp.com (Joseph N. Pato)
Cc: eric@atrium.com (Eric J. Rothfus), kerberos@MIT.EDU
At 11:04 6/16/94 -0700, Dave Crocker wrote:
> But in one case, you just use the term 'security' and in the
>other you specify 'Kerberos' rather than, for example, "MIT Security server"
>or "MIT Kerberos Security server". We should try to have the terms be
>comparable.
>
I chose my terms to try to highlight the differences between DCE and the
MIT Kerberos environments. In addition I used the terms that are generally
accepted in each community. The DCE community does not refer to a "DCE
Kerberos" server - because there is no such thing. There is a DCE Security
server that includes authentication and ticket generation; user account and
attribute registry; privilege (PAC Certification). In the "Kerberos"
community, there is a "Kerberos" server that implements an authentication
and ticket generation service.
I have not seen the MIT Kerberos environment called the "MIT Security
server" on this list or elsewhere.
> security does more than just Kerberos authentication - but it does include
>
>I was very much avoiding any discussion about the particular differences
>between the two and especially not wanting to get into questions of
>goodness. I took the original query to be about compatibility.
I didn't think I raised an issue of "goodness" - I simply stated that the
DCE Security server is more than a KDC supporting the AS and TGS protocols.
I wanted this clear so that a rationale for an independent code base is
established.
>
> As Beta releases come from MIT, and product offerings come in the DCE,
> there will be some differences in client machine file formats etc - but the
>
>Simple summary: DCE Kerberos and MIT Kerberos are different and
>use non-interoperable protocols. All of the rest is detail. The fact that
>there are similar or even identical components/formats/etc. between the
>two is irrelevant if they don't interoperate.
>
Both the DCE security server and the MIT Kerberos server include
implementations of the RFC 1510 protocol. As of DCE 1.0.3 and MIT Kerberos
V5 Beta 3, we believe both implementations use the same protocol and
interoperate. In the absence of a protocol validation suite it is
impossible to state that either one is correct and therefore that the two
fully interoperate. You will notice that bug reports come to this list and
krb5-bugs on a semi-regular basis like the GSSAPI incompatibility reported
by OpenVision today.
With respect to file formats, these are not part of the protocol - and are
not defined anywhere other than the code - and present potential deployment
issues when the client code for a kerberos protocol engine is deployed on a
machine. The only conflict I am aware of between DCE and the MIT
distribution is that until recently the MIT code had dropped support for
the beta-1 format credential file used by DCE. DCE will be moving forward
to the later format credential files and I believe that the MIT
distribution has picked up Digital's changes that re-enable support for the
beta-1 format files.
It is impossible, however, to make assertions about the file formats that
have been chosen by other commercial Kerberos vendors (but I suspect most
retained the MIT formats and therefore should be compatible).
> With respect to clients accessing the environment, they don't care which
> system has been deployed. The AS and KDS are abstract servers that provide
>
>Wrong. A client using DCE security cannot talk with an MIT Kerberos
>server, unless the DCE client is ALSO supporting MIT Kerberos. This is
>called 'dual stack' rather than "compatible".
>
I was a little imprecise here. I meant a client using the MIT distribution
does not care (since the DCE server listens to the RFC 1510 protocol over
UDP port 88)
As I went on to describe, a DCE client that does not request PACs can also
communicate over the UDP port 88 to a "vanilla" MIT Kerberos server. The
"krb5_sendto_kdc" function in the DCE is coded to attempt an RPC. If that
fails, it retains all of the conventional code for communicating with the
KDC over the UDP port (assuming that the local machine has been configured
with site and realm locating information - that is otherwise unnecessary in
the DCE).
The RPC protocol for the DCE is exactly the same bytes in bytes out
protocol defined in RFC 1510. The only difference is that it is using RPC
as a "transport" so that it can run over arbitrary transport protocols
(UDP, TCP, Decnet Phase V, ISO stacks) - anything that the RPC runtime
supports.
> authentication and can be accessed over the RFC 1510 protocol. It does
> matter from an administration perspective which one has been deployed, but
>
>In other words, the software doesn't care, but the people running things
>need to? First, I consider that important, and second I consider it
>wrong. The software needs to know which protocol set to use, MIT or DCE.
I stated that the administration is different - the DCE does not support
kadmin since there is no standard specification for the kadmin protocol. So
an administrator must use "rgy_edit" in the DCE to edit the principal
database - and in a kerberos environment, the administrator either uses
kadmin, or the commercial replacement for kadmin.
For the "end-user" of an application, there is no difference.
Software does not need to know which protocol to use - there is only one
application protocol for communicating with the KDC and that is defined in
RFC 1510. Both environments support this protocol over UDP port 88. In
addition the DCE environment will accept these message encapsulated in an
RPC over an arbitrary other set of transport protocols - but this fact is
invisible to application software.
>
> Applications don't have to support either DCE Kerberos or MIT Kerberos.
> Applications have an application protocol. IF that protocol is based on
> DCE RPC, then the application gets protected messages and authentication
>
>Oh, gee. You mean that the application is unaware of the security model that
>is in force? You mean that if the associated security service supports
>authentication but not authorization, the application doesn't need to know
>that? Then how the heck are differential security policies put into force
>for different applications?
I'm afraid I don't understand your issue here. For the functionality
defined by the RFC 1510 protocol, there are no differences. If the security
model for an application is satisfied by this then either system will
support the application. If the security model for the application uses
extended attributes in privilege attribute certificates etc. defined as
part of the DCE security model, then the application requires the DCE
sercurity server. (I will note that the DCE security model can be
implemented with a "vanilla" Kerberos KDC and an independent privilege
service obtaining forwardable tickets from the KDC - but I am unaware of
any implementations that do not have these two services co-resident in the
same process.)
>
> In either case, if the security
> protocol is based on Kerberos, then the DCE Security server can be used as
> the AS and TGS. An in either case - if the RPC authorization protocol is
>
>Yup. The DCE Security Server from OSF supports both security protocol
>sets. It is a dual stack server. That has nothing to do with protocol
>compatibility and in fact means that product choices are limited.
>
I lost you here. I'll grant you that it is "multiple" stacks, since the DCE
security server will listen to AS and TGS requests over a number of
transport protcols (UDP port 88 and RPC over arbitrary transports). The
"security" protocol, however, is exactly the same over each of those
transports.
I don't, however, see how this limits product choices.
- joe
