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

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

Thanks. I am not talking about changing examples, but changing the
CHOICE that the focus has, regarding challenging a user for password or
not. The following section:

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

We started this discussion by saying that this is a reason for us having
the "block" value for <join-handling> action. I am saying that this
behavior (not challenging if there is a rule with "block") is
inconsistent, and the behavior should be changed (and as a result the
"block" value is really unnecessary).

    noa.


-----Original Message-----
From: hisham.khartabil at nokia.com [mailto:hisham.khartabil at nokia.com] 
Sent: Wednesday, November 10, 2004 14:34
To: Noa Kissilov
Subject: RE: [XCON] CPCP Issue 31: Expelling a User


Noa,

Thanks for this email. What you are saying is true. But we don't dictate
how rules should be set. If you want to represent them the way you
describe, then there is nothing stopping you. We just show very few
examples in the draft that may or may not fit your taste.

Are you talking about specifically changing examples in the current
draft? If so, which ones?

Thanks,
Hisham

> -----Original Message-----
> From: ext Noa Kissilov [mailto:NoaK at radvision.com]
> Sent: 10.November.2004 09:59
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Subject: RE: [XCON] CPCP Issue 31: Expelling a User
> 
> 
> 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