[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: mapping identities RE: Compromise Authentication Proposal
Date forwarded: Fri, 9 Oct 1998 14:10:58 -0700 (PDT)
Date sent: Fri, 09 Oct 1998 15:10:03 -0600
From: "Ed Reed" <ed_reed@novell.com>
To: <Chris.Oliva@entrust.com>, <ietf-ldapext@netscape.com>
Subject: RE: mapping identities RE: Compromise Authentication Proposal
Forwarded by: ietf-ldapext@netscape.com
Ed
A wholly agree with your analysis and rationale below. I might add that a
similar discussion was had in the X.500 group about resolving who were the
members of a group of names (cf distribution list) when it was (the members of)
the list that was given access rights. Text was added to the X.500 standard to
say that it might be difficult to determine group membership if the list is not
held locally.
Quoting from section 16.4.2.5. of X.501
ADSA is not required to perform a remote operation to determine whether
the requestor belongs to a particular group for the purposes of Basic
Access Control. If membership in the group cannot be evaluated, the
DSA shall assume that the requestor does not belong to the group if
the ACI item grants the permission sought, and does belong to the
group if it denies the permission sought.
David
> 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
> >
> >
> >
> >
>
>
>
>
>
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 370 957 287
Email D.W.Chadwick@iti.salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
***************************************************