Subject: Re: ldapACI syntax and matching rules and more

From: [email-masked]
Date: Thu, 16 Mar 2000 10:10:02 -0600

Kurt et. al.:

Here are a few of my reactions:

>Also, I think KerberosId should be generalized.  I suggest
>referring to it as a UserId which allows any UTF-8 printable
>string.  This maps better onto authmeth's authzid "u:".
>If left as a KerberosId, it should not be a SHOULD.

This is "OK", but it needs to be possible to avoid name capture
in cases where different authentication mechanisms are supported to the
same directory.  I don't want someone to be able to use a
"foo-name" which is lexically the same as someone else's kerberosid
to get access to resources illicitly.

>The BNFs appear underspecified.  < printable string > allows
>too many characters which hinder (or disallow) parsing.  A
>< subject DN > should be an RFC 2253 DN string.  < oid >
>should be a RFC 2252 numericoid.

I'll defer to those more knowledgeable on these.

>How does a ACL granting access to an attribute types superior affect
>access the attribute type?  Ie: does granting access to 'name'
>allow access to 'cn'?

In the current draft the answer is no, and I'd prefer to keep it
this way in order to keep the ACL resolution algorithm simple.  If we
implement semantics like these, then we need to do bunch of type
resolution at access check time -- could be a performance problem.

>Why is ipAddress restricted to the "dotted-decimal string
>representation"?  This restricts ipAddress to IPv4 addresses.
>A reference to exact ipAddress form should be provided.
>[I'd like wildcard support... ie: 10.*.*.* or 10.0.0.0/8
>or 10.0.0.0:255.0.0.0]

Again, I don't want to do wildcarding because it requires a complicated
evaluation
code-path at access check time.  However I agree it would be good to have some
proposal
which supports IPv6.

--bob

Bob Blakley
Chief Scientist
Tivoli SecureWay Business Unit

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 16 Mar 2000 08:41:09 -0800

>to get access to resources illicitly.

To resolve this issue, I suggest relating the ACI "userid" to the
Authmeth AuthzId "u:".  As new forms were added to AuthzId, a new
form can be added to ACIs (and vice versa).

>resolution at access check time -- could be a performance problem.

I would note that ACL management already requires a bunch of type
resolution checks to handle attribute subtypes (ie: lang- tags)
and alternative name forms (OID vs. multiple names).  Given this
(and my experience implementing such) the performance hit of
checking superiors (via sup) is actually quite minimal and,
depending on the implementation quite natural (ie: it may actually
be harder NOT to provide such support).

>code-path at access check time.

Even where that complication makes rules easier to manage and
likely to be much "quicker"?  The example I gave would require 2^24
times more ACI values to implement without wildcarding.

Kurt