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

[Paul Kyzivat <pkyzivat at cisco.com>]

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