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
