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

[Aki Niemi <aki.niemi at nokia.com>]

Inline.

On Fri, 2004-08-13 at 17:40, ext Paul Kyzivat wrote:
> Hisham - comments inline.
> 
> 	Paul
> 
> hisham.khartabil at nokia.com wrote:
> > Users who are using a PSTN phone to join a conference can
> authenticate using a PIN (traditional way). We use the <pin> condition
> for this.
> > 
> > Users who are aware of the conference password can join,
> irrespective of their identity. So anyone who knows the password was
> join. We use the <password> condition for this.
> > 
> > There was a huge confusion about the useability of these 2
> conditions. A question was raised on how a focus would react if the
> password was changed for the conference. Another was raised on what
> does it mean for a user to be authenticated and then requiring them to
> enter a password?
> > 
> > There were also comments that a conference policy should not assign
> passwords. Those are assigned out of band. The conference policy would
> then just require the password.
> > 
> > There was no consensus on any of these issues. Here is a concrete
> proposal:
> 
> 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.

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.

Cheers,
AKi


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