Hadriel, > -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: 19 November 2008 20:40 > To: Elwell, John; IETF SIP List > Subject: RE: Another possible limitation of DERIVE > > At the end of the day it's just a form of return-routability > test, subject to the same middle-box trust issues we already > know and love. Not that there's anything wrong with that, > just that I don't think they're claiming it does anything > more than that. > > With regards to your specific scenario, you said with 4474 if > sp.net did NOT interfere with the From-uri then you can > verify where the call really came from. (example.com) But if > sp.net did not interfere with the From-uri, then Derive will > also route to example.com. [JRE] Yes, but how does the callee UA know whether this has happened or not? How does it know who is making the assertion (in the OPTIONS response) that it has indeed sent the INVITE request? With RFC 4474, the subject of the certificate provides this information.
John > > 4474 does not and cannot prevent sp.net from changing the > From-uri to sp.net - it can only prevent sp.net from changing > it to example.com, or foobar.com. If sp.net changed it to > foobar.com, Derive could catch that in some cases, but > obviously if the Derive message just happened to go through > sp.net then sp.net can successfully lie and make the Derive > check succeed. Whereas 4474 would catch the lie no matter what. > > BTW, I think it still is subject to the Baiting attack. I > make a Bank call me, and I then re-use its call-id+tag in an > INVITE I send to you. Since it's the same call-id and tag, > Bank will say "yes I'm making that call". > > But I assume the purpose for Derive is not to try to prevent > all kinds of middle-man/middle-box attacks, but rather > prevent spray-spamming and some basic identity fraud > scenarios in a better-than-nothing approach. No? > > -hadriel > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > > Elwell, John > > Sent: Wednesday, November 19, 2008 11:15 AM > > To: IETF SIP List > > Subject: [Sip] Another possible limitation of DERIVE > > > > Suppose, for the sake of argument, we go with Hadriel's draft and > > OPTIONS, e.g., global call ID in INVITE request, sent back > in OPTIONS > > request with global call ID to URI obtained from receive From. > > > > Now suppose the initial From URI is > sip:[EMAIL PROTECTED];user=phone > > and this gets modified by callee's service provider to > > sip:[EMAIL PROTECTED];user=phone. Callee UA sends OPTIONS > request to the > > latter URI. B2BUA in sp.net acts as UAS for the OPTIONS request and > > returns 200 OK, on basis that it recognises the global call ID. What > > does this give me? Basically that the call arrived via my service > > provider, which I know anyway if it arrives over a TLS > connection for > > which I have authenticated the service provider. The > problem is, I don't > > know that sp.net has terminated the OPTIONS request. Even > if the service > > provider has not acted in this way and the OPTIONS request > has gone all > > the way back to the caller UA (or at least to its domain > proxy/B2BUA), I > > have no evidence that this is so. > > > > Now contrast this with RFC 4474. With RFC 4474, sp.net can > change the > > URI as above and re-sign (insert a new Identity header > field). At least > > my UA can see that the only guarantee I have is that the > call arrived > > via sp.net. On the other hand, if sp.net has not intervened > in this way > > I can see where the call has really come from (subject to B2BUAs not > > breaking the signature). In other words, RFC 4474 tells me who is > > asserting that it sent the INVITE request, whereas DERIVE > just tells me > > that someone is asserting that it sent the INVITE request. > > > > John > > > > _______________________________________________ > > 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
