Re: IP Address in the ACM (Was: Comments on Access Control Model - BNF)

[George_Robert_Blakley_III/Tivoli_Systems%TIVOLI_SYSTEMS@us.ibm.com]

I agree with everything you say here, Kurt.

I think non-ACI mechanisms are better than ACI mechanisms for restricting
topology, and
I also agree that only IP address ranges or wildcarded expressions scale if
you want to
use an ACI-based mechanism to do this.

I was originally and still am personally opposed to the inclusion of IP
address as a subject
attribute in access control systems.

In terms of precedence, let's try to reason through this:

     (1) If an ACL says to grant on the basis of IP address but deny on the
basis of
          some other attribute (username, group, etc....), then the
behavior we
          want is (in my opinion) "deny".  Rationale: the user is
prohibited from
          access, regardless of where he's sitting.

     (2) If an ACL says to deny on the basis of IP address but grant on the
basis of
          some other attribute (username, group, etc....), then the
behavior we want
          is *also* (in my opinion) "deny".  Rationale: the user is allowed
access,
          but not from where he's sitting.

Is there a way to achieve this with our current resolution algorithm?  I'd
have to check more
carefully than I have time to do right now.

--bob

Bob Blakley
Chief Scientist
Enterprise Solutions Unit
Tivoli Systems, Inc. (an IBM Company)


"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> on 04/04/2001 12:33:53 PM

To:   ietf-ldapext@netscape.com
cc:
Subject:  Re: IP Address in the ACM (Was: Comments on Access Control  Model
      - BNF)



Bob said:
>I agree in general that IP addresses shouldn't be used
>as identities and that RFC2820 is correct on this count.
>However the goal at the time the original model draft was
>written was to support (or at least not exclude) things
>which existing implementations were already doing, however
>misguided they might be from a "pure security" point of
>view.  Several implementations supported and still
>support IP addresses as subject attributes.

I note that most implementations actually support IP address
with some form of wildcard support.  Requiring an ACI
value per IP address just doesn't scale.

>To your second point, the precedence assignment was based
>on the observation that it's usually not a single IP
>address which is included in a policy, but a range of IP
>addresses.  Normally everything within (or everything
>except) a specific IP address range is excluded from access
>-- REGARDLESS of other attributes.  Hence IP address became
>the highest precedence -- because the mechanism is essentially
>enforcing topology control & hence to be effective has
>to be enforced first.

Since you did note "IP address range", my general comment
is that this subject is less specific than varous other
subjects and hence should be lower.

Also, as far as implementing "topology controls", non-ACM
mechanisms are often far more effective.  For example, our
server implements "TCP wrappers" (an internal "firewalling"
mechanism) to enforce topology controls.  We also do support
IP addresses in our ACM (only in ACLs, not ACIs), but normally
their use is in combination with other factors.

Kurt