 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
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?
Seems like this approach is fraught with problems.
- 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.
Paul
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