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
