Re: [Sip] draft-state-sip-relay-attack-00

["Nils Ohlmeier" <[e-mail]>]

> Hadriel Kaplan wrote:
>>
>>> -----Original Message-----
>>> From: Raphael Coeffic [mailto:[e-mail]]
>>> Sent: Tuesday, March 10, 2009 6:06 AM
>>>
>>> Hadriel Kaplan wrote:
>>>
>>> Forcing registrations is the path that IMS went for, I believe. But if
>>> you want to take advantage of this, you may have to deploy a little
>>> more
>>> IMS than you'd like to.
>>>
>>
>> The concept and practice of "forcing" UA's, which have AoR's belonging
>> to a domain, to REGISTER their contact binding for those AoR's in order
>> to make calls, has been around a lot longer than IMS has.  Invoking the
>> "that sounds like IMS" defense is a cheap guilt-by-association argument,
>> and not relevant.  One might as well argue that using INVITE's or RTP
>> "is the path that IMS went for".
>>
>> You keep making it sound like sending a SIP request which does not
>> create a dialog is somehow a difficult mechanism to implement, or
>> "forces" people to do something they don't want to.  What is it forcing?
>>
>>
> Well, it is not required as per RFC 3261 ;-)
>
>> You're looking for a means of authenticating a UA without being subject
>> to a relay attack.  Using a different SIP Method name, which can only be
>> initiated by the client with the credentials, and one that UA's cannot
>> be baited to provide by random third parties, is one solution to the
>> problem.  If you don't like the string "REGISTER", then how about
>> "OPTIONS"?
>>
>>
> No, I think you missunderstood me. I still think that requiring a
> registration and checking the source IP and port against the registered
> contact is a fair measure to take. However, it introduces more traffic
> in some scenarios, where it is not necessarily needed. REGISTERs could
> become the "background load" in the servers. This also puts a lot of
> state into some proxies that does not need it, etc...
> My concern is just that it seems like there is no better solution.

Sure to create a Contact binding via an authenticated REGISTER is one
possible solution.
But I think this only works because you rely on the fact that REGISTERs
are not being retargeted like INVITEs. Which then in the end means you
simply can forget about authenticating all other requests, as long as the
Contact or IP/port was successfully authenticated via the "one hop"
REGISTER method (refer-to: IMS).
The advantage of this solution is clearly that it can be easily deployed
by hopefully most of the service providers today.

But I believe the proper technical solution would be that the server
authenticates itself in the challenge, plus adding protected informations
to the challenge which allows the receiver of the challenge to verify that
this challenge was/is targeted to himself.
The dis-advantage is clearly that this would be only possible with
extensions of the existing protocols. But we would/might gain other
benefits by such a solution as well.

Regards
  Nils Ohlmeier