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

From: [email-masked]
Date: Thu, 25 Mar 2004 00:05:20 +0200

Hi,

See inline:

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 24 March, 2004 10:00
> To: Henning Schulzrinne
> Cc: Isomaki Markus (Nokia-NRC/Helsinki); [email-masked]
> Subject: supporitng blacklists, was: Re: [Simple] Comments on: First
> draft of text on semantic-based authorization policies [exceptions]
> 
> 
> 
> There are a bunch of separable points in these various mails, so I'm
> separating responses and changing the subject.
> 
> Henning Schulzrinne wrote:
> 
> > 
> >> 
> >> So it is to my understanding impossible for instance to provide 
> >> presence to everyone except an enumerated list of identities. This
> >> is usually what black-listing means.
> > 
> > 
> > I'm finding it hard to believe that 'everyone in the world except A,
> > B and C' is a useful service concept. My concern is that this
> > promises privacy to users that may not understand the implications
> > (and the uselessness of this). Can you imagine a system that allows
> > any random user to obtain presence information?
> 
> I agree with Henning. What I really think you want, Markus, is to say
> that, "for users within domains where I know that its hard to get new
> identities easily, allow anyone except Joe and Bob". I believe thats
> what you had in mind when you said:
> 
> > While in general this is the case, I don't think it should limit
> > _all_ systems, some of which can deal with identities 
> better than the
> > Internet at large. Below is an example, beyond block-listing, how
> > leaving out exceptions makes things difficult
> 
> With my definition above, the existing domain-based exceptions work 
> fine. For example, if AOL wants to do black lists, they would do:
> 
> <rule>
> <conditions>
> <identity>
>       <domain>aol.com</domain>
>       <except>joe</except>
>       <except>bob</except>
>     </identity>
> </conditions>
> 
> <actions>
>    <accept-subscription/>
> </actions>
> </rule>
> 
> That is, you can use the existing mechanism to enumerate the 
> domains in 
> the trusted set which have this property. Today, we only really see 
> single provider networks, where you can only subscribe to 
> someone in the 
> same domain. That is supported fine by the current mechanism. 
> Of course, 
> the standard caveats apply - you really need to understand 
> the way the 
> domain hands out identities before you set such a policy.
> 
> When we eventually run into networks where there are so many service 
> providers amongst this "trusted set" that it becomes difficult to 
> enumerate them, we might have a problem, but I think we can 
> cross that 
> bridge later.
> 

You may be right on how SIP deployment life-cycle goes, but I think we should look ahead one step even with the initial set of specifications. After all, I wouldn't want to say that SIMPLE is currently aiming only for a single-domain deployability.

3GPP IMS (and the operators committed to it) is a good example of an attempt to create a trusted SIP network which spans accross several service providers and thus obviously several DNS domains. I assume too that initially it will start as single-operator islands, but soon enough those islands will be connected. At that step there probably wouldn't be interworking with the "whole Internet", just among the operators who are collaborating. 

Within this trust domain P-Asserted-Id would be used (based on HTTP-digest or HTTP-digest-AKA authentication and use of TLS or IPSec), so the users would be able to trust the identities of their peers. Also, the creation of new user identities would be controlled by each provider.

In this kind of environment black-listing still makes some sense, at least more sense than doing similar type of stuff in PSTN, which also happens and is considered useful. The current specs allow exceptions, but only per domain, so there is a problem here. I hope people at least understand my point, even if they may disagree with it. (3GPP is probably not the only body trying to setup something like this.)

One idea that occured to me is this: what if each operator within such trust domain keeps track on all the DNS domains that belong to this trust domain, i.e. from which domains do they accept getting requests with P-Asserted-Id. We would then allow making subtractions (exceptions) from that set in a similar way as it is currently allowed from a single domain. It could be something like this:
- Operator keeps up-to-date list of trusted DNS domains as a well-known resource in the global XCAP tree. 
- Users' terminals are able to fetch that list from there.
- The user would then be able to set the identity part in rules like
<identity>
      <trust-domain/>
      <except>[email-masked]</except>
      <except>[email-masked]</except>
</identity>
assuming that both foo.com and bar.net are part of the <trust-domain>.

The main problem obviously is the maintenance of the list of trusted domains. If the trust is transitive even the operator may not be aware of it all.

Do you think this gets too complicated? It's the best I can think of if people are in general against having this
<identity>
      <any/>
      <except>[email-masked]</except>
      <except>[email-masked]</except>
</identity>

> 
> > 
> > I think the concept of 'everybody gets to ask for permission before 
> > subscribing except bad guys A, B and C who I've already told to get 
> > lost' is useful and might implementable by an appropriate 
> ordering of
> >  actions. For example, if you order actions as
> > 
> > known_reject (highest), permit, ask, dont_bother (lowest, default)
> > 
> > the right thing happens. However, caveats about file merging apply.
> 
> Henning - I dont understand how this is privacy safe. In your 
> ordering, 
> there is not a strictly increasing amount of information 
> revealed as the 
> values increase.
> 
> -Jonathan R.
> -- 
> 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
> 

Markus

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

---

From: [email-masked]
Date: Thu, 25 Mar 2004 00:05:20 +0200

Hi,

Markus

---

From: [email-masked]
Date: Thu, 25 Mar 2004 00:24:19 +0200

Hi,

Inline:

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Henning Schulzrinne
> Sent: 24 March, 2004 16:09
> To: Jonathan Rosenberg
> Subject: Re: supporitng blacklists, was: Re: [Simple] 
> Comments on: First

And I guess that one of the design goals was that if you have a rule that permits something, there can't be a rule which takes it away ('known_reject' clearly gives out less than 'permit'), as if the rules come from different places and some of them are somehow not "executed", more information is revealed that what was the intention. 

> > 
> > Henning - I dont understand how this is privacy safe. In 
> your ordering, 
> The idea is 'known reject' trumps all other values. Thus, if your 
> identity matches such a rule, it gets bounced even if a more 
> encompassing rule allows to request permission.
> 

Still I guess this would be against the spirit of privacy safety?

> This is unnecessary if we agree that global blacklists are a bad idea 
> even for the subscription (as opposed to information 
> delivery) phase. My 
> notion is only needed if you want to support the notion:
> 
> "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?
> 

This is exactly what I'm trying to get supported (even if I made negative comments about the proposal above...)! Can someone explain what would the problem with

<identity>
      <any/>

I see this so that the <identity> element defines a set with an "atomic" operation, i.e. if something goes wrong the end-result would be an empty set (same as with external lists within <identity>). The permissions that follow would then be applied to this set. 

So there isn't anything like defining a rule which makes an exception to permissions given in another rule, which I understand is bad. The whole exception handling happens wihin the scope of <identity> element in a single rule.

Here's an example: Let's say that there are two rules, which provide the same permission. Identity-elements for those are defined like this:

Rule 1:
<identity>
      <any/>

Rule 2:
<identity>
      <any/>

Taking an union of these sets results in <all> and is according to the additiveness principle.

> Henning

Markus

---

From: [email-masked]
Date: Wed, 31 Mar 2004 17:43:59 +0300

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?

Markus 

> 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
> -- 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
> 
> 
> > 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]
> > 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:
> > >>
> > 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."
> > >>>
> > >> 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.
> > > 
> > 
> > --

---

From: [email-masked]
Date: Wed, 31 Mar 2004 17:43:59 +0300

Hi,

Markus