Subject: RE: [Simple] <except-domain> element issue for common policy

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 6 Jul 2005 18:17:19 -0400

The most compelling reason to process policies in an additive fashion is that there may be multiple rulemakers inputting policies to the system. External rulesets are just one example of a way that multiple distinct entities might associate policy with a single presentity.

I agree that if there is one centralized point of policy composition then it could potentially do something sensible with this. However, I don't think it would be behaving in an additive fashion, and it really sounds to me like you want to have it both ways.

If permissions are composed in a strictly additive fashion, then if there are multiple rulemakers inputting policy to the point of composition, with the addition of <except> the more permissive policies clobber the less permissive policies. This is scary from a privacy perspective, and probably contrary to what many rulemakers would think will happen. For example, if I input a rule saying that McDonalds can't have my location information, and my service provider's default policy is that anyone can have it, then if those are aggregated additively, McDonald's gets my location information. This is bad, and it is a direct result of <except>. I can't be sure that my policies will be enforced unless I know all of the other policies that are being inputted to the system.

When you say things like:

> That experience can still be simulated with privacy safety if a web 
> application keeps track of set of blocked users and adds them as an 
> exception to each rule.

The "web application" you're talking about is in fact a policy compositor that doesn't follow the additive rule. There was no question to start with that if policies weren't composed additively, then <except> could be made to work. However, we need to be open about our departure from the additive model and reconsider the system accordingly. Saying that all exceptions need to be in all domain-based rules is just hand-waving - if there are multiple rule-makers and <except>s are in play, then somewhere behind it all will be a non-additive compositor.

Jon Peterson
NeuStar, Inc.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Aki Niemi <[email-masked]>
Date: Thu, 07 Jul 2005 06:55:26 +0300

Inline.

ext Peterson, Jon wrote:
> The most compelling reason to process policies in an additive fashion
> is that there may be multiple rulemakers inputting policies to the
> system. External rulesets are just one example of a way that multiple
> distinct entities might associate policy with a single presentity.
> 
> I agree that if there is one centralized point of policy composition
> then it could potentially do something sensible with this. However, I
> don't think it would be behaving in an additive fashion, and it
> really sounds to me like you want to have it both ways.
> 
> If permissions are composed in a strictly additive fashion, then if
> there are multiple rulemakers inputting policy to the point of
> composition, with the addition of <except> the more permissive
> policies clobber the less permissive policies. This is scary from a
> privacy perspective, and probably contrary to what many rulemakers
> would think will happen. For example, if I input a rule saying that
> McDonalds can't have my location information, and my service
> provider's default policy is that anyone can have it, then if those
> are aggregated additively, McDonald's gets my location information.
> This is bad, and it is a direct result of <except>. I can't be sure
> that my policies will be enforced unless I know all of the other
> policies that are being inputted to the system.

How so? I can model the above with simple non-excepting rules:

R1: grant "Pizza Hut", "Hesburger", "Wendy's" and "Sonic Burger" 
location information
R2: grant "any" location information

How is this a direct result of <except>?

>>  application keeps track of set of blocked users and adds them as
>> an exception to each rule.
> 
> 
> The "web application" you're talking about is in fact a policy
> compositor that doesn't follow the additive rule. There was no
> question to start with that if policies weren't composed additively,
> then <except> could be made to work. However, we need to be open
> about our departure from the additive model and reconsider the system
> accordingly. Saying that all exceptions need to be in all
> domain-based rules is just hand-waving - if there are multiple
> rule-makers and <except>s are in play, then somewhere behind it all
> will be a non-additive compositor.

Forget about <except> for a while. This is a basic feature of 
common-policy. If there are multiple rulemakers, then there will always 
need to be such a compositor functionality to make the overall policy 
deterministic from the user's point of view.

For example, consider a ruleset maintained by a set of rulemakers that 
includes the following rules each created by a different rulemaker:

R1: grant Åke, Stephen, Lisa and Carol access to presence
R2: grant Alex, Bob, Billy and Chris access to presence
R3: grant Atte, Günther and Carol access to presence

Let's say rulemaker #1 wants to remove Carol from its rule R1. It would 
be very easy for the user to be fooled into thinking that once the grant 
is taken away from Carol in R1, that Carol won't get presence. This of 
course isn't so because R3 (created by rulemaker #3) also grants Carol 
presence. *Unless* rulemaker #1 also goes through all of the other rules 
in the ruleset, and removes all grants to Carol.

Fact is, the "compositor" needs to be there between the ruleset and the 
user, and treat the ruleset as a whole to be able to 1) present a 
sensible representation of the policy to the user and 2) keep that 
policy deterministic from the user's point of view.

Cheers,
Aki

> Jon Peterson NeuStar, Inc.
> 
> _______________________________________________ Simple mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/simple
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Jul 2005 09:23:08 -0400

Agree with Aki. As long as we stick to atomic, position-independent 
rules, i.e., where each rule is independent of other rules and rule 
ordering is immaterial, there are only two possible scenarios:

(A) Additive rules: Each matching rule adds permissions. Common-policy 
follows that model.

(B) Subtractive rules: Each rule removes access based on a matching set 
of conditions. A classical black list is a good example of that, but you 
could construct the mirror image of the common-policy rules.

The additive property is not just or primarily important for multiple 
rule makers, but rather avoids nasty "holes" during updates without 
requiring transactions in the update mechanism. With the additive model, 
you can edit a rule set by removing a rule, then adding a new one, while 
being sure that in the time between the removal and the addition, you 
won't suddenly increase your privacy exposure. (And since the update 
mechanim can fail or even be made to fail by an adversary, this gap 
could me more than just a few milliseconds.)

Additive rules can be privacy safe in the manner that we have defined, 
subtractive rules cannot. (Subtractive rules might still be useful, 
although I think harder to understand for users unless they are really 
just lists of individuals or domains that shouldn't get access.)

One can also design rule systems that are "first-match", i.e., where 
order matters. Very early on in the GEOPRIV design process, there was 
clear consensus that having rule sets that depend on ordering were brittle.

For the case that Jon mentioned, subtractive rules are possibly 
attractive, although one would hope that most providers would start out 
with least privilege, rather than giving the world unfettered access 
that the user then has to rein in.

I hope we don't have to revisit all of these discussions again, but 
maybe some design motivation in the draft wouldn't hurt.

Henning