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). 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.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/
http://www.pingtel.com/
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
