[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: mapping identities RE: Compromise Authentication Proposal
Ed,
That seems rather restrictive. I could think of situations where I would
want to allow access for users (e.g. vendors or customers) that are not in
my DIB. What you are proposing may require me to maintain entries for such
users.
If we had chaining, it would be less of an issue, but we do not.
Cheers, ....Erik.
------------------------------------------
Erik Skovgaard
GeoTrain Corp.
Enterprise Directory Architecture and Deployment
http://www.geotrain.com
At 15:10 09/10/98 -0600, Ed Reed wrote:
>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
>>
>>
>>
>>
>
>
>
>
>
>