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

Hello Michael,

Michael Procter wrote:
> Raphael Coeffic wrote:
>   
>> Michael Procter wrote: 
>>     
>>> I'm intrigued by the variation in fig2.  How often are you finding two
>>> proxies in different administrative domains that use the same
>>> credentials?  Or is the attack more focussed towards Alice using
>>> multiple sets of credentials?
>>>
>>>   
>>>       
>> They are not using the same credentials, which is the reason why
>> 'proxy.com' won't remove Alice's credentials from the request, and
>> thus enable the attack.
>>     
>
> I see - it wasn't entirely clear from your text which case you were
> addressing.  So that scenario is essentially the normal MITM digest
> attack.  Whenever you receive a challenge, you can't really authenticate
> the server that is challenging you to determine whether you should issue
> a valid response or not.
>
>   

That's true. The novelty is that such a MITM attack can be induced by 
SIP means, without to much interventions into the network topology (no 
DNS or ARP spoofing for example).

>>> I think that the variation in fig3 can be addressed to some degree by
>>> using GRUU, but I don't think that completely solves the problem.
>>>   
>>>       
>> I am not quite sure that I understand how this helps: could you
>> develop your thoughts a little bit more?
>>     
>
> Sorry - I mistyped!  What I meant to say was that 'outbound' addresses
> the problem to some degree.  To expand on that a little, the key in fig3
> is for Bob to be able to send a response directly to Alice, without
> going through the proxy.  In the hosted scenario (which I considered
> first), Alice is typically behind a NAT/FW and uses outbound to maintain
> flows to proxy.com.  As a consequence of this, Alice should only act
> upon responses received over these flows.  This would defeat the attack
> in fig3, since Bob's altered response would probably not even reach
> Alice, let alone be acted upon.
>
> In the non-hosted scenario, where Alice and proxy.com are on the same
> network (i.e. without NAT/FW issues) such as might be the case in a
> typical enterprise deployment, then outbound wouldn't be used.  But in
> this case, I would expect the enterprise firewall to prevent
> communications from Bob to Alice, except when mediated by an appropriate
> device (such as proxy.com).  Again, the scenario in fig3 would be defeated.
>
>   
Imho, not necessarily. It is very easy to forge an IP (that of the 
proxy) if you only need one-way communication, which is the case for the 
200 reply. This means that it should be quite easy to get this reply 
directly to Alice. The question is what Alice and the outbound proxy 
will do after that.

> That isn't to say that the attack in fig3 isn't a real attack, only that
> I wouldn't expect most deployed networks to suffer from it.
>
>   
You may be right.

Best regards,
Raphael.
_______________________________________________
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