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

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

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

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