RE: mapping identities RE: Compromise Authentication Proposal

[Christopher Oliva <Chris.Oliva@entrust.com>]

> > -----Original Message-----
> > From: Ed Reed [mailto:ed_reed@novell.com]
> > Sent: Friday, October 09, 1998 2:10 PM
> > To: Chris.Oliva@entrust.com; ietf-ldapext@netscape.com
> > Subject: RE: mapping identities RE: Compromise Authentication
> Proposal
> > 
> > 
> > For a variety of reasons, some implementation specific, some 
> > foundationally conceptual, I very much want to keep any 
> > access control policy that we wind up with internally 
> > consistent.  Doing that implies that names which are granted 
> > rights must be DNs known (meaning resolveable) to the LDAP 
> > namespace to which they're granted rights.
> 
> Other name forms than DNs are resolvable. Any attribute of an entry
> that is
> unique is resolvable.
> 
> I think we got a layering violation here. Application protocols don't
> define
> security principals -- security protocols do. If this WG wants to go
> to the
> CAT WG and ask for a Kerberos name form for DNs, they are welcome to
> do so.
> But until they do, we can't say that any authentication protocol has
> to
> support DNs for the user name. What we _can_ say (because we do
> directories)
> is that _the directory_ has to be able to map any user name form used
> in an
> authentication protocol into a DN.
> 
> Paul
> 
I'm not advocating a dog's breakfast of alternate name forms. However,
it may make sense to pick a few name forms which are commonly used
rather than relying on possibly unsecured mapping techniques or
embedding alternate name forms within DNs. There may be atleast one
alternate name form which would make a good candidate as an alternative
to DNs. (email address? OID (also heavily used by directories)?)

In any case alternate name forms have already been defined to name
subjects in certificates. Why would directory access controls also not
benefit from this?

Chris.