FW: [XCON] CPCP Issue 31: Expelling a User

["Noa Kissilov" <NoaK at radvision.com>]

About passcode challenge: the contradiction is that if there is a rule
with value "block", the user can't join even if there is a way in for
him (he knows the passcode). This is a contradiction to "block" having
the lowest value and being overriden if there is any other rule allowing
a user to join.

I'll give an example to make sure it's clear what I'm trying to say.
Consider the following set of rules:

   	<rule id="1">
   		<conditions>
   			<identity>
   				<domain>example.com</domain>
   			</identity>
   		</conditions>
   		<actions>
   			<join-handling>allow</join-handling>
   		</actions>
   		<transformations/>
   	</rule>
  	<rule id="2">
   		<conditions>
   			<identity>
   				<uri>bob at example.com</uri>
   			</identity>
   		</conditions>
   		<actions>
   			<join-handling>block</join-handling>
   		</actions>
   		<transformations/>
   	</rule>


In this case bob would be allowed in, even though there is a rule
blocking him specifically (I took the example from section 5.4.1). Now
if the first rule is changed to have a passcode, bob will not be allowed
in even if he knows the passcode - he simply won't be challenged for it,
since there is a rule blocking him:

   	<rule id="1">
   		<conditions>
   			<identity>
   				<domain>example.com</domain>
   			</identity>
    			<participant-passcode/>
  		</conditions>
   		<actions>
   			<join-handling>allow</join-handling>
   		</actions>
   		<transformations/>
   	</rule>
  	<rule id="2">
   		<conditions>
   			<identity>
   				<uri>bob at example.com</uri>
   			</identity>
   		</conditions>
   		<actions>
   			<join-handling>block</join-handling>
   		</actions>
   		<transformations/>
   	</rule>

It seems absurd to me that once we decided to protect our conference in
a password the whole flow changes. BTW, rule no. 2 in the original
example has no impact otherwise, and needs to be denoted as an <except>
portion of the <identity> element. I suggest having it done the same way
for using passcodes - these rules are still equivalent to 

   	<rule id="1">
   		<conditions>
   			<identity>
   				<domain>example.com</domain>
				<except>bob at example.com</except>
   			</identity>
    			<participant-passcode/>
  		</conditions>
   		<actions>
   			<join-handling>allow</join-handling>
   		</actions>
   		<transformations/>
   	</rule>

And bob will not be allowed in even if he knows the passcode. It seems
to me like the right way to do it, and then we can also give up the
"block" value for this action - it will have no impact.

    noa.


-----Original Message-----
From: hisham.khartabil at nokia.com [mailto:hisham.khartabil at nokia.com] 
Sent: Monday, November 08, 2004 20:10
To: Noa Kissilov; xcon at ietf.org
Subject: RE: [XCON] CPCP Issue 31: Expelling a User




> -----Original Message-----
> From: ext Noa Kissilov [mailto:NoaK at radvision.com]
> Sent: 07.November.2004 15:01
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon at ietf.org
> Subject: RE: [XCON] CPCP Issue 31: Expelling a User
> 
> 
> 
> 
>     noa.
> 
> 
> -----Original Message-----
> From: hisham.khartabil at nokia.com [mailto:hisham.khartabil at nokia.com]
> Sent: Friday, November 05, 2004 12:18
> To: Noa Kissilov; xcon at ietf.org
> Subject: RE: [XCON] CPCP Issue 31: Expelling a User
> 
> 
> 
> 
> > -----Original Message-----
> > From: ext Noa Kissilov [mailto:NoaK at radvision.com]
> > Sent: 24.October.2004 12:41
> > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon at ietf.org
> > Subject: RE: [XCON] CPCP Issue 31: Expelling a User
> > 
> > 
> > Hi,
> > 
> > As I see it this problem is derived from the problem that
> > authorization RULES shouldn't be used to take actions on 
> > participants. A RULE is something referred to when you consider a 
> > certain behaviour. Action, such as having a server do something, 
> > should have a different mechanism
> > to be set. This is only one aspect of another question, which is the
> > essence of the conference policy document - is it a state descriptor
> > (like described about sidebars: if no sidebar element appears in
> > conference policy, it means there are no sidebars currently in the
> > conference, and vice versa), policy definition (like rules - someone
> > asks to do something, we check it with the policy and then 
> decide upon
> > our behavior), or a mechanism to fire actions? I believe currently 
> > there is a mixture between the 3, and this causes some inconsistency

> > and confusion. For example, for expelling a user we need to both 
> > change policy (so that this user will not be allowed in the
> > conference) and say
> > somehow to disconnect it now. These are 2 distinct tasks, and 
> > I believe
> > they should have 2 distinct mechanisms.
> 
> What you describe here is nothing new to us. We know and accept it.
> [noa] but now they are mixed. For example, it is said that when a 
> <join-handling> in a rule is set to "block", the focus should send 
> "bye".
> 
> "  Expelling a user is performed by a privileged user creating or
>    manipulating an existing authorization rule and setting that user's
>    <join-handling> action to "block>.  The focus reacts by terminating
>    the session with that participant, such as a sending SIP BYE
> request."
> 
> Now we can say that since <join-handling> is an action, it is OK that
> changing an action part of a rule causes action. But <join-handling> 
> is also used as a rule - to say who is allowed in the conference
> and who is
> not. It is part of the evaluation of joining request - which 
> is exactly
> a rule. So I'm confused about that...

It is a rule.  When a user changes a rule, the focus needs to be
informed about it. The focus, in this case, will be informed that a user
has been blocked now. The focus reacts by removing that user if no other
rule permits him to stay.

