Re: draft-state-sip-relay-attack-00

Nils, Jonathan,

You may be aware of it or not, however, we have already implemented this 
scenario at iptel.org. This is because iptel.org does not have any own 
PSTN gateway. In this case, the user can configure a PSTN gateway he 
whishes to use when such a number is dialed. We implemented like this to 
cope with all the low-end phones that do not provide multiple accounts, 
or do not offer a convenient way for the user to provide routing rules.

Even cisco and snom phones (at least those we have) are not able to 
select the outbound account on their own, based on the R-URI. On the 
other hand, this is very easy to offer at the proxy level, provided that 
my proxy does relay challenges and responses to the UA (in this case, 
the realm is different).

So, as a conclusion, I do not think we are talking about theory, but 
about real existing applications. Of course, you could also store your 
other PSTN credentials at the proxy, and make it deal with the 
authentication for you. However, I'm quite sure you wouldn't be very 
confident about that, would you?

Regards,
Raphael.

Nils Ohlmeier wrote:
>>>> Server identity can be verified by normal server-only auth between a
>>>> client and its server, but even that is not needed.
>>> Right, mutual authentication seems to be the best way.
>>>
>>>> A client will know which domain its proxy is representing, and once
>>>> connected, it only provides credentials for that domain.
>>>>
>>> What do you mean by "connected"? And why should a UA only provide
>>> credentials for one domain only?
>>
>> I'm saying, when a phone registers or makes a call, it does so by
>> connecting to a SIP server, through a domain name or IP config or
>> whatever. THat server will have an associated credential. For any
>> request sent to that server, it should never provide a credential except
>> the one associated with it.
>>
>> Your attack is possible only when the client sends credentials for a
>> domain, different than the one it is currently registered or placed the
>> call through in the first place.
>
> And the SIP server which relays the INVITE from the attacker to the 
> victim has to drop (?) the challenge if it receives such from the 
> attacker (at least if the realm is identical to the one used by the 
> server itself).
>
> This is basically the same description which I provided already earlier.
>
> The only open "issue" is then relaying of 407/401 replies from 
> downstream elements by the proxy. I agree with Jonathan that I also do 
> not believe that this actually a real world scenario. But mutual 
> authentication in the challenge might help to solve this issue if 
> people insist of keeping this scenario.
>
> Regards
>   Nils

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip