Hello, first of all I agree that the draft describes a potential problem.
One thing which is not that obvious but is implictly a requirement for the attack: the proxies has to challenge in-dialog requests. I do not see a big benefit in challeging in-dialog requests as these are hopefully rejected by the remote side if no matching dialog exists. If the UA would know that his proxy does not challenge in-dialog requests it could simply ignore the challenge :-) Some more comments: Figure 1: - As the draft already states this direct attack becomes inpossible if Alice UA accepts incoming requests only from one of its proxys (we have to keep in mind that we rely here on pure IP layer security which is weak as we all know). - Additionally Alice UA should notice that the call got established without a route set. And without any Route set I would not see why the UA should get a challenge at all. But I admit that such a check most likely does not exist in UA today. Figure 2: - If p2.com uses a different realm then proxy.com you should mention in your draft that Bob needs to know that Alice has accounts configured for both servers in her UA. - I never unterstood why a proxy should pass through the authentication request from a foreign domain. In which scenario do I have credentials for two different domains, but the traffic including authentication is passed through only one of them? Sure I could have a call forwarding from p2.com to proxy.com. Again only if p2.com challenges in-dialog requests the problem arrises with this call forwarding. - Another possible improvement for an UA would be to strictly bind the credentials to one proxy. Which means it would only answer challenges for proxy.com if the request came IP wise from proxy.com and it would not answer challenges for other proxies if they arrive IP wise from proxy.com. This improvement does not work if you use daisy chained proxy with authentication for outbound calls (but I have never seen or heard of such a setup), or if the proxy with active call forwarding challenges in-dialog requests. - If we admit that this authentication pass through is of no real use, either Alice UA could ignore it, or proxy.com could simply strip the authentication from the foreign domain p2.com. - If we still need authentication pass through proxy.com could at least check that it does not pass through challenges with the same realm as its own one (which brakes daisy chains of challenging proxy with identical realms - which is hopefully not too comon). I admit that my comments are no real solution for the problem itself and some of them would first need to be implemented. But hopefully they help to improve the situation. Regards Nils Ohlmeier VoIP Freelancer > Hello, > > a new internet draft has been published concerning the relay attack on > digest authentication and SIP. The attack itself has been first > disclosed 2 years ago by the maydnes team from the french INRIA. Until > now, no document has been pushlished that documents the attack and > provides guidance to SIP operators or handset manufacturers. > > http://tools.ietf.org/html/draft-state-sip-relay-attack-00 > > 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. > > > Regards, > > Raphael Coeffic. > (on behalf of all the authors of this draft) > > --------------------------------------------------------------------------------------------------- > > Filename: draft-state-sip-relay-attack > Version: 00 > Staging URL: > http://www3.ietf.org/proceedings/staging/draft-state-sip-relay-attack-00.txt > Title: SIP digest authentication relay attack > Creation_date: 2009-03-02 > WG ID: Indvidual Submission > Number_of_pages: 18 > Abstract: > The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism > for creating, modifying, and terminating sessions with one or more > participants. This document describes a vulnerability of SIP > combined with HTTP Digest Access Authentication [RFC2617] through > which an attacker can leverage the victim's credentials to send > authenticated requests on his behalf. This attack is different from > the man-in-the-middle (MITM) attack and does not require any > eavesdropping, DNS or IP spoofing. > > > > _______________________________________________ > 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 > > _______________________________________________ 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
