[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on Access Control Model draft - grant/deny evaluation rules
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