Subject: RE: [XCON] Authorization in conference policy

From: [email-masked]
Date: Wed, 12 May 2004 23:41:01 +0300

Hi all,

I also think that the common policy is such a well though of construct that CPCP should use it rather than having to invent the similar thing of its own. 

The main problem is what Aki raised, i.e. how to block a certain set of identities from a conference which is otherwise open to anyone. As CPCP follows the model where kicking-out is done by modifying the authorization policy, the problem applies also to the case how to kick out a certain identity from a conference that is otherwise open to anyone.

I've raised the very same (blacklisting for otherwise public info) issue within SIMPLE for presence. Actually I understand quite well why it is probably not a good idea for presence (or geoloc). The point is that they are about protecting the privacy of some data, and even if I block a set of identities from the data, my data is still compromised to those people in practice, if I'm willing to give it to ANY other identity. So even if blacklists are used in many presence systems, I'm able to live with SIMPLE concensus not to have them.

However, I think the conferencing case is still different. There we could not really live without the all-except construct. In conference you don't just protect some data, but you also protect the conference participants from a misbehaving participant. So blocking and kicking out a single identity is important and useful, even if the same person could join later with another identity. I think it's like spam filtering: if I add some address to my spam filter, it certainly does not guarantee that I don't get any spam from that spammer anymore (since he can use different identities), but certainly it reduces it at least for a short while (and conferences for instance normally don't last forever). 

What Alex is proposing below is what you currently can do with the common policy, i.e. applying exceptions within domains. However, this is not adequate in this case, since you can never enumerate all the possible domains. So something like this is instead needed:

    <identity>
      <anyone/>
      <except>[email-masked]</except>
      <except>[email-masked]</except>
      <except>[email-masked]</except>
    </identity>

I'm NOT proposing to change common policy to accommodate this. As said, I understand clearly why this is not supported for e.g. geoloc and presence. I think CPCP should take common policy as it is and make this change specifically within CPCP. This way we would get (most of) the benefits of common policy, but could still meet the CPCP and conferencing requirements.

Markus 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Alex Audu
> Sent: 12 May, 2004 21:50
> To: Alan Johnston
> Cc: Niemi Aki (Nokia-M/Espoo); XCON WG; Henning Schulzrinne; Jonathan
> Rosenberg; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Ted Hardie; Khartabil
> Hisham (Nokia-TP-MSW/Helsinki); Koskelainen Petri (Nokia-NRC/Tampere)
> Subject: Re: [XCON] Authorization in conference policy
> 
> 
> It is true that  common-policy does not support "all-except" 
> conditions.  But its <identity> element
> does support  <except> which can be used to implement a form of 
> blacklist, as exemplified in 
> seciotn 7.1 of  common-policy  as follows:
> 
>    The next example shows how exceptions are implemented. A 
> request MUST
>    match the domain part and all three exceptions parts in an atomic
>    fashion to be a successful match.
> 
>    <identity>
>      <domain>example.com</domain>
>      <except>[email-masked]</except>
>      <except>[email-masked]</except>
>      <except>[email-masked]</except>
>    </identity>
> 
> 
> I guess the question is, would this be enough in a 
> conferencing scenario?
> It is beneficial to unify cpcp policy under the common-policy 
> paradigm.
> 
> Regards,
> Alex.
> 
> 
> 
> Alan Johnston wrote:
> 
> > Hi Aki,
> >
> > Thanks for bringing this up.
> >
> > I do think it would be worthwhile to do a comparison of 
> presence and 
> > location policy and the conference policy that we are developing in 
> > XCON.  If there are major differences or divergences, it 
> would be good 
> > to know what they are (such as the all-except construct you mention 
> > below).
> >
> > Having said that, I'm not so certain that conference policy 
> needs to 
> > formally be aligned with the common policy framework, as the 
> > differences between it and the other policies seem to be 
> greater than 
> > the similarities.
> >
> > However, if there are some concrete advantages to doing so, I think 
> > the working group should consider this approach.
> >
> > Thanks,
> > Alan Johnston
> > co-chair XCON
> >
> > At 02:46 PM 4/28/2004 +0300, Aki Niemi wrote:
> >
> >> Hi All,
> >>
> >> Currently, XCAP-CPCP [1] includes the definition of data 
> elements for
> >> implementing authorization rules and permission rules 
> (privileges) for
> >> conferences. Along with the definition of those elements, 
> it defines its
> >> own rule syntax.
> >>
> >> Common-policy [2] defines an authorization policy 
> framework, intended
> >> for use in different applications to control access to 
> data. It includes
> >> a syntax for common policy rules that are currently being used to
> >> describe authorization policies in location and SIP presence
> >> applications. Also, the common policy framework can be extended to
> >> accomodate other application needs.
> >>
> >> In short, this framework defines policy as a set of rules where the
> >> respective ordering of rules does not matter. Each rule 
> consists of a
> >> condition for matching some property (e.g., identity of 
> the requestor of
> >> data); and permissions that are to be applied in case the 
> "condition"
> >> part has evaluated to true.
> >>
> >> It seems natural that the conference policy work would 
> also benefit from
> >> adopting the common-policy framework.
> >>
> >> However, one of the intended usages of conference policy 
> is to control
> >> the participation to a conference. To expel a participant from an
> >> ongoing conference, the conference policy would be 
> manipulated in such a
> >> way that the participant is no longer allowed to 
> participate, effecting
> >> a removal of that participant from the conference. The need for
> >> expelling users is also independent of the original 
> admittance policy.
> >> Even in conferences that have open admittance (i.e. anyone 
> can join), a
> >> moderator would need to be able to expel users who are 
> disturbing the
> >> conference, e.g., expel a participant from a chat room for using
> >> explicit language.
> >>
> >> In common-policy point of view, the above would require an 
> "all-except"
> >> construct, which I believe currently is not allowed in 
> common-policy.
> >> Question is, can this be worked around, if we were to adopt
> >> common-policy in the conference policy work?
> >>
> >> And if yes, would XCON be willing to see common-policy 
> adopted in the
> >> conference policy work?
> >>
> >> The advantages would include having a unified syntax for 
> policy rules in
> >> these different applications, including a clear extension 
> model etc.
> >>
> >> Disadvantages (pending the resolution of the above issue) would be
> >> having to rewrite the authorization policy parts of 
> XCAP-CPCP, causing a
> >> delay.
> >>
> >> Thoughts?
> >>
> >> Cheers,
> >> Aki
> >>
> >> [1]
> >> 
> http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xca
p-cpcp-usage-02.txt 
>>
>>
>> [2]
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-00.txt 
>>
>>
>>
>> _______________________________________________
>> XCON mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/xcon
>
>
>
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 May 2004 17:31:10 -0400

