What is the real concern here?
Why would you care if the caller has registered? SIP does not require
registration to send requests.
I guess you either are concerned that the caller is somehow authorized
to call you, or call anybody, or else you are concerned with whether you
can trust the identity of the caller as specified by the incoming request.
Whether the caller is authorized to send invites is really none of your
business. If the invite was sent, and reached you, then presumably the
caller had as much authorization as it needed.
Whether the caller is authorized to call *you* is your problem. If you
are concerned about the call reaching you via your proxy or not, then it
seems you want to delegate some of the authorization of callers to your
proxy. Doing so has to be an agreement between you and your proxy. That
agreement will have some responsibilities for each of you. Those are not
standardized - you will have to consult the documentation for the proxy
you use. If that is your intent, then you probably want to reject calls
that don't arrive with the proxy as the prior hop (in Via). If not, in
theory you could return a 305 response, telling the caller to try again
via the proxy. But the exact use of 305 is underspecified so that's
unlikely to work well.
Whether you can trust the identity of the caller depends on the
environment in which you are embedded. An infrastructure such as
3gpp/IMS has a number of extra mechanisms to control access, and then
depends on transitive trust. If you are registered within IMS and
receive a request in accord with that you can, within limits, trust the
ID provided via P-Asserted-Identity. Enterprise SIP networks, such as
"SIP PBXs" also typically control things and depend on transitive trust.
Outside such environments it gets harder. SIP Identity (RFC 4474) is
intended for this, but isn't implemented much. You could of course
challenge the caller using digest authentication, but that would require
that you have a password for every caller, which isn't very likely.
Absent that, you should probably consider the identity of the caller (in
the From header of the invite) as suspect. Whether you want to answer
such calls is up to you, for general telephony I think most would want
to at least alert and let the user decide whether to answer.
Thanks,
Paul
On 1/12/12 3:56 AM, Vineet Menon wrote:
> Hi,
>
> Again, you can force route all calls thru the proxy so that calls
> will always be routed thru the proxy. So that, a session hijacking can be
> avoided.
>
> In addition to this, I wanted to clarify whether the use of proxy avoid
> another user from calling your UA without registering to proxy ? eg. using
> IP dialing...
> How can this be avoided? I am peculiarly concerned because this is like
> some malicious user is using your infrastructure for his own purpose. I
> believe SIP in its core cannot do this!!
>
> Regards,
>
> Vineet Menon
>
>
>
>
> On 11 January 2012 19:41, Kevin P. Fleming<kpflem...@digium.com> wrote:
>
>> On 01/11/2012 07:11 AM, Sandro wrote:
>>> Hello all.
>>>
>>> I have a theoretical question about call admitting and security.
>>>
>>> Let's say we have two clients A&B (phones or softphones) and a
>>> proxy/registrar.
>>> Clients register themselves on the registrar with authentication (http
>>> digest).
>>> This is, i think, the most normal scenario.
>>>
>>> Proxy authenticates incoming (from the clients) calls, this means invite
>>> messages, with the same registrar credentials, and this gives it a
>> certain
>>> degree of security.
>>>
>>> What happens for clients?
>>> I mean, how can a client "authorize/authenticate" a call coming from the
>>> proxy and become sure it's is *really* coming from its proxy?
>>>
>>> Let's say for example that a "C" malicious client/proxy is sending
>> INVITEs
>>> to A.
>>> How can A recognize that these INVITEs are not related to the REGISTER
>>> "session" to the proxy?
>>
>> There is no perfect method to do this, but one very common method is for
>> the UA that REGISTERs to include a randomly-generated token in the
>> Contact URI that it supplies to the registrar; incoming INVITEs
>> generated by UAs that obtained the Contact URI from that registrar will
>> then include that token, and the receiving UA can 'trust' that the
>> INVITE was generated by a UA that was authorized by the registrar to do so.
>>
>> This can easily be sniffed by a third party if the SIP signaling is not
>> secured, of course.
>>
>> --
>> Kevin P. Fleming
>> Digium, Inc. | Director of Software Technologies
>> Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> Check us out at www.digium.com& www.asterisk.org
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
