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

[rvh@qsun.mt.att.com (Richard V Huber)]

In terms of the resolution algorithm, it seems farily easy to change it
to do what Bob is talking about.

Just change it so that ipAddress has no explicit precedence of its
own.  The algorithm should go in precedence order through the list of
Subjects within a Scope (excluding ipAddress).  At the completion of
the processing of Subjects within a Scope, any applicable ACI with
ipAddress as subject should be added to the list that is passed on to
the next step.  Since deny has precedence over grant, this means that
ACI with ipAddress subject can only deny access; it cannot grant.

In my version of the Access Decision Algorithm, you would remove
ipAddress (and DNS name?) from the list of Subjects within a Scope and
add a step 2a after step 2:

  2a. If there are any applicable ACI values with subject of type
      ipAddress (or DNS name?), add them to the list at this point.

Note that adding this as a separate step means that the part of step 2
that says "If no ACI values remain after processing all Subject Types,
access is denied" is processed before the new step.  Thus access is
denied and the ipAddress has no effect if there is no applicable ACI
other than the one(s) based on ipAddress.

If we are going to use ipAddress as a subject I prefer this to the
original scheme.  With the original scheme a "grant" associated with an
ipAddress subject was a very dangerous thing.

Rick Huber

: From: George_Robert_Blakley_III/Tivoli_Systems%TIVOLI_SYSTEMS@us.ibm.com
: To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
: cc: ietf-ldapext@netscape.com
: Subject: Re: IP Address in the ACM (Was: Comments on Access Control Model 
: 	- BNF)
: 
: 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