> -----Original Message----- > From: Jan Janak [mailto:[email protected]] > Sent: Saturday, March 07, 2009 2:51 PM > > I am not sure I understand how accepting/not-accepting INVITEs from > non-registered contacts makes it different, could you elaborate?
Assume Bob is bad, Alice is the victim. The setup for the attack is such that Bob sends an INVITE to/through Alice's domain, pretending to be Alice. Alice's domain challenges the INVITE, which Bob passes on to Alice, and using her challenge-response Bob challenge-responds to Alice's domain. Right? I am arguing that in common practice (in my particular market space, anyway), Alice's domain wouldn't accept Bob's spoofed INVITE to begin with. Because it requires Bob's UA to actually be Registered as Alice in order to send in an INVITE pretending to be Alice. Since REGISTER requests are challenged, and the digest-challenge mechanism includes the Method name in the calculation, Bob can't try to REGISTER into Alice's domain and use a challenge-response from her INVITE to do so. Ergo, no problem. Even for cases where they accept INVITE's from non-registering UA's (e.g, big IP-PBX SIP Trunks), my particular customer types often restrict what AoR can be claimed or allowed to make calls in from that trunk. On the peering side, it's a different story - but the model they currently employ is a chain-of-trust, so they trust the peer to authenticate and control things in a similar fashion. Whether that's a good idea or not is a different story, but that's the current model. There are protection mechanisms available to prevent or at least mitigate this particular issue for peering, but I have less confidence that people use them in practice. > I don't want to put words in Raphael's mouth, but he probably mentioned > publicly reachable SIP providers because they typically place no > restrictions > on incoming calls for their users and thus this kind of attack can be > easily > tried with them. Not in my experience. They place *many* restrictions on incoming calls. But then those are my customers, which are just a subset, and obviously my view is undoubtedly myopic because those are the types of providers that would be talking to me to begin with. And again, whether they actually use the tools at hand I don't know. -hadriel _______________________________________________ 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
