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. Hi Raphael, Thanks for documenting this! page 10: It is worth noting that the protection provided on the request URI is purely theoretical, as [RFC3261] introduces an exception to the request URI checking required by [RFC2617] in section 22.4: Another important consideration to keep in mind while thinking about solutions is that the Contact header in the dialog creating request can be pretty much anything bob likes if he also adds a Record-Route header in, leading to the dialog target URI at alice's UA being whatever bob wants, and thus the Authentication header can be manipulated to contain whatever the attacker wants in the uri parameter. To explain - consider Figure 1 in the draft F1 could be sent by [email protected] as: INVITE sip:[email protected] SIP/2.0 Contact: <sip:[email protected]> Record-Route: <sip:[email protected];lr> thus, when alice creates the dialog, the remote URI will indeed be [email protected], and your in-dialog F10 message will be: F10 INVITE Alice -> Bob INVITE sip:[email protected] SIP/2.0 Route: <sip:[email protected];lr> Proxy-Authorization: Digest username="alice", realm="proxy.com", uri="sip:[email protected]", nonce="f84f1cec41e6cbe5aea9c8e88d359543", response="3bea678acef9875433487f23a567d876", opaque="", algorithm=MD5 Content-Type: application/sdp Content-Length:... presto - the authentication header now even contains the URI you want to call. note that a re-INVITE could also be done to change the target URI a few times to get different Authentication headers with different URIs in, all legitimate. As to the potential solutions: both only accepting from registered contact or any attempt at avoiding sending re-INVITE [1] are in my opinion unfeasible and broken - i'll have some thought on others, though :-) ~ Theo 1 - REFER is another in-dialog method that could be abused - an OOD REFER may be accepted with authentication by - for example - a PSTN gateway. Social engineering of alice could result in alice's UA sending a REFER that could then be used. _______________________________________________ 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
