Nils, On 05-03 14:40, Nils Ohlmeier wrote: > 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.
It is not the proxy who challenges the in-dialog request, it is the attacker (Bob). Even if the proxy is configured not to challenge in-dialog requests, or even if digest authentication is not used at all on the proxy, as long as it forwards the 407 from the attacker, the attack would still be possible. The proxy (in figure 2) is only used to make sure that the 407 generated by Bob makes it to Alice. See figure 2 in the I-D, the 407 is generated by Bob based on the 407 he received from p2.com. And the 407 from p2.com is a response to an out-of-dialog INVITE. So a requirement to make the attack possible is that the user agent responds to challenges generated for 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. Yes, hopefully :-). But what if not? What if you deploy a poorly implemented PSTN gateway which would happily process an in-dialog request with no matching dialog? Of course you can test the gateway before you deploy it if it is under your control. There are other cases where you know nothing about the target UA implementation, such as when the users of your proxy call other users and you have no control over the UA implementation they use. > - I never unterstood why a proxy should pass through the authentication > request from a foreign domain. Because this is how it is specified in section 22.3 of RFC3261. > In which scenario do I have credentials for > two different domains, but the traffic including authentication is passed > through only one of them? One such scenario is that you have a UA configured with credentials for two different ITSPs and the UA uses another proxy server as the outbound proxy for both of them. This outbound proxy could be your corporate proxy sitting on a firewall, NAT conditioning proxy, SBC, etc.. Jan. _______________________________________________ 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
