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

[hisham.khartabil at nokia.com]

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