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

Reply via email to