> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Elwell, John > Sent: Wednesday, November 19, 2008 10: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.
Agreed. I brought this up earlier in the week in http://www.ietf.org/mail-archive/web/sip/current/msg25640.html, when I wrote: # If we had a way to determine who 'owns' an E.164, we # could make that owner prove they received the DERIVE # query (by asking them to encrypt something with their # private key), which prevents a PSTN gateway from lying. (substitute 'PSTN gateway' with 'B2BUA'.) # This is something that could be bolted on later, # if/when we figure out how to map an E.164 to # certificate that 'owns' it. and this is why draft-wing-sip-identity-media (expired) signs the originating information (as does Kai's draft). Both would receive additional benefit from the ability to associate an E.164 to a certificate. -d > 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
