Subject: RE: [Geopriv] RE: supporitng blacklists, was: Re: [Simple] Comments on: First draft of text on semantic-based authorization policies [exceptions]

From: [email-masked]
Date: Thu, 1 Apr 2004 15:25:24 +0300

Hannes,

I wasn't referring to the ordering of _rules_, but ordering of _actions_, such as <confirmation>. For instance what happens if the same watcher/recipient is given several (unorthogonal) actions - for instance <confirmation> and <accept-subscription> by different rules. There is no way of deciding what to do, unless the actions that are unorthogonal are given integer values (per chapter 10 of the draft you refer to), i.e. there is at least partial ordering of actions. (Orthogonal actions can be combined with union still.)

I think Jonathan's example would be OK, if we say that <deny-subscription> is the default given to watchers not matched by any rule, so the last rule:

> > > > <rule>
> > > > <conditions>
> > > >    <identity>
> > > >      <user>joe</user>
> > > >    <identity>
> > > > </conditions>
> > > > <actions>
> > > >    <deny-subscription/>
> > > > </actions>
> > > > </rule>

would not be needed at all (unless there is something even stricter which is applied by default to watchers who do not even get <deny-permission> - I doubt this would be the case).

However, I think in another thread in SIMPLE Henning has suggested (as far as I understood it)actually that <confirmation> could have lower "number" than <deny-subscription>, and that has been debated.

Markus 

> -----Original Message-----
> From: ext Tschofenig Hannes [mailto:[email-masked]]
> Sent: 01 April, 2004 14:27
> To: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [Geopriv] RE: supporitng blacklists, was: Re: [Simple]
> Comments on: First draft of text on semantic-based authorization
> policies [exceptions]
> 
> 
> hi markus, 
> 
> > Hi,
> > 
> > I see that this is another case, where it would be beneficial 
> > that the <action>s would be ordered in similar way as other 
> > permissions. I guess the "lowest" or default value would be 
> > <deny-subscription>, as that gives least information out, so 
> > there would not be even need to have that in any rules?
> 
> well, section 4 of <draft-ietf-geopriv-common-policy-00.txt> 
> says that:
> "... This also implies that rule ordering is not important."
> 
> i think that we should note this fact more clearly. 
> 
> we do not assume that rules appear in a certain order. rules 
> can appear in
> any order without effecting the result of the rule evaluation.
> 
> introducing an order into these rules would create a number 
> of problems. i
> will just list a few: 
> - you need to make sure that the person writing those rules 
> is aware of the
> order to anticipate its result. 
> - rule updates (e.g., via xcap need be aware of the order) - 
> changing the
> order of the rule has an impact on the result of rule 
> evaluation. i am not
> sure whether xcap would be able to handle this issue properly. 
> - you suddenly have to deal with a different conflict 
> resolution strategy.
> you know this from regular firewall rules. we tried to keep 
> our conflict
> resolution strategy very simple (see section 10 - Procedure 
> for Combining
> Permissions; in the same draft).
> 
> ciao
> hannes
> 
> > 
> > Markus 
> > 
> > > -----Original Message-----
> > > From: ext Tschofenig Hannes [mailto:[email-masked]]
> > > Sent: 31 March, 2004 14:48
> > > To: 'Jonathan Rosenberg'; Ben Campbell
> > > Cc: Ted Hardie; Henning Schulzrinne; Isomaki Markus
> > > (Nokia-NRC/Helsinki); [email-masked]; [email-masked]'
> > > Subject: RE: supporitng blacklists, was: Re: [Simple] 
> > > Comments on: First
> > > draft of text on semantic-based authorization policies 
> [exceptions]
> > > 
> > > 
> > > -- cc to geopriv ml
> > > 
> > > hi jonathan, 
> > > 
> > > you propose an action with is a deny. doesn't this conflict 
> > > with the goals
> > > expressed in the common policy draft (
> > > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-
> > > policy-00.txt)
> > > where Section 4 (Goals and Assumptions) specifies 'Permit 
> > > only' actions are
> > > allowed. do you suggest that we modifying our 
> > > goals/assumptions or do i miss
> > > something?
> > > 
> > > ciao
> > > hannes
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jonathan Rosenberg [mailto:[email-masked]]
> > > > Sent: Thursday, March 25, 2004 4:43 PM
> > > > To: Ben Campbell
> > > > Cc: Ted Hardie; Henning Schulzrinne; [email-masked];
> > > > [email-masked]
> > > > Subject: Re: supporitng blacklists, was: Re: [Simple] 
> > > > Comments on: First
> > > > draft of text on semantic-based authorization policies 
> > [exceptions]
> > > > 
> > > > 
> > > > You can still achieve the functionality you want, Ben, 
> > > > without requiring 
> > > > the new rule Henning had proposed:
> > > > 
> > > > <rule>
> > > > <conditions>
> > > >    <identity>
> > > >      <domain>example.com</domain>
> > > >      <except>joe</except>
> > > >    <identity>
> > > > </conditions>
> > > > 
> > > > <actions>
> > > >    <ask-for-confirmation/>
> > > > </actions>
> > > > </rule>
> > > > 
> > > > <rule>
> > > > <conditions>
> > > >    <identity>
> > > >      <user>joe</user>
> > > >    <identity>
> > > > </conditions>
> > > > 
> > > > <actions>
> > > >    <deny-subscription/>
> > > > </actions>
> > > > </rule>
> > > > 
> > > > 
> > > > Of course, you need to be careful that the user joe is not a 
> > > > member of 
> > > > any other rule which grants a permission greater than 
> > > > "deny-subscription", but thats a fundamental property of 
> > > the model in 
> > > > general.
> > > > 
> > > > -Jonathan R.
> > > > 
> > > > Ben Campbell wrote:
> > > > 
> > > > > Ted Hardie wrote:
> > > > > 
> > > > >> At 9:09 AM -0500 03/24/2004, Henning Schulzrinne wrote:
> > > > >>
> > > > >>> "Everybody in the world, in any domain, gets to *ask* to 
> > > > subscribe to 
> > > > >>> my presence, but Alice, Bob and Carol have already been 
> > > > told to take 
> > > > >>> a hike and thus shouldn't even be able to ask."
> > > > >>>
> > > > >>> Is this the type of rule we want to be to support?
> > > > >>
> > > > >>
> > > > >>
> > > > >> It's seems to me to be a lot easier just to keep telling 
> > > > them to take 
> > > > >> a hike
> > > > >> whenever they ask; is there a reason to optimize for this 
> > > > case that I'm
> > > > >> missing?
> > > > > 
> > > > > 
> > > > > The act of asking can become a kind of harrassment. Some 
> > > > time ago, I had 
> > > > > a yahoo messenger user that continuously asked permission 
> > > > to watch my 
> > > > > presence, but refused to identify themselves to me. This 
> > > > continued after 
> > > > > I asked them to desist. Fortunately, yahoo messenger 
> > > > allowed me to block 
> > > > > that ID, so I no longer get bothered by them.
> > > > > 
> > > > 
> > > > -- 
> > > > Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> > > > Chief Technology Officer                    Parsippany, NJ 
> > > 07054-2711
> > > > dynamicsoft
> > > > [email-masked]                     FAX:   
> (973) 952-5050
> > > > http://www.jdrosen.net                      PHONE: 
> (973) 952-5000
> > > > http://www.dynamicsoft.com
> > > > 
> > > > _______________________________________________
> > > > Simple mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/simple
> > > > 
> > > 
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 03 Apr 2004 23:25:41 -0500

