RE: [XCON] CPCP Issue 28: <pin> and <password>

[hisham.khartabil at nokia.com]

> -----Original Message-----
> From: ext Noa Kissilov [mailto:NoaK at radvision.com]
> Sent: 07.November.2004 15:36
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); 
> pkyzivat at cisco.com; Niemi
> Aki (Nokia-NRC/Helsinki)
> Cc: xcon at ietf.org
> Subject: RE: [XCON] CPCP Issue 28: <pin> and <password>
> 
> 
> If there is no <mixing-start-time>, then the conference should start
> immediately when conference policy is submitted. Now, setting 
> a password
> to the conference should be done at the focus at conference creation
> time (otherwise anyone can conncect). 

No, it means that no one can connect using a passcode because it has not been assigned yet.

>So it means that the 
> CPS needs to
> wait with the creation until the password is received. (which is
> inconsistent with the saying that if there is no <mixing-start-time>
> element the conference starts immediately). 

Again, you can create the conference immediately. You are assuming here that a conference only has users joining with a passcode, which is not always the case. It is actually the rare case.  But lets way it was the case, then those users cannot join until a passcode is created and assigned to the conference.

/Hisham


> 
> So I thought a solution to that might be to allow a setting a 
> conference
> password before... But's I don't think this works (unless the CPS
> supports something like: "here is a passcode, use it to conference X
> which I will tell you about later". I'm not sure this is a nice
> mechanism).
> 
> 
>     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; pkyzivat at cisco.com; aki.niemi at nokia.com
> Cc: xcon at ietf.org
> Subject: RE: [XCON] CPCP Issue 28: <pin> and <password>
> 
> 
> 
> -----Original Message-----
> From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org]On Behalf Of
> ext Noa Kissilov
> Sent: 24.October.2004 12:44
> To: pkyzivat at cisco.com; Niemi Aki (Nokia-NRC/Helsinki)
> Cc: xcon at ietf.org
> Subject: RE: [XCON] CPCP Issue 28: <pin> and <password>
> 
> 
> Hi,
> Regarding the passcode being transferred to the server out of band, I
> see a problem: what happens when a new conference policy document is
> created in the CPS? It cannot just create the conference, since a
> password or a PIN number needs to be transferred to it out of band (no
> one will be able to connect). 
> It can create a conference. No one can join until the 
> passcode has been
> created.
> 
>   But how is it transferred out of band before there is a 
> conference? If
> there is such a thing so the CPS needs to know about a 
> conference before
> it knows about it via the conference policy document. 
> Creating a conference policy does not mean the conference starts
> immediately. The CPS needs to know and can use the conference policy.
> why would you create a passcode when you haven't created a conference
> policy?
> /Hisham
>     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:28
> To: pkyzivat at cisco.com; aki.niemi at nokia.com
> Cc: xcon at ietf.org
> Subject: RE: [XCON] CPCP Issue 28: <pin> and <password>
> 
> 
> This issue is now a draft-ietf-xcon-cpcp-00.txt issue.
> I think we are being way too creative here. We have 3 simple
> requirements:
> 1. Allow PSTN users to join a conference using a PIN
> 2. Allow IP users to join using passwords
> 3. Allow IP users to join using individual passwords
> The first requirement can be achieved by allowing a rule to 
> have a <pin>
> as a condition. The PIN (or a multiplicity of PINs, if you wish) is
> created and delivered to users out of band and therefore does not need
> to appear in the conference policy. The following rule says that if
> anyone knows the PIN, then they can join the conference:
>         <rule id="1">
>                 <conditions>
>                         <pin/>
>                 </conditions>
>                 <actions>
>                         <join-handling>allow</join-handling>
>                 </actions>
>                 <transformations/>
>         </rule>
> 
> 
> The second requirement can be solved in a similar fashion as the first
> one; use of <password>. The passwords are created and 
> delivered to users
> out of band and therefore do not need to appear in the conference
> policy. The following rule says that if anyone knows a password, then
> they can join the conference:
>         <rule id="1">
>                 <conditions>
>                         <password/>
>                 </conditions>
>                 <actions>
>                         <join-handling>allow</join-handling>
>                 </actions>
>                 <transformations/>
>         </rule>
> The third requirement is redundant since the presence of a rule that
> allows a user to join is enough. The rule itself authorises that user
> with that specific identity to join the conference and 
> therefore no need
> for individual passwords. Having said that, the syntax does 
> not prohibit
> implementers from creating such rules that carry both the 
> identity and a
> password condition.
> Regards,
> Hisham
> > -----Original Message-----
> > From: ext Paul Kyzivat [mailto:pkyzivat at cisco.com]
> > Sent: 26.August.2004 22:17
> > To: Niemi Aki (Nokia-M/Espoo)
> > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); xcon at ietf.org
> > Subject: Re: [XCON] CPCP Issue 28: <pin> and <password>
> > 
> > 
> > 
> > 
> > Aki Niemi wrote:
> > > 
> > >>I seem to recall that there was a recognition that
> > pins/passwords can
> > >>be used in two ways:
> > >>
> > >>- they may be used as a means of authenticating. In this
> > case the pin
> > >>   or password is specific to an identity that must also 
> be provided
> > >>
> > >>- they may be used as a shared secret for a conference, where 
> > >>possession
> > >>   grants admission to the conference regardless of identity.
> > >>
> > >>The first form is irrelevant to CPCP, since its use would simply 
> > >>provide the identity that is used by CPCP for authorization. It is
> > the second
> > >>usage that needs to be discussed in CPCP.
> > > 
> > > 
> > > Agree. Concretely, the first would require the ability to 
> create new
> 
> > > user accounts (e.g., username/password) in the conference 
> domain and
> 
> > > delivering the associated credentials individually to intended 
> > > participants. So it's all about authentication - there is
> > really nothing
> > > specific to authorization.
> > 
> > OK. We are in agreement here. Good.
> > 
> > > The second I think is best handled in the conference 
> configuration. 
> > > I.e., when getting a <conference-uri> in the <settings>,
> > that URI (like
> > > a SIP URI) can be either made to contain randomness with
> > enough entropy
> > > as to be able to be used as a "secret", or can be
> > accompanied with a PIN
> > > prompt (works best for PSTN access, but also with SIP etc.
> > using DTMF).
> > > 
> > > The question is, given that there could be various
> > <conference-uri>s in
> > > place, should there be a condition that can match a request to a 
> > > specific <conference-uri> that was accessed?
> > > 
> > > Or alternatively, should each <rule> or <ruleset> actually
> > only apply to
> > > a given <conference-uri>, for example:
> > > 
> > > <ruleset for="tel:+3589123456"; conf-id="344535" pin="4558982">
> > >    <rule id="public">
> > >       ...
> > >    </rule>
> > >    <rule id="private">
> > >       ...
> > >    </rule>
> > > </ruleset>
> > > 
> > > <ruleset id="sip:foobar at example.com">
> > >    <rule id="something">
> > >       ...
> > >    </rule>
> > > </ruleset>
> > > 
> > > Something along these lines could actually be used instead of the 
> > > <settings> and <conference-uri> elements. I.e., if you
> > wanted to assign
> > > a new URI for the conference, you'd do it by creating a
> > completely new
> > > ruleset for it.
> > 
> > One way of achieving this is to move the PIN management to an
> > entirely 
> > different scope. Assume your other suggestion - that the 
> > fundamental way 
> > of granting access by possession of a secret is by use of a 
> > pseudo-random conference uri.
> > 
> > If there are users that can't deal with that, and need a 
> pin instead,
> > give them the address of another server - a PIN server. When 
> > called, it 
> > first prompts the caller for the PIN. Then based on that it 
> > looks up the 
> > actual conference URI and forwards the caller to it.
> > 
> > This is somewhat appealing because it means all the initial 
> prompting
> > for the PIN isn't part of the conference at all.
> > 
> > The downside is that you need two different addresses - one 
> for those
> > who will use a PIN and a different one for those who won't. 
> But maybe 
> > this is the same as the difference between a sip url and a tel url. 
> > Chances are the pseudo-random addresses will be sip addresses 
> > which are 
> > cheap, while perhaps tel addresses will always be to a pin server.
> > 
> >       Paul
> > 
> > 
> > 
> _______________________________________________
> 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