Subject: Re: [Geopriv] WGLC on Common Policy

From: John Schnizlein <[email-masked]>
Date: Tue, 21 Feb 2006 17:09:35 -0500

On Feb 20, 2006, at 12:39 PM, Allison Mankin wrote:
>
> We are starting the WGLC on draft-ietf-geopriv-common-policy-07.txt

The principle of only adding permissions rather than ever withdrawing 
them, which is clearly stated in section 4, and for which we had 
compelling reason during WG discussions appears to be violated by 
allowing a large and possibly unknown number of users in section 7.1.4. 
  Despite the promise toward the end of section 4 "No all-except 
conditions", section 7.1.4 does neither justifies this violation nor 
explains how the apparent violation of principle is not a violation 
"how exceptions can be made to work".  Rather, it simply specifies that 
exceptions are allowed in the important case of user identities.  My 
impression was that either the justification would be included or the 
exception feature would be excluded.

John

Relevant text for convenience:

4.  Goals and Assumptions
...
    Permit only:

       Rules only provide permissions rather than denying them.  Allowing
       both 'permit' and 'deny' actions would require some rule ordering
       which had implications on the update operations executed on these
       rules.  Additionally it would make distributed rule sets more
       complicated.  Hence, only 'permit' actions are allowed which
       result in more efficient rule processing.  This also implies that
       rule ordering is not important.  Consequently, to make a policy
       decision requires processing all policy rules.

...
    No all-except conditions:

       It is not possible to express exclusion conditions based on
       identities such as "everybody except Alice".  However, this
       restriction does not prevent all forms of blacklisting.  It is
       still possible to express an authorization rule like 'I allow
       access to my location information for everyone of domain
       example.com except for John'.  See the example in Section 7.1
       describing how exceptions can be made to work.  The reason for
       this choice is the ease with which identities can be manufactured,
       and the implication that all-except types of rules are easily
       subverted.
...

7.1.4.  Matching Multiple Entities

    The <many> element is a mechanism to perform authorization decisions
    based on the domain part of the authenticated identity.  As such, it
    allows to match a large and possibly unknown number of users within a
    domain.

    Furthermore, it is possible to include one or multiple <except>
    elements to exclude either individual users or users belonging to a
    specific domain.  Excluding individual entities is implemented using
    a <except id="..."/> statement.  The semantic of the 'id' attribute
    of the <except> element has the same meaning as the 'id' attribute of

    the <one> element (see Section 7.1.3).  Excluding users belonging to
    a specific domain is implemented using the <except domain="..."/>
    element that excludes any user from the indicated domain.

    If multiple <except> elements are listed as child elements of the
    <many> element then the result of each <except> element is combined
    using a logical OR.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Feb 2006 17:15:43 -0500

John,

This is subtle and I don't have the mailing list discussion handy where 
this has been discussed previously, but the matching of user names does 
not impact the "additive permissions" design requirement. Rules are 
always additive. However, determining when a rule is *matched* may well 
allow exceptions ("match unless"). If any of these match exceptions are 
met, the rule will not be added to the permission set.

The basic test is that removing a rule can never increase permissions. 
This requirement is met here.

Henning

John Schnizlein wrote:
> explains how the apparent violation of principle is not a violation "how 
> exceptions can be made to work".  Rather, it simply specifies that

---

From: John Schnizlein <[email-masked]>
Date: Tue, 21 Feb 2006 17:27:42 -0500

On Feb 21, 2006, at 5:15 PM, Henning Schulzrinne wrote:
>
> This is subtle and I don't have the mailing list discussion handy 
> where this has been discussed previously, but the matching of user 
> names does not impact the "additive permissions" design requirement. 
> Rules are always additive. However, determining when a rule is 
> *matched* may well allow exceptions ("match unless"). If any of these 
> match exceptions are met, the rule will not be added to the permission 
> set.
>

Wouldn't removing a rule that contained an allowance for some domain 
<except id="john"/> have the effect of allowing john?  This certainly 
seems to be the effect if there were another rule that covered the 
domain but did not include the exception.

Especially if this is a subtle problem, the resolution of that problem 
should be in the draft before it is considered done.

John

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Feb 2006 17:37:03 -0500

> domain but did not include the exception.

No. Let's say we have two rules:

Rule 1: Give permission A to everybody at example.com except John.
Rule 2: Give permission A to everybody at example.com

With this set of rules, John will have permission A (based on Rule 2). 
Here, Rule 1 adds no permissions. (But that can happen even without 
exceptions.)

Removing rule 1 will still leave John with the same set of permissions.

Removing rule 2 will leave John worse off, but that's ok.

Since I'm probably missing the case you're after, maybe you can specify 
an example along the lines as above.

Henning

---

From: John Schnizlein <[email-masked]>
Date: Tue, 21 Feb 2006 18:22:22 -0500

Henning:

You have the right example.  It seems that the subtlety is captured by 
the fact that your Rule 1 is a no-op because the union of permissions 
across different rules applies.  The distinction between deny rules and 
allow rules with exceptions (that have the effect of denial) is that 
rule writers will have been warned that the policy is the union of all 
the rules.  Maybe this point should be emphasized in section 7.1.4 so 
that in the more-likely example of a larger set of rules such as this 
one, in which intent of the last rule is not realized, rule writers are 
less likely to stumble onto false assurance.

Rule 1: Give permission A to everybody at example.com
Rule 2:
...
Rule n:
Rule n+1: Give permission A to everybody at example.com except John.

The risk of adding a no-op rule like n+1 is greater with complex rules 
like the following example from 7.1.4.2:

        <rule id="f3g44r1">
            <conditions>
                <sphere value="work"/>
                <identity>
                    <many>
                        <except domain="example.com"/>
                        <except domain="example.org"/>
                        <except id="sip:[email-masked]"/>
                        <except id="sip:[email-masked]"/>
                        <except id="tel:+1-212-555-1234" />
                        <except id="sip:[email-masked]"/>
                    </many>
                </identity>
                <validity>
                    <from>2003-12-24T17:00:00+01:00</from>
                    <until>2003-12-24T19:00:00+01:00</until>
                </validity>
            </conditions>
            <actions/>
            <transformations/>
        </rule>

John

    No false assurance:

       It appears more dangerous to give the user the impression that the
       system will prevent disclosure automatically, but fail to do so
       with a significant probability of operator error or
       misunderstanding, than to force the user to explicitly invoke
       simpler rules.

On Feb 21, 2006, at 5:37 PM, Henning Schulzrinne wrote:

> Since I'm probably missing the case you're after, maybe you can 
> specify an example along the lines as above.
>
> Henning
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Feb 2006 08:24:04 -0500

John:

I agree that some additional wording might be helpful. In general, it 
seems that all composite rule systems have the potential that rules may 
be redundant. I suspect the best thing is to do this like programming 
language compilers, i.e., to have an automatic checker that flags 
redundant rules that are subsumed by other rules, possibly 
unintentionally. Beyond pointing this out, this seems to be largely an 
implementation issue, however.

Henning