> 
> > 
> > Another question about this subject: why is it required to have
> > "block" value for actions?
> 
> Good question. But what you describe below is not a reason. It is a 
> good question because there is no need to explicitly block someone. By

> not having a rule there, it implicitly means that they are blocked. So

> I guess "block" is not needed. But the following text in the
> internet-draft might cause us to add it anyway:
> 
> "A focus need not care if a user using a passcode to join is calling
>    from a PSTN or an IP phone.  For example: Using a SIP phone, a SIP
>    INVITE request arrives directly at the focus.  The focus examines 
> the
>    identity and discovers that there are no rules allowing
> this identity
>    to join.  The focus also determines that there are no rules
>    explicitly prohibiting this identity from joining.  The 
> focus in this
>    case decides to challenge the identity for a passcode, if 
> there is a
>    rule that allows users with a passcode knowledge to join.  
> If no such
>    rule exists, the focus would not challenge for a passcode."
> 
> [noa] why do we need this? I mean, what happens if we challenge for
> passcode in any case there is a rule with passcode? If we leave the 
> flow like this, it means that <join-handling> with value "block" has
> precedence over passcode with <join-handling> with value "confirm" or
> "allow". Isn't it a contradiction? Just because passcode is something
> that has to be specifically asked for, I don't think it should affect
> the logic of rules processing.

A focus has to run through the rules anytime a user tries to join. What
is contradicting? A focus MAY choose to challenge for a passcode if it
does not find a rule explicitly blocking a user from joining.

/Hisham

> 
> Regards,
> Hisham
> 
> 
> > In the common policy it is stated specifically that
> > rules only permit. Why is "block" required anyway, especially when
> > it is with the lowest value of 0 and will be overridden upon any
> other value
> > apearance (in other rules)? It is stated that this is the default
> > anyway. Let's make it simpler...
> > 
> >     noa.
> > 
> > 
> > -----Original Message-----
> > From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf
> > Of hisham.khartabil at nokia.com
> > Sent: Monday, September 13, 2004 15:31
> > To: hisham.khartabil at nokia.com; xcon at ietf.org
> > Subject: RE: [XCON] CPCP Issue 31: Expelling a User
> > 
> > 
> > This is a draft-ietf-xcon-cpcp-00.txt issue now.
> > 
> > I have not received any comments about this and I honestly have no
> > idea how to simplify this besides creating a new expel list
> (which I don't
> > like).
> > 
> > If no one has any better ideas, then I will keep the text as is (no 
> > expel list, but to expel a user, multiple rules may need to be 
> > altered).
> > 
> > Regards,
> > Hisham
> > 
> > > -----Original Message-----
> > > From: xcon-bounces at ietf.org
> > [mailto:xcon-bounces at ietf.org]On Behalf Of
> > 
> > > ext hisham.khartabil at nokia.com
> > > Sent: 13.August.2004 16:14
> > > To: xcon at ietf.org
> > > Subject: [XCON] CPCP Issue 31: Expelling a User
> > > 
> > > 
> > > This issue was missed during the presentation since the chair
> > > ;) accidentally put up the old version of the slides.'
> > > 
> > > Back to the issue:
> > > 
> > > Care must be taken since if one rules allows a user to
> join and one
> > > blocks a user from joining, the result in that the user is
> > allowed to
> > > join.
> > >  
> > > For example, Bob can join a conference since an
> > authorization rule has
> > > been defined to allow everyone at example.com:
> > > 
> > > <rule id="1">
> > >    		<conditions>
> > >    			<identity>
> > >    				<domain>example.com</domain>
> > >    			</identity>
> > >    		</conditions>
> > >    		<actions>
> > >    			<join-handling>allow</join-handling>
> > >    		</actions>
> > >    		<transformations/>
> > > </rule>
> > > 
> > > Setting the following rule will not block Bob from joining
> > nor will it
> > > expel him since the above rule overrides it:
> > > 
> > >   	<rule id="2">
> > >    		<conditions>
> > >    			<identity>
> > >    				<uri>bob at example.com</uri>
> > >    			</identity>
> > >    		</conditions>
> > >    		<actions>
> > >    			<join-handling>block</join-handling>
> > >    		</actions>
> > > 		<transformations/>
> > >    	</rule>
> > > 
> > > So, in order to expel Bob, the original rule has to be
> > modified using
> > > the <except> element:
> > > 
> > >    	<rule id="1">
> > >    		<conditions>
> > >    			<identity>
> > >    				<domain>example.com</domain>
> > >    				<except>bob at domain.com</except>
> > >    			</identity>
> > >    		</conditions>
> > >    		<actions>
> > >    			<join-handling>allow</join-handling>
> > >    		</actions>
> > >    		<transformations/>
> > > 	</rule>
> > > 
> > > This type of behaviour makes it very hard to a client
> implementation
> 
> > > to figure out how to expel a user because it depends on all
> > the rules
> > > in a conference. It must go through all the rules and
> > change all the
> > > necessary ones so that that user is not capable of joining again.
> > > 
> > > Does anyone have ideas on how to simplify this? A separate
> > expel list
> > > that overrides any rules???
> > > 
> > > Regards,
> > > Hisham
> > > 
> > > _______________________________________________
> > > XCON mailing list
> > > XCON at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/xcon
> > > 
> > 
> > _______________________________________________
> > XCON mailing list
> > XCON at ietf.org
> > https://www1.ietf.org/mailman/listinfo/xcon
> > 
> > 
> 
> 


_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon