Subject: RE: name-type significance for principal name equality

From: [email-masked]
Date: Thu, 5 Sep 2002 18:21:20 -0400

Kerberos principal names have a name type *hint* which is NOT encoded
into the print form of any principal name.

Thus "[email-masked]" may be tagged as a host-based principal or a
user-based principal, or even an x.500 principal, or as a principal of
unknown type; whatever the type tag is, it is meaningless in the end.
Existing implementations may set it, but no two principal names may
exist whose components are the same, in the same realm but with
different name types (as the RFC puts it, the name type does not
partition the namespace).

So, for example, there is no option to MIT krb5's kadmin's add_principal
sub-command to set the principal name type.

This is what makes the GSS name types so obnoxious to us Kerberos types.
But see the last paragrapgh of this post.

Name type, schname types. All Kerberos names should be unique with
respect to each other, and all x.509 names should be unique with respect
to each other, and so on - ultimately one could encode the name type
into the name to distinguish between otherwise equal names, but that
just makes the names uglier. Fortunately usernames and *fully qualified*
hostnames tend to never conflict, thus there is no confusion in the
following Kerberos princ name examples:

 - [email-masked]
 - [email-masked]

Yes, there is redundancy, but that just happens to be a result of
agreement between a host's DNS domain name and its Kerberos REALM
name - I grant you that this is how one would generally want things
to be, and so the resulting redundancy in the names amounts to encoding
a name type in the principal name. AND YES, if one wishes to support
the use of short form hostnames then the two names given above MUST refer
to the same host and so the first one cannot be a username. This explains,
BTW, why in ActiveDirectory Computers are a sub-class of Persons and share
the namespace, thus one cannot have a computer object in AD whose short
form name conflicts with the name of a user in the same domain/tree/... as
AD KDCs support short form name aliasing (with or without canonicalization
in the TGS exchange).

For a GSS-type API it would have been, IMO, much better to have a mech-
independent way to construct names which does not require a single
canonical GSS name form tagged with a GSS name type. Think of a function
with optional user name, service name, host name and realm/domain name
arguments - clearly some combinations might make no sense, but at least
it would work better than what we've got now and it would still be mech-
independent, and the underlying mech provider would have the necessary
hints. Currently, the gss user name type encodes no realm/domain
information, which makes it useless in a multi-realm situation;
fortunately there's the exported name forms. Besides, this would have
allowed "realm/domain-based" names (TGS names are realm based), which
would have been ideal for services such as LDAP. And it isn't entirely
meaningless to mix a username, a service name and a realm name; think of
U2U auth - the service name might turn out to be unused by a given mech,
but some other mech might actually make use of it.)

Cheers,

Nico
-- 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.