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

[hisham.khartabil at nokia.com]

> -----Original Message-----
> From: Niemi Aki (Nokia-NRC/Helsinki) 
> Sent: 14.September.2004 16:41
> To: ext Paul Kyzivat
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); XCON WG
> Subject: Re: [XCON] CPCP Issue 28: <pin> and <password>
> 
> 
> Inline.
> 
> On Mon, 2004-09-13 at 20:14, ext Paul Kyzivat wrote:
> > By common usage today, it would be obtained because the initial 
> > connection is to an IVR that prompts for it. that dialog 
> isn't really 
> > part of the conference. How the result of it gets back to 
> the focus may 
> > need clarification.
> 
> Indeed, or how the call ends up in the IVR in the first place (more on
> this below).
> 
> > One possibility is that limited function voice only calls 
> are directed 
> > at a different server - an IVR. It does its prompting to 
> get a pin, and 
> > maybe conference id. Then it could:
> > - redirect the caller with a url to the focus that also 
> embeds the pin.
> >    In this case, the condition that checks the pin makes 
> perfect sense.
> >    The check is distinct from authentication, because the caller may
> >    not be authenticated at all, or may be authenticated 
> with an arbitrary
> >    identity.
> 
> If the URL is secret (embeds the pin as you suggest) and the IVR is
> configured to redirect callers that entered the correct id/pin to that
> secret URL, why does there need to be a pin condition? Isn't the fact
> that the caller enters the focus using a secret URL enough?
> 
> > - act as a b2bua. In this case it can provide suitable 
> authentication
> >    info which is chosen based on the pin. In this case no special
> >    conditions are needed - authorization can be based on the
> >    authenticated id provided by the b2bua.
> 
> I agree, this is one possibility. And it need not necessarily 
> be a B2BUA
> either. Simple proxy authentication is enough in most cases 
> where digest
> credentials can be used.
> 
> > Or, all calls can go directly to the focus. The 
> authorization rules can 
> > be applied based on what authenticated identity is 
> available, if any. If 
> > the call is going to be rejected, it can instead then be 
> treated with an 
> > IVR that prompts for a pin. Then the rules are applied 
> again with it.
> 
> Hmm... Do we in fact need another action defined, that redirects all
> callers to an IVR if they call the focus without proper authenticated
> identity?
> 
> > I'm sure there are other ways to handle this stuff as well. 
> But maybe 
> > these kinds of scenarios need to be explored to understand how the 
> > pin/password fits in with other authentication and 
> authorization strategies.
> 
> You're probably right. It seems there is at least a concept here of an
> "authentication service", that is able to provide authentication
> information to the focus to be used in matching with the rule
> conditions. An authenticated identity carried in for example as a
> P-Asserted-Identity is an obvious example, but non-identity based
> information could also be used, e.g., some SAML assertions 
> described in
> draft-tschofenig-sip-saml-00.txt.
> 
> But the <pin> condition is a poor attempt at that, especially as it is
> trivially transformed into an equivalent <identiy> condition.
> 
> Say, instead of:
> 
> <conditions>
> 	<pin/>
> </conditions>
> 
> you would have:
> 
> <conditions>
> 	<identity>
> 		<id>those_who_knew_the_PIN</id>
> 	</identity>
> </conditions>

The focus would have to create such identity (URI) based on the PIN. A user cannot create such URI. Also, what would be in the <id> element above that looks like an identity user at domain but tells the focus to interpret it as the secret URI for the conference that was somewhere created.

I don't by into this complexity at the conferece policy level. <pin> is enough to achieve that your asking for. <pin> condition exactly means "those_who_knew_the_PIN". Why does it have to an identity that is created somewhere? I don't think this is needed in a conference policy.

/Hisham

> 
> Cheers,
> Aki
> 
> > 	Paul
> > 
> > Aki Niemi wrote:
> > > Ok, I'll try.
> > > 
> > > There are different methods to access a conference. Some 
> can readily
> > > provide an identity to use in the conditions, others 
> can't. Some require
> > > that users are collectively authenticated using a 
> passcode, others can
> > > contain a random secret in the URI itself, or use specific
> > > username/password pairs for this collective passcode.
> > > 
> > > If you have all of the above type accesses to a 
> conference, and a single
> > > set of rules, for which accesses does the condition apply to?
> > > 
> > > What if I want all PSTN-access allowed using a passcode, 
> but all SIP
> > > access only using authenticated identities, and *not* 
> using a passcode?
> > > I can't see a single <passcode> condition covering both of these
> > > orthogonal cases.
> > > 
> > > That's why I proposed a separate ruleset for each access 
> method. If you
> > > have that, there's no need for the conditions you 
> propose. For example,
> > > if you've configured for a PSTN access to always prompt 
> for a PIN, then
> > > the only way ever anyone is ever going to get through 
> using that access
> > > is to know the PIN. (That would actually mean that you wouldn't
> > > necessarily need any conditions at all...)
> > > 
> > > Another option is to assign a special identity for the 
> PSTN-users in the
> > > system (who've entered the PIN correctly), and use that in the
> > > <identity> conditions. In other words, anyone who entered the PIN
> > > correctly will get that authenticated identity assigned 
> by the system.
> > > 
> > > This involves as much out-of-band configuration as 
> setting the PIN and
> > > configuring the PIN-prompt for it in the first place, and 
> requires no
> > > additional conditions to be defined.
> > > 
> > > Cheers,
> > > Aki
> > > 
> > > 
> > > On Mon, 2004-09-13 at 17:56, Khartabil Hisham 
> (Nokia-TP-MSW/Helsinki)
> > > wrote:
> > > 
> > >>Hi Aki,
> > >>
> > >>I don't understand your argument here. The way PSTN users are
> > >>authorised to join a conference is through a PIN. The 
> condition is if
> > >>they know the PIN, then they get in the conference. You 
> cannot know
> > >>the user behind a PSTN number and therefore need an 
> authorisation rule
> > >>based on PIN.
> > >>
> > >>Perhaps I didn't fully understand your proposal, can you re-state?
> > >>
> > >>Thanks,
> > >>Hisham
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > XCON mailing list
> > > XCON at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/xcon
> > > 
> > 
> 

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