Scott Lawrence wrote:
> On Mon, 2008-01-28 at 10:41 -0500, Paul Kyzivat wrote:
>> authentication is
>>>> rarely done on in-dialog requests. Bypassing it assumes that the dialog
>>>> id is only known to the parties on the signaling path, even though this
>>>> might not be true.
>>> We've recently started challenging some in-dialog requests:
>>> specifically, any REFER without Replaces is challenged by our proxy so
>>> that we can use the identity of the transfer controller to authorize the
>>> INVITE generated by the transferee.
>> Can you explain further? (I'm just curious to understand what is in the
>> wild.)
>
> It helps to understand the problem we were trying to solve. The proxy
> may restrict some users to a subset of possible calls - for example, I
> might be allowed to make local PSTN calls but not International PSTN
> calls. This is enforced by challenging an INVITE that requires some
> privilege level and then using the authenticated identity to look for
> that privilege (note: this has no relationship to any registration
> authentication; registration only controls what calls we route _to_ a
> UAS; it has no effect on calls _from_ a UAC).
You say there is no relationship. Do you mean that this is an
independent authentication, from a different realm with unique
credentials from those used for registration? Or do you just mean tha
registration doesn't confer a right to make these calls, so they are
still challenged, but that the same realm and credentials are used.
(I'm trying to understand what the UA needs to know to participate.)
This all sounds like interesting fodder for BLISS.
Thanks,
Paul
> We want it to be true
> that if I can call a given target, then I can also transfer any call to
> that target. The problem is that in a blind transfer, the transferee
> sends the INVITE to the transfer target - and the tranferee may not be
> in the local domain or have any credentials for it. We want that INVITE
> to be authorized using the identity of the transfer controller, so...
>
> Our proxy looks at any REFER; if all of these are true:
> 1. The Refer-To URI is in the domain the proxy is authoritative for
> 2. There is no Replaces header parameter on the Refer-To uri
> 3. The request is not authenticated
> then it challenges the REFER for authentication.
>
> Transfers to some other domain are not challenged (this is because in
> practice they seem to usually be from a party in that foreign domain so
> the controller isn't likely to have local credentials)
>
> Consultative transfer completions (REFER with Replaces) are not
> challenged because the authorization for both existing call legs has
> already been done; this REFER is just switching the endpoints around.
>
> When the proxy gets an authenticated blind transfer requests (REFER with
> 1 & 2 above true and 3 false), it rewrites the Refer-To URI, adding a
> private signed identity header parameter to it. When the transferee
> sends the INVITE, this private header shows up at the proxy as an
> identity that it can then use to authorize the call.
>
> Yes, I know that this is not perfectly secure, but in practice it's good
> enough for our needs.
>
> You can try it on our public test server: interop.pingtel.com
>
>
>> This is the proxy on the terminating side? (The one that did the AOR to
>> Contact translation on the initial invite.) And its expecting the same
>> credential that is used to authorize registration?
>>
>> If so, that in effect means only an agent operating on behalf of the
>> callee will be able to initiate such a REFER. Right? (That seems a sane
>> policy, but it certainly is a *policy*, and there could be others.)
>
> Not quite - either party could initiate the REFER. The restriction is
> that only a party that has credentials in the proxies domain can blind
> transfer to an address in the proxies domain. This does mean that some
> transfers could fail that would otherwise succeed (you are outside my
> domain and transfer me to a target in my domain that I could have called
> but you could not have, which would work if the proxy let the REFER
> through unauthenticated), but that failure is less interesting and less
> common than the problem we're trying to solve.
>
>> This of course depends on that proxy having record-routed.
>
> Yes, but our proxy always does.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
