Re: Another possible limitation of DERIVE

> -----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