On Wed, Mar 4, 2009 at 10:34 AM, Raphael Coeffic <[email protected]> wrote: > The appropriate mitigations of problem resolutions are still not 100% clear. > We hope that this draft can help start a discussion on how to best resolve > this problem.
After more thinking about this, I don't think this document presents anything other than there are poorly implemented SIP endpoints and proxies out there - as there is nothing wrong with SIP itself [1] in these attacks: It all boils down to UA vendors currently giving credentials to anyone who asks for them, even if they shouldn't be. All of the scenarios you mention in this document apply directly to proxy authentication in the case where a UA would use outbound authentication with it's proxy. A UA only ever sending proxy credentials to it's proxy seems like a dead simple and sensible thing to do (and although i'm not really surprised UAs don't do this, i'll pretend to be), and makes all the attacks you list just go away. The only issue i see is in fig 3, how to identify a next hop is actually proxy.com and not bob, as a proxy will commonly RR with a URI such as node-01.proxy.com instead of proxy.com, or even use an IP address in it. The first, and most and correct way is use TLS or DTLS with mutual auth, and you can verify that the next hop is really your proxy and thus it's ok to send credentials to it. The second way is to always send requests to proxy.com (i.e, using outboind), even in dialog ones (and indeed many UAs have a "send in-dialog requests via outbound proxy" option,which makes this attack go away) - although this might breaks some broken SBCs out there that SPs deploy today. The third option (and most ickly and hacky) it to build and keep a whitelist of IP addresses that proxy.com is, and ensure the SP only ever record-routes using an IP address that a forward lookup on proxy.com would resolve to. crappy but in reality mostly works today, as long as devices are sensible and do things like refresh after TTLs expire on RRsets. So, what does need to be done is beat UA vendors and SIP operators with a great big security clue stick (how that's done i'd love to know. My stick is almost broken, and even when applied directly, mostly ineffective.) - perhaps a BCP to highlight the issues? However, you don't cover the more interesting cases of multi-hop proxy authentication or end-to-end WWW authentication: these are the harder ones to deal with, and may result in some "real" issues in SIP itself rather than shoddy implementations and insecure proxies. ~ Theo 1 - heh. sarcasm. _______________________________________________ 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
