Re: Another possible limitation of DERIVE

Hi John

actually I think this concern has been indirectly articulated -- IMO,
it falls in the better-than-nothing category: any man-in-the-middle
including those who are legitimately in the path (sitting on DNS servers,
sitting  on proxy servers) can provide misleading assertions.

A "honest B2BUA" should here IMO really not answer with 200 until it
propagated the DERIVE test to the other side, unless it has the
knowledge of DERIVE test. (say by having it completed on its own)

The key point is however, that we just can't neither prevent nor
detect man-in-the-middle misconduct with better-than-nothing security.
If a B2BUA decides to play dishonestly (in addition to "mechanical"
side-effects such as destroyed callid, which we may possible fix),
we can neither prevent  nor detect it with better-than-nothing
security.

Which I think turns us to the DERIVE question: are we interested
in better than nothing security?

-jiri

Elwell, John wrote:
> 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 attempt to make your point a bit "compressed" -- the concern is that
someone along the path is answering on the end party behalf, right?

In which case the answers above would relate: with better-than-nothing
security we really neither can detect nor prevent MitM providing
misleading answers. IF a B2BUA decides to lie, pretend, answer without
knowing, etc., we can't do anything about it. IF a domain (as identified
by its DNS name) decides to deploy such a vehicle, it is its choice.
(probably not best for its reputation)

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

A way to see it is in both cases the DNS domain owners are the verification
instance, that  provide some assertions using the vehicles they have.
With  4474 you additionally know that the DNS domain owner is really him
on the grounds of the trust relationship you established with a CA. Both
mechanisms can provide  you with misleading assertions about the URI
(username can be lied-unverified-whatever, or the whole From could have
been completely different before signing). IMO the added value 4474 
gives you
is a trusted  party assertion that you are blaming the right DNS owner 
for not
playing fair about From HF.

-jiri

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