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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Apr 2001 10:33:53 -0700

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

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 4 Apr 2001 10:59:30 -0700

I hope that IP addresses as subjects are OPTIONAL, and that the security
considerations section is appropriately negative on their security.

In fact, I believe they should be a SHOULD NOT in the spec -- i.e., you
must have good reason to believe that they are secure before you use
them.

Paul

---

From: George_Robert_Blakley_III/[email-masked]
Date: Wed, 11 Apr 2001 11:18:23 -0500

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" <[email-masked]> on 04/04/2001 12:33:53 PM

To:   [email-masked]
cc:
Subject:  Re: IP Address in the ACM (Was: Comments on Access Control  Model
      - BNF)

Kurt

---

From: [email-masked] (Richard V Huber)
Date: Wed, 11 Apr 2001 17:11:46 -0400

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/[email-masked]
: To: "Kurt D. Zeilenga" <[email-masked]>
: cc: [email-masked]
: 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" <[email-masked]> on 04/04/2001 12:33:53 PM
: 
: To:   [email-masked]
: 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

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 11 Apr 2001 17:55:39 -0700

Gee, this seems pretty complicated -- all for a mechanism known to be of
only limited secure applicability. Again, I object to making it
mandatory for compliance.

> -----Original Message-----
> From: Richard V Huber [mailto:[email-masked]] 
> Sent: Wednesday, April 11, 2001 2:12 PM
> 
> 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 
> 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:
> 
> 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.
>