Subject: [Sip] Another possible limitation of DERIVE

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 Nov 2008 16:14:46 +0000

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-masked];user=phone
and this gets modified by callee's service provider to
sip:[email-masked];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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Nov 2008 14:35:25 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Elwell, John
> Sent: Wednesday, November 19, 2008 10:15 AM
> To: IETF SIP List
> Subject: [Sip] Another possible limitation of DERIVE
> 
> 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Nov 2008 15:39:54 -0500

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.

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Elwell, John
> Sent: Wednesday, November 19, 2008 11:15 AM
> To: IETF SIP List

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Wed, 19 Nov 2008 22:58:45 +0100

> 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 "ye…

In the current spec, all subscriptions should be authorized before
approval and a caller (Bank) should accept subscribe requests only
from URIs to which it has sent an INVITE-request (Hadriel).
-- 
Victor Pascual Ávila
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 Nov 2008 23:49:10 +0000

Hadriel, 

> From: Hadriel Kaplan [mailto:[email-masked]] 
> 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
> 
> Behalf Of

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 20 Nov 2008 15:28:24 +0100

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:
> via sp.net. 
> On the other hand, if sp.net has not intervened in this way
> 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

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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 21 Nov 2008 13:16:48 +0000

Jiri,

Well, you could argue that P-Asserted-Identity is btn security - you
simply have to trust the chain of SIP intermediaries without having
visibility of who exactly is in that chain. I am not convinced that
DERIVE, either in its current documented form or taking into account the
many helpful suggestions during the last couple of weeks, can really
claim to add very much.

The fact that the mechanism can yield a significant number of "false
positives" (or perhaps "false negatives" is the right term) means the
mechanism, as it stands, fails to provide a safe means by which I can
decline or ignore calls I don't want, or send them to voicemail if I
don't want them right now. I think this limits its applicability.

One particularly appealing aspect of DERIVE as documented is that it
tries to avoid special behaviour at the calling side, as noted during
the meeting. So I would still appreciate any further ideas that have
this same property.

I appreciate your efforts on this and, believe me, I really want to
explore all possible ideas for solving this identity problem. So don't
let the absence of success with this discourage you from submitting
other ideas.

John

> From: Jiri Kuthan [mailto:[email-masked]] 
> Sent: 20 November 2008 14:28
> To: Elwell, John
> Cc: IETF SIP List
> Subject: Re: [Sip] Another possible limitation of DERIVE
> 
> Hi John
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Nov 2008 09:55:50 -0600

> many helpful suggestions during the last couple of weeks, can really

So here's a scenario to play against. It's not exactly in the scope of  
DERIVE, although one might see DERIVE as a defense.

I crate a CA cert claiming to be for "elwell.org" and use it to sign a  
cert for "sip.elwell.org".

I then generate INVITE requests for everybody on the SIP mailing list,  
with RFC 4474 Identity headers signed by "sip.elwell.org" and send  
them off UDP. Not from a real SIP UP, but from a simple harassment  
program.

How many phones ring straight away? How many other people are going to  
look at the cert, presume you are a reasonable guy to be getting  a  
signed request from and accept the call?

How do existing identity mechanisms protect against this? What other  
mechanisms might be operationally used to check it?

Remember, with BTN security, we're talking "things that keep basic  
script kiddies from being annoying", not "things that defeat somebody  
who can cache-poison DNS" (although there may be some script-kiddies  
doing that these days).

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Nov 2008 11:04:01 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Friday, November 21, 2008 10:56 AM
>
> How do existing identity mechanisms protect against this?

The answer to that is simple: will you pay for the calls?

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Nov 2008 10:06:43 -0600

> The answer to that is simple: will you pay for the calls?

Pay? I have yet to pay (beyond the basic transport cost) for a SIP  
call using a domain-style address.

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 21 Nov 2008 09:04:53 -0800

John,

>So don'tlet the absence of success with this discourage you from submitting
>other ideas.

I beg to differ. In an Internet environment or in SIP VoIP networks that have little PSTN heritage constraints and/or long chains of interemediaries, Derive is very useful. I would suggest therefore Derive to be published as an informational RFC and to state in what type of networks it is most effective.

Thanks, Henry

On 11/21/08 5:16 AM, "Elwell, John" <[email-masked]> wrote:

Jiri,

John