> I wasn't referring to the ordering of _rules_, but ordering of
> _actions_, such as <confirmation>. For instance what happens if the
> same watcher/recipient is given several (unorthogonal) actions - for
> instance <confirmation> and <accept-subscription> by different rules.
> There is no way of deciding what to do, unless the actions that are
> unorthogonal are given integer values (per chapter 10 of the draft
> you refer to), i.e. there is at least partial ordering of actions.
> (Orthogonal actions can be combined with union still.)

I had suggested exactly such an ordering of actions earlier. I agree 
that action ordering is necessary to make things work. I hope we all 
agree that rule ordering is evil.

> 
> I think Jonathan's example would be OK, if we say that
> <deny-subscription> is the default given to watchers not matched by
> any rule, so the last rule:

The 'NULL' action is the default and does not need to be expressed 
explicitly. In this case, deny is a sensible default (see below).

> However, I think in another thread in SIMPLE Henning has suggested
> (as far as I understood it)actually that <confirmation> could have
> lower "number" than <deny-subscription>, and that has been debated.

My earlier post assumed that you only had domain-specific blacklists. If 
we allow global, rule-specific blacklists, you could do this with

(1) everybody except blacklist: confirmation required
(2) whitelist: accept subscription

and making 'deny' the default behavior for those not matching any rule 
(which includes those on the blacklist). In that case, you wouldn't 
really need 'deny' as an action since it would never appear in a rule, 
as far as I can tell.

You obviously have to be careful to include the blacklist on any other 
rule that might match a blacklist resident, in particular domain-wide 
matches, but that's a generic problem. Example:

(3) columbia.edu: accept subscription during business hours

would need to be qualified with any blacklisted columbia.edu addresses.

I don't think you can have a stalker blacklist if you make 
confirmation-required the default behavior, except by the contorted 
ordering that I proposed earlier, where deny has the *highest* ranking 
and trumps anything else. The problem with that ordering is that it is 
not privacy safe under unreliable composition [PSURC]. (My more precise 
definition of unreliable composition: some complete rules may be at 
another location and may not be reliably available when making a decision.)

My model above is PSURC since if rule (1) is not available, everybody 
except the whitelist will be denied without getting to knock.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 03 Apr 2004 23:25:41 -0500

Henning