> I guess one question that follows from this is a use case question:
> how often will a conference organizer be able to close a conference
> *completely* to new participants at some point in the conference?
> That would provide a pretty obvious counter to newly minted identities,
> but it seems like it might be a small subset of likely cases.  Any data
> on that?

I think this is fairly common - once a conference has been in progress 
for a while, it's natural to close to door to random strangers. In some 
cases, I suspect that there will be a human in the loop - "send email to 
[email-masked] and we'll add you to the member list".

If you get a person that you have to kick out because they are 
misbehaving, you might assume that this person has some incentive to 
re-join and continue his tirades.

It seems like that the better model for this is to affect mixing, and 
simply withdraw the floor from the person. This is needed in any event 
for the common case where somebody has put their phone on mute, not 
realizing that this generates music-on-hold (or walked out of the room, 
leaving the microphone on, which then captures street noise).

What cases are there that mixing policy wouldn't have the same effect 
than explicit removal?

Henning

---

From: Ted Hardie <[email-masked]>
Date: Wed, 12 May 2004 14:02:14 -0700

At 11:41 PM +0300 05/12/2004, <[email-masked]> wrote:
>
>However, I think the conferencing case is still different. There we 
>could not really live without the all-except construct. In 
>conference you don't just protect some data, but you also protect 
>the conference participants from a misbehaving participant. So 
>blocking and kicking out a single identity is important and useful, 
>even if the same person could join later with another identity.

And I think that is the crux of the question.  In previous discussions,
the idea that a misbehaving individual could mint an identity at
essentially no cost meant that creating an "any except" construct
didn't actually prevent much.  Your argument seems to say
that even though it doesn't prevent them from accessing the
conference, the *act* of kicking them out and blocking them
has some value in and of itself.

Speaking personally, it seems most likely to be valuable only
in cases where 1) the individual must mint a new identity (i.e. cannot
easily use a different, existing identity) and 2) this takes sufficient
time that the conference proceeds without disruption either to its
conclusion or for some significant period of time.  I'm not sure about
the percentage of cases likely to meet both 1 and 2.

		regards,
				Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Wed, 12 May 2004 15:51:32 -0700

At 5:31 PM -0400 05/12/2004, Henning Schulzrinne wrote:
>It seems like that the better model for this is to affect mixing, 
>and simply withdraw the floor from the person. This is needed in any 
>event for the common case where somebody has put their phone on 
>mute, not realizing that this generates music-on-hold (or walked out 
>of the room, leaving the microphone on, which then captures street 
>noise).
>
>What cases are there that mixing policy wouldn't have the same 
>effect than explicit removal?
>

It allows them to continue to listen to the call, which means it doesn't do the
same thing as the boot.  I assume there are cases where this is required
or desirable.
			Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 May 2004 20:42:56 -0400

> same thing as the boot.  I assume there are cases where this is required

Wouldn't that depend on the capability of the media mixer configuration?

---

From: Aki Niemi <[email-masked]>
Date: Thu, 13 May 2004 10:34:38 +0300

> [email-masked] and we'll add you to the member list".

Or set <confirmation>true</confirmation> in the authz policy, which 
would mean the moderator gets a notification of someone trying to join 
(using the conference-info events), and can reactively authorize that 
person.

However, this sort of admittance policy is well within the bounds of 
what common-policy already supports. No problem there.

