Re: [Ietf-krb-wg] the PKU2U DN to Kerberos Principal name mapping

[Martin Rex <Martin.Rex at sap.com>]

Jeffrey Hutzelman wrote:
> 
> --On Monday, January 28, 2008 05:55:04 PM -0600 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> 
> > I'm not sure that we actually want GSS_Compare_name() to sport such
> > behaviour, as opposed to having a new function that does, because it's
> > pushing things a bit to say that the two NAME objects passed to it are
> > equal representations of the same principal.  They are representations
> > of the same principal name, just not _equal_ representations of it.
> 
> That's OK.  GSS_Compare_name is defined to return a true result when the 
> names represent the same entity, not only when they are the same.  This 
> appears to be exactly what GSS_Compare_name is for, so no, I don't think we 
> need a new interface for this.

Personally, I would prefer to see a new API instead of seeing an
existing API being frobbed in such new ways.

A possibility to extract all sorts of attributes from Certificates
besides the Subject DName (and in particular for Kerberos mechanisms)
is extremely non-portable and may often not even locally work
in a (application-provider) predictable fashion.

Example: although the nametypes User Name Form (GSS_C_NT_USER_NAME)
and Machine UID Form (GSS_C_NT_MACHINE_UID_NAME) are
specified at the generic level (rfc2743), the translation of
any such name into an authenticated identity is fairly unspecified,
and not just implementation defined, but in addition may depend
on local configuration.

In MIT Kerberos, there might be a "tradition" (resulting in some
level of expectation) that a username or uid is mapped to
a Kerberos principal name by appending some realm name, but
from the GSS-API perspective, it would be ok if acquisition of
credentials for an "OS username" or and "OS userid" would
resolve to the "default" credentials of that user.  Depending
on whether the current process is running as the specified
user or for someone else the name translation outcome may differ
or even fail.

IIRC, DCE allowed an explicit mapping table between the DCE principal
name and a local account name, and Microsoft W2K workstations
joined to a vanilla Kerberos KDC also allow/require an explicit
local mapping between local accounts and Kerberos principals
from vanilla Kerberos KDCs.

With new, explicit API calls it is much easier to define
how any fancy new name translation functionality can be made to work
in a fashion that is portable/predictable accross different independent
implementations of a gssapi mechanism, and to distinguish
gssapi implementations that support this extensions and those
that don't.


-Martin
_______________________________________________
Kitten mailing list
Kitten at ietf.org
http://www.ietf.org/mailman/listinfo/kitten