RE: mapping identities RE: Compromise Authentication Proposal

[Ed Reed <ed_reed@novell.com>]

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.

DNs may be defined in directories not held locally (I'm presuming a distributed LDAP environment here, not a server-exclusive one).  But those names need to be resolveable to the policy enforcement function.

I don't believe that access control information that specifies arbitrary regular expression wild cards will pass the test "tell me who has what rights here", and so I don't like those, either.

With regard to using alternate names in ACI information - that's the same as using aliases, it seems to me.  If you allow it, you know you'll incur possibly horrible performance penalties for some operations (she logged in with an alias this time, but not the same one the ACI information uses, so the login has to get the canonicalized identity (DN) for her...which is okay, but then the ACI should always be resolved to the canonicalized entry, too...else how will you marry betty lou up to the aci information that grants Elizabeth rights to do something?)

If we want to create a system that is conceptually and internally consistent - useful properties for any security related system - let's keep it simple for the policy audit, evaluation, and enforcement systems.

I take the cited paragraph to mean that if a server supports mappings of arbitary strings to DNs, it must also support DNs which don't require such mappings (ie, which are directly resolveable to the subject name of the certificate).  Right?

Ed

<<< Christopher Oliva <Chris.Oliva@entrust.com> 10/ 9  8:37a >>>
I'm a little concerned with section 9.1 of the document to which you
refer. I think there is room to clarify the situation with respect to
mapping of identities and what is meant by the statement "A server which
supports mappings of names MUST be capable of being configured to
support certificates for which no mapping is required." I assume what
this means is that the "subject name" of the certificate does not need
to be mapped to an entry DN.

Furthermore, certificates may contain the subjectAltName extension
field. This allows the "subject name" to be specified in a variety of
alternate (non distinguished name) formats such as email address, ip
address, OID etc. What I'm suggesting is that no mapping of these names
should be required to a DN or entry within the directory system and that
the ldap access controls allow the configuration of authorization
identities based on the subjectAltName. Also note that a certificate may
contain multiple subjectAltNames and/or subject name and that each of
those unambiguously identify the subject.

Chris.

> ----------
> From: 	Jeff.Hodges@stanford.edu[SMTP:Jeff.Hodges@stanford.edu]
> Sent: 	Thursday, October 08, 1998 4:18 PM
> To: 	ietf-ldapext@netscape.com
> Subject: 	Re: mapping identities RE: Compromise Authentication
> Proposal 
> 
> Just to point out: separating the concepts of "authentication
> identities" from 
> "authorization identities", which is what this subthread is nominally
> about -- 
> ~is~ addressed in draft-ietf-ldapext-authmeth-02.txt (and in SASL
> (RFC2222)). 
> See sections 5 and 11 in authmeth-02, and section 3 (para 6 & 7) in
> RFC2222.
> 
> Note that I am going to be (real soon now) moving
> authmeth-02:section-5 (back) 
> into draft-ietf-ldapext-ldapv3-tls so that the latter may be
> progressed 
> without dependence on authmeth.
> 
> Jeff
> 
> 
> 
>