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

[hisham.khartabil at nokia.com]

I agree that there is no need to separate the two. Perhaps password alone will suffice if we think of digits entered by a user in the PSTN domain as a password string.

Maybe change it to <passcode>?

Regards,
Hisham

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: 13.September.2004 16:55
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: Niemi Aki (Nokia-NRC/Helsinki); xcon at ietf.org
> Subject: Re: [XCON] CPCP Issue 28: <pin> and <password>
> 
> 
> Hisham,
> 
> I pretty much agree with your analysis. But having broken it 
> down that 
> way, what is the fundamental difference between a pin and a password? 
> Isn't a pin just a password that happens to be all numeric?
> 
> I only see a reason for a distinction if there is to be some 
> difference 
> in how they are applied. For instance, since pins are usually 
> drawn from 
> a fairly small space of possible values, they can be more 
> easily tried 
> exhaustively. So there may be special measures to prevent 
> many retries. 
> But if there is nothing in cpcp to cover this, then I think 
> there is no 
> reason to distinguish between the two.
> 
> 	Paul
> 
> hisham.khartabil at nokia.com wrote:
> > 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