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. >> 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. 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. Regards, Michael _______________________________________________ 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
