Hi Theo,
I really think that mutual authentication is the way to go.
Unfortunatly, there is nothing deployed in this direction right now.
Most providers (at least in germany) try to tackle those issues by
separating networks. The SIP phones are then jailed into things like
dedicated virtual circuits (on the DSL level). On the provider-side,
they use the full panel of firewalls to get the full control of
everything. This is definitely not the way to go.
Having the BCP gathered into this document (or another one, I don't
care) would be a good thing to do. If you let people think by
themselves, you might end-up with the situation we have right now.
Theo Zourzouvillys wrote:
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.
If you provide me with the input, I'd be very happy to document those
issues.
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
