Re: Comments on Access Control Model draft - grant/deny evaluation rules

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:14 AM 4/4/01 -0400, Richard V Huber wrote:
>: >Some of the things that I don't think are clear in the current draft:
>: >
>: > - Groups and roles may contain other groups and roles.  Subtrees may
>: >   contain groups and roles.  Since groups, roles, and subtrees are of
>: >   different precedence, the interactions need to be spelled out.
>: 
>: I would recommend that subtrees, groups and roles not be
>: recursively evaluated.
>
>If groups and roles are not recursively evaluated, I think that the
>principle of least surprise will be violated - it won't work the way
>people expect it to.

Maybe David or someone from the X.500 crowd could comment on
why X.500 does not recursively evaluate groups and roles their
ACM.

X.500(93):
   nested groups are not supported when evaluating access controls.

I note that recursive evaluation could be quite expensive.

>: >Precedence of Subjects within a Scope:
>: >
>: >  1. ipAddress
>: 
>: I don't understand why ipAddress is viewed as being more
>: specific than an authzID.
>: 
>: 
>: >  2. Wildcarded DNS name
>: >     If multiple wildcarded DNS names are applicable, they are of equal
>: >     precedence.
>: 
>: I don't understand why ipAddress is viewed as being more
>: specific than an authzID.
>
>Bob Blakley sent some mail about this explaining the precedence.

Yes.  I'll post a specific message  on this subject...

>: 
>: X.501(93) 16.4.2.3 AuthenticationLevel
>: AuthenticationLevel defines the minimum requestor authentication level required for this ACIItem.
>: 
>
>But then we have to define a well-ordering of authentication levels,
>and I believe that is a rathole.  And the rathole reopens every time
>someone comes out with a new SASL mechanism.

Yes, but "simple" and "sasl" are not authentication levels,
they are authentication methods.  Authenticated simple with
transport layer security (w/ a strong cipher) is actually
stronger than say CRAM-MD5.  But then SASL/EXTERNAL might
actually offer less security than CRAM-MD5 (as SASL/EXTERNAL
allows the server to choose any suitable authentication
identity it might have available to it... including an
IP address).

Now, I don't mind having support for authentication methods
and mechanisms, ie:
        "none", "simple/anonymous", "simple/unauthenticated",
        "simple/authenticated", "sasl/mechanism" (where mechanism
        is any SASL mechanism).

and I note that many of these will have questionable value
in ACIs.  For example, "sasl/external" does not imply any
particular authentication level.

I would rather we just define four levels:
        "none" (includes methods/mechanisms:
                "none", "simple/anonymous", "simple/unauthenticated",
                and SASL equivalents (none should be used))
        "weak"  (includes unprotected password methods such as          "simple/authenticated" (without TLS*), SASL/PLAIN
                (without TLS), etc.)
        "protected" (includes protected password mechanisms
                such as "simple/authenticated" w/ TLS*, SASL/PLAIN
                w/ TLS*, SASL/CRAM-MD5, SASL-DIGEST-MD5, etc.)
        "strong" (includes mechanisms better than "protected" such
                as SASL/GSSAPI).

        (* TLS w/ an adequate cipher).

Note that such classifications need to be subjective to allow the
directory implementor (who may delegate to the admin) which
mechanisms fall within what categories.  A case in point is
SASL/EXTERNAL cannot possibly be categorized unless you know what
lower level authentication method was used to produce the identity
the implementation chooses to pull up into LDAP.

Kurt