> re-join and continue his tirades.

Certainly. Kicking someone off the conference is nothing more than a 
slap on the hand. Kicking and banning someone is a little bit stronger, 
but still not enough to guarantee good riddance of the misbehaving 
individual.

There is certain analogy here with IRC, where both /kick and /kick-ban 
are operations a channel operator can invoke. In IRC coming up with a 
new nick bears close to zero cost, yet both of these operations are 
needed and AFAIK, used in the real world.

I think we need the same features in CPCP since I think text chats are 
also one form of conferencing.

> What cases are there that mixing policy wouldn't have the same effect 

At least the experience is different for the participant being removed. 
Anyway, I think the requirement for CPCP to be able to expel 
participants is quite clear. I think this is also orthogonal to any 
mixing policy requirements.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Thu, 13 May 2004 11:17:29 +0300

[Replying to self...]

ext Aki Niemi wrote:
>> for a while, it's natural to close to door to random strangers. In 
>> some cases, I suspect that there will be a human in the loop - "send 
>> email to [email-masked] and we'll add you to the member list".
> 
> 

Except that this doesn't quite work. If I'd like to grant "allow" to a 
named few, and request that all others need confirmation before joining, 
I would need a rule construct like this:

<rule id="djkfh">
   <conditions>
     <identity>
       <uri>[email-masked]</uri>
       <uri>[email-masked]</uri>
       <uri>[email-masked]</uri>
     </identity>
   </conditions>
   <actions>
     <accept>true</accept>
   </actions>
</rule>

<rule id="kliel">
   <conditions>
     <identity>
       <anyone />
     </identity>
   </conditions>
   <actions>
     <confirmation>true</confirmation>
   </actions>
</rule>

Now, expelling someone so that not even confirmation is granted would 
require the second rule to be modified like this:

<rule id="kliel">
   <conditions>
     <identity>
       <anyone />
       <except>[email-masked]</except>
     </identity>
   </conditions>
   <actions>
     <confirmation>true</confirmation>
   </actions>
</rule>

...which is again an "all-except" construct.

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 May 2004 08:18:51 -0400

A random idea:

make the admission policy stateful and design a special condition that says

"any URI && if admitted for the first time, then [admit without 
confirmation|confirm|..."

The person kicked out would fail that test and get the special 
individualized treatment (such as confirmation required or rejection).

The drawback is that the higher-layer bouncer application would have to 
add the good guys to the explicit user list to make it easier for them 
to rejoin if they should leave temporarily, but that's probably 
unavoidable anyway if the initial admission requires confirmation. (You 
wouldn't want to have to manually approve each person in a large group 
each time they come and go.)

The advantage of tracking admission count is that this also simplifies 
the "ask when joining the conference for the first time, get admitted 
automatically if rejoining".

Aki Niemi wrote:

>> realizing that this generates music-on-hold (or walked out of the 
>> room, leaving the microphone on, which then captures street noise).
>>

---

From: Aki Niemi <[email-masked]>
Date: Fri, 14 May 2004 21:30:30 +0300

Hi Henning,

I think this is an interesting idea. But I don't see the difference 
between this approach, and one where upon first time confirmation the 
moderator explicitly grants a user an "allow" permission.

However, can we conclude that in these scenarios at least, there is 
anyway a valid requirement for having a condition statement that is for 
"any" identity?

Cheers,
Aki

ext Henning Schulzrinne wrote:
>>> I think this is fairly common - once a conference has been in 
>>> progress for a while, it's natural to close to door to random 
>>> strangers. In some cases, I suspect that there will be a human in the 
>>> loop - "send email to [email-masked] and we'll add you to 
>>> the member list".
>>
>>
>>
>> slap on the hand. Kicking and banning someone is a little bit 
>> stronger, but still not enough to guarantee good riddance of the 
>> misbehaving individual.
>>
>>> simply withdraw the floor from the person. This is needed in any 
>>> event for the common case where somebody has put their phone on mute, 
>>> not realizing that this generates music-on-hold (or walked out of the 
>> At least the experience is different for the participant being 
>> removed. Anyway, I think the requirement for CPCP to be able to expel

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 May 2004 15:00:27 -0400

I think my idea avoids violating the 'positive rules only' design 
criterion ('no exceptions'), as in

alice  anytime   admit
bob    firsttime confirm
*      firsttime confirm
trudy  anytime   deny

where Trudy is the person that got kicked out. New arrivals would match 
the '*' line (and maybe the Alice or Bob rule), and would require 
confirmation. Trudy, however, would only match the last rule, since 
she's not a first-timer. Clearly, you can't usefully have

*      anytime   admit
trudy  anytime   deny

> anyway a valid requirement for having a condition statement that is for 

Yes. One could event extend my mechanism to the IM/presence/call 
admission case, although I'm not arguing for that. It basically gives 
everyone one chance before being blacklisted. For conferences, the 
record is wiped clean at the end of the conference, while for the 
others, there would have to be some policy stating the statute of 
limitations for the banning.