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

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

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>

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