Subject: [Sip] scope of derive

From: Jiri Kuthan <[email-masked]>
Date: Fri, 21 Nov 2008 00:52:34 +0100

I'm just wondering, if folks could help to explain me this:
apparently when I asked if people in the WG feel safe about
IETF's mechanisms deployable to prevent spoofed From, nobody
spoke up. At the same time, there were some who felt that
we don't have a problem statement. I would be thankful if
representatives of the latter group could share with me
what is the missing piece here to state a problem.

Thank you very much indeed,

-jiri

p.s. the other aspects such as B2BUA traversal is IMO very
orthogonal and is to be ellaborated on in a seprate document.

_______________________________________________
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: Fri, 05 Dec 2008 11:34:20 +0000

Jiri,

It is well-known that I am not comfortable that we have a **deployable**
solution for preventing From URI spoofing. The reason it is not
deployable is because of B2BUAs, and to some extent because of
E.164-based URIs and the way they are handled in practice. Furthermore
there are issues with PSTN interworking, but we can't do much about
that. 

I have tried to articulate these issues by means of several I-Ds over
the last year or so, but capturing a "problem statement" acceptable to
all seems to be an elusive goal.

The reason seems to be that if I describe the problem in a certain way
(e.g., B2BUAs break the RFC 4474 signature), people say "but we can get
round this by doing A", so the problem statement has to be extended to
say why A doesn't work, and then people say "but you can get round it by
doing B", so the problem statement has to be further extended to say why
B will not work, and so on ad infinitum.

So I would welcome any other attempts to write the problem statement.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jiri Kuthan
> Sent: 20 November 2008 23:53
> To: [email-masked]; Cullen Jennings
> Subject: [Sip] scope of derive
>

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Fri, 5 Dec 2008 14:47:04 +0100

> So I would welcome any other attempts to write the problem statement.

The whole identity problem cannot be solved in one shot.
IMO the scope of DERIVE is very limited, which I consider to be a good
thing if we really want to have a deployable solution.

Starting from the very beginning, I'm wondering if folks agree that:
- From URI spoofing is a problem
- Existing mechanisms present some shortcomings (see
draft-elwell-sip-e2e-identity-important)
- An "as much end-to-end as possible" solution is desired
- This solution is desired to be *simple and deployable*
- In the absence of some sort of authentication mechanism, URI
verification is "better-than-nothing"
- A "better-than-nothing" approach to URI verification may provide the
desired level of simplicity and deployability.
- The used mechanism should work on a per-session basis. This might be
done by using any unique session-identifier/token shared between the
calling and the called parties.

I'd like to hear your opinions on this.

Cheers,
-- 
Victor Pascual Ávila

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 05 Dec 2008 16:39:47 +0000

Viktor, 

> From: Victor Pascual Ávila [mailto:[email-masked]] 
> Sent: 05 December 2008 13:47
> To: Elwell, John
> Cc: Jiri Kuthan; [email-masked]; Cullen Jennings
> Subject: Re: [Sip] scope of derive
> 
[JRE] Jiri asked about problem statement, not solution.

> desired level of simplicity and deployability.
[JRE] The word "may" is important here. Until we find an approach that is viable (and I don't think we are quite there yet with DERIVE), it is difficult to tell whether a better-than-nothing approach would be worthwhile.

John

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 5 Dec 2008 08:48:26 -0800

John,

>it is difficult to tell whether a better-than-nothing approach would be worthwhile.

Is this not for the market to decide?
(Who are we?)

Henry

On 12/5/08 8:39 AM, "Elwell, John" <[email-masked]> wrote:

Viktor,

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 05 Dec 2008 17:10:15 +0000

Henry,

Of course, as with any specs we produce, but until the spec is written (not necessarily as an RFC) vendors can't implement it and the market can't therefore decide. All we can do in the IETF is assess whether we think it worthwhile to devote resources to writing an RFC.

John

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: 05 December 2008 16:48
> To: Elwell, John; Victor Pascual Ávila
> Cc: [email-masked]; Cullen Jennings
> [JRE] The word "may" is important here. Until we find an 
> approach that is viable (and I don't think we are quite there 
> yet with DERIVE), it is difficult to tell whether a 
> better-than-nothing approach would be worthwhile.
> 
> John
> 
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 Dec 2008 11:22:22 -0600

> what is the missing piece here to state a problem.

So let's define a "spoofed From."

Are we talking about a real UA generating an INVITE request with a  
bogus identity asserted in it's From: field, or are we talking about a  
DOS attack (like a voice-hammer generator) where a device that is not  
a UA is generating an INVITE request that causes the UAS to deliver  
the attack to the victim?

For the first threat, in our current spec family, we have strong  
identity (aka RFC 4474) as a general solution, and weak identity (RFC  
3325) as a point solution for single-domains or federations with  
identity enforcement points in trusted proxies.

For the second threat, we have null-authentication; the UAS can  
challenge the request (which tests direct return routability to the  
UAC) and wait for a response before proceeding to the alerting phase.  
By direct return routability, I mean that we can follow the via-stack  
back to the originating UAS (possibly with help for a via-pruning SBC).

So where does DERIVE fit in?

I believe it attempts to address both problems. It's clearly heavier  
than the existing solution for the second threat, but if we use  
DERIVE, we get this problem fixed for free. So the question of the  
work really seems to be its applicability to the first threat.

Let us move to an examination of the assumptions. DERIVE assumes that  
the identity expressed in the request being examined is a routable  
identity, and that there is a indirect return routability for that  
identity. By indirect return routability, I mean that a new  request  
targeted to that identity will reach the user agent that originated  
the request. Further, DERIVE assumes that the UA reached by the  
indirect return routability path has knowledge of the request being  
examined and that it can attest to that knowledge, thereby  
establishing the veracity of the identity expressed in the request to  
the level of "this identity resolves in the routing topology to the  
node that sent the request".

Therein lies the differentiator: Whereas RFC 4474 proves the identity  
cryptographically (that is, through secrets known to the identity- 
holder or to a trusted third party working on behalf of the identity- 
holder), DERIVE proves it functionally (by the definition of  
"functionally" meaning "it works", sorry you Haskell fans!).

Two questions remain:

1) Is a functional verification through indirect return routability  
testing of the identity expressed in a request actually useful?

2) Is the mechanism used by DERIVE reasonable for implementing an  
indirect return routability check?

Let's attack these one at a time.

Question 1: Usefulness of indirect request return-routability checks  
in SIP

Many attacks seen in the Internet rely on forged transmission  
identifiers. For example, consider the once wildly popular Smurf attack:

	 http://en.wikipedia.org/wiki/Smurf_attack

The Smurf attack uses a ICMP echo request with a forged IPsource  
address, where the victim's address is used as its source address  
(i.e, it's "From:"). This initial request is addressed to the  
broadcast address of a remote subnet. If the attack succeeds, each  
host on the remote subnet replies, thereby flooding the victim with  
unexpected ICMP echo request responses.

Although we have not identified a Smurf-like direct amplification  
attack in SIP, it's still obviously possible to use a forged From: to  
cause the victim's phone to ring, thereby making the target UA an  
attack amplifier against the person (or sanity) of the end user. One  
might call this the "ring ring ditch" or "ring ring ginger" attack,  
from the similar childish doorbell prank"

	http://en.wikipedia.org/wiki/Knock_down_ginger

DERIVE clearly reduces the opportunity to use a forged From: to bypass  
controls on the victim's phone. Not perfect, but it passes the script- 
kiddie test.

Consider however the SIP Voice Hammer attack:

	http://tools.ietf.org/id/draft-ietf-mmusic-ice-19.txt, section 18.15.1

This works similarly to Smurf, but it uses a second level of  
indirection. Rather than spoofing the victim's From: address, Voice  
Hammer insert's the victim;s address into the SDP of a SIP INVITE.  
When the target of the request "answers" the call, the target becomes  
an amplifier, spewing RTP packets at the victim.

Indirect return routability testing gives us no direct defense here,  
in that provides some validation of the from: address but we have no  
way of correlating this address with the one used in the SDP. However,  
it does make it harder to originate the attack anonymously, as it  
requires that the attacker establish indirect return routability at  
the SIP level, which presumably gives us a little better chance of  
hunting the perpetrator down and apply other mechanisms (such as  
summary execution) in order to prevent further offenses.

In other words, it's good enough to stop script kiddies.

In a third attack scenario, presume the attacker's goal is to  
impersonate a caller, such as the infamous "Radio-Show Sarkozy/Palin"  
calls.
	
	http://www.huffingtonpost.com/2008/11/01/masked-avengers-prank-cal_n_140023.html

Here the goal is not necessarily to prevent the call, but to give the  
called party some level of comfort as to the authenticity of the  
caller's expression of identity.

Indirect return routability checks clearly establish that the calling  
party is sufficiently in-control of the expressed identity as to be  
able to receive calls directed toward that identity. This is better  
than nothing; it can't prove identity, but it greatly decreases the  
probability of a random radio DJ being able to make a prank call.

Question 2: Does DERIVE provide a reasonable solution?

In order to impact the DoS attacks described in 1, the solution has to  
be "strong enough" that we can reasonably reject a call, at the  
automata level, without bothering the user. No arguments have been  
made that the mechanism in DERIVE is sufficiently widely deployed that  
one can reject calls not using it. One might argue that one could add  
an extension detection mechanism (such as including a modifier in the  
identity) that says "You can expect calls from me to support DERIVE;  
if they don't, it isn't me" that might help. But it's still a pretty  
weak defense against DoS. In the general case, DERIVE does NOT stop  
script kiddies from known DoS attacks, so it may not be useful here.

Consider however the "Radio-Show Sarkozy/Palin" calls; here the  
requirement is not to block the call entirely, but to give additional  
guidance to the user as to how to evaluate the caller's claimed  
identity. Here DERIVE might be useful. It's more use if we have a  
reason to believe that calls from a given party should support DERIVE.  
In the end, it comes down to breadth of availability. Will DERIVE be  
widespread enough that anybody bothers with it? My hunch is that this  
is unlikely, but this might be a useful point of discussion.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Dec 2008 14:50:32 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Elwell, John
> Sent: Friday, December 05, 2008 12:10 PM
>
> Of course, as with any specs we produce, but until the spec is written
> (not necessarily as an RFC) vendors can't implement it and the market
> can't therefore decide. All we can do in the IETF is assess whether we
> think it worthwhile to devote resources to writing an RFC.

Yes exactly.  The great thing about a DERIVE concept, or Dan's return-routability draft, is it doesn't require an RFC at all really.  There is no interoperability issue to be solved, and no changes to SIP, AFAICT.  No?
But if they want it to be a WG item then it has to argue its case just as all the others do.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Dec 2008 16:27:40 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Friday, December 05, 2008 12:22 PM
>

Actually, I would debate that.  Derive and other return-routability checks have the property of: "if I pass then you know I'm good, if I fail then you know nothing (neither good nor bad)".   I would argue such a property is only useful in voice communications if it passes and provides a positive/"good" result *frequently*.

For example, if the odds of Derive passing is low in general, then Palin would have had to assume it *was* Sarkozy even if it failed.  Why?  Because she assumes it now, with no such checking, and the odds of this thing passing are low per the supposition.

Therefore, if we feel the odds of a return-routability check succeeding is low in general, it is NOT the case that: "it greatly decreases the probability of a random radio DJ being able to make a prank call."

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Dec 2008 17:10:45 -0500

> [snip]

Ummmm... no it doesn't.  It stops me from attacking the intended target's phone *directly*, but not as a smurf-style attack.  I simply set my From: to the *target's* URI, then send that INVITE to every number I can.  Thus I get other devices to flood the target with SUBSCRIBEs.  It's not as annoying as ringing the target's phone, for sure, but it's still an attack.  And unlike SMURF or hammer attack, it only requires me to know the target's AoR, not its IP or MAC.  And unlike a direct INVITE attack, I don't even need authorization or a path to reach the intended target; I only need to be able to reach a lot of Derive-capable UA's and hope some of them can reach the intended target.

-hadriel

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 05 Dec 2008 23:16:06 +0000

Excellent analysis of the context and applicability of DERIVE, Dean.  In
it, you wrote:

> [...] DERIVE assumes that  

There are two issues with these assumptions that I think are worth one
further level of analysis:

A From Address will often fail to reach the caller if used as a request
target.

        For DERIVE to work the "indirect return routability" test needs
        to reach the specific UA that originated the call whose
        authenticity is being checked.  In environments with any kind of
        gateway, this will often not be the case.  If I'm calling from a
        non-SIP environment into SIP, even if that translation
        accurately preserves my identity as a From address (for example,
        my PSTN carrier provides a valid caller-id which then is
        accurately translated to a From header), that address is often
        not going to have the property that it is sure to route back to
        the very same gateway that the INVITE came from.  What's more,
        there's no other reason why it should - an AOR is an identifier,
        not a route description.
        
SUBSCRIBE is not INVITE

        It is by no means assured that a SUBSCRIBE request will be
        routed to the same set of UAs that an INVITE would be.  In
        particular, a SUBSCRIBE coming from outside the callers domain
        may often be subject to policy based routing or rejected without
        ever reaching the UA of even a legitimate caller.

These factors are the ones that I was referring to in the Minneapolis
meeting when I said that a DERIVE-based test would have a high
false-alarm rate - that is, that the indirect return routability test
would fail even for a legitimate caller with a legitimate From address.
I believe this rate would be so high that it would certainly be unsuited
to any automated filtering - the best it could do would be to offer a
user-interface indication of failure at call presentation time.  Even in
that case, it would indicate an unverified caller so often that the
callee would be unwise to make any firm judgment based on it, so the
callee is in exactly the position they are in today - the From address
is a hint.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Dec 2008 18:29:27 -0500

> Scott Lawrence
> Sent: Friday, December 05, 2008 6:16 PM
>

Right - this was the same issue people had with Dan's return-routability test.

>         ever reaching the UA of even a legitimate caller.

Correct - this was noted in an earlier email on this topic a few weeks ago as well.
It's actually worse than that, BTW.  We've already noted that the UAC would in fact have to support the dialog-event package; as would every b2bua in the middle that changed a call-id, and you'd have to hit all those same b2bua's.
These all reduce the probability of a positive check result. (for some of us fairly drastically)

> Even in

Exactly - that was my point about the Palin/Sarkozy problem not really being resolved.

-hadriel

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 06 Dec 2008 08:49:25 +0100

Scott Lawrence wrote:
> false-alarm rate 

I agree but I don't think that's the point. Remember that DERIVE is 
about the
positive test, the negative tests are worthless. In other words this is 
about
the migration path and not about the starting point (every single 
extension takes
some new lines of  code, without which there is 0% deployment). 
Importantly, while
DERIVE grows, the worthless share declines and reinforces the value of 
the positive
share.

> - that is, that the indirect return routability test

The point is the *positive* case.
I bet I can name you 10 reasons why the negative case can occur but I'm not
interested the negative case. (it is not "false positive", it is
worthless zero-bit-long piece of information).

> callee is in exactly the position they are in today - the From address

Why are you exactly interested in studying the negative case when it is
obviously without value?

-jiri

---

From: Dean Willis <[email-masked]>
Date: Sat, 6 Dec 2008 12:06:53 -0600

On Dec 5, 2008, at 3:27 PM, Hadriel Kaplan wrote:

> Actually, I would debate that.  Derive and other return-routability  
> checks have the property of: "if I pass then you know I'm good, if I  
> fail then you know nothing (neither good nor bad)".   I would argue  
> such a property is only useful in voice communications if it passes  
> and provides a positive/"good" result *frequently*.

Well, if you had previously told me that you should always pass RRC  
and then fail, I might assume the caller isn't you.

>
>
> For example, if the odds of Derive passing is low in general, then  
> Palin would have had to assume it *was* Sarkozy even if it failed.   
> Why?  Because she assumes it now, with no such checking, and the  
> odds of this thing passing are low per the supposition.
>
> Therefore, if we feel the odds of a return-routability check  
> succeeding is low in general, it is NOT the case that: "it greatly  
> decreases the probability of a random radio DJ being able to make a  
> prank call."

But in general, you're confounding the second part of my analysis with  
the first, so keep reading . . .

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 08 Dec 2008 14:08:27 +0000

Jiri, 

> Sent: 06 December 2008 07:49
> To: Scott Lawrence
> Cc: [email-masked]
[JRE] The number of negatives will diminish, true, but it will never
approach zero, because there will always be negative cases arising from
forking, call forwarding, problematic B2BUAs, etc.. So it is a question
whether it will get sufficiently close to zero that the odd false
negative can safely be ignored. I am rather doubtful.

John

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Dec 2008 15:49:09 +0100

Elwell, John wrote:
> forking, call forwarding, problematic B2BUAs, etc.. 

indeed.

> So it is a question

The question remains: why would like to worry about the negative case
when we know it has zero information value?? I cannot conceive anyone
would like to use such non-information and I don't see the point in
studying it then.

-jiri

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 08 Dec 2008 08:37:08 -0800

At Fri, 21 Nov 2008 00:52:34 +0100,
> what is the missing piece here to state a problem.

You could start with a threat model and a set of constraints.

-Ekr

---

From: "Scott Lawrence" <[email-masked]>
Date: Mon, 08 Dec 2008 16:55:11 +0000

> would like to use such non-information and I don't see the point in

I'll turn that question around: what do you think this really achieves
for the ordinary non-technical phone user?

      * Sometimes the phone has an indicator that the caller-id has been
        verified.

      * Sometimes the phone fails to have that indicator, but
        regardless, the caller-id may be correct.

I believe that the false-negatives in the latter greatly diminish the
value of the former, because you still have to answer the phone to find
out if it is who it claims to be.

Further - what part of a caller-id does a phone display?  Given:

	From: "Scott Lawrence" <[email-masked]>

what do you suppose a phone will display?  For most phones I use today,
it will either be "Scott Lawrence" or "scott", and in any event most
won't have enough characters for a long address.  These display
limitations and ambiguities mean that an attacker can trivially create a
return-routable address that will very likely be displayed in the same
way as some other address, so even the positive case can be spoofed as
far as the human user is concerned.

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Dec 2008 18:10:41 +0100

> [JRE] The word "may" is important here. Until we find an approach that is viable (and I don't think we are quite there yet with DERIVE), it is difficult to tell whether a better-than-nothing approa…

I think DERIVE is a viable approach for spoofing protection and I 
haven't found
a convincing argument that would counter that really. (abstracting now from
the dialog package).  In fact, DERIVE is MORE viable than anything else 
which
has been discussed. RFC4474 has turned out not to be viable, and neither did
From, P-Asserted-Identity or other possible "just-nothing" approach. To 
provide
arguments: we know that RFC4474 has not been deployed. We thus do not have
running code and cannot rely on it. sipit reports show two implementations,
one of them is ours in SER, which to my best knowledge has not found
a deployment. I guess that's because reliance on CAs and excessive message
integrity. (who in the world does NOT rewrite SDP???) Security of 
plain-text
From/PAI hopefuly requires no discussion.

I understand you have been worried about B2BUA. That's a legitimate concern,
but let's face it...fixing applications is fixing consequences and not the
problem. Today it is DERIVE, yesterday it was REFER and tommorrow it is 
going
to be FOOBAR -- fixing the apps doesn't help. Fixing the root of the problem
is fixing the B2BUA, such as by making them more deterministic. Hadriel's
draft about sesssion id is IMO a real specific step torwards that.

Well -- we may have a way for doing reverse-routability checks which is 
simpler.
DERIVE a la SPF would avoid all of this SIP pain, however at the loss of 
per-dialog
granularity. The "resolution" would then degrade to administrative 
domain-name
ownership as opposed to "dialog ownership". In fact, we have recently 
deployed
SPF for our domain and instantly observed a dramatic increase in number 
of faked
emails that have been dropped.

To me that would be a reasonable answer to dealing with all of the SIP 
complexity
(and B2BUA, and SBC, and what-have-you). One could even guess that the share
of positive cases would be initially higher -- it takes only reliance on
configuration of sender's DNS (as opposed to updating B2BUA).

---

From: Dean Willis <[email-masked]>
Date: Mon, 8 Dec 2008 11:15:05 -0600

> would like to use such non-information and I don't see the point in

How would DERIVE change the behavior of the user in the positive case?  
How would DERIVE change the behavior of the user in the negative case?

--
Dean

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 8 Dec 2008 09:15:38 -0800

>for the ordinary non-technical phone user?

Voice enabled chat rooms (such as iChat, Jabber, etc.), social networks, blogs, media web sites and web based customer support are emerging communications where DERIVE will just work fine. Note the potential that DERIVE can be basically protocol independent, though I hope it will first be used by SIP.

Judging DERIVE only from the perspective of 'legacy' VoIP telephony is just not right and makes me wonder about the direction of this discussion.

My two cents,

Henry

On 12/8/08 8:55 AM, "Scott Lawrence" <[email-masked]> wrote:

---

From: Dean Willis <[email-masked]>
Date: Mon, 8 Dec 2008 11:22:42 -0600

On Dec 8, 2008, at 11:10 AM, Jiri Kuthan wrote:
> a convincing argument that would counter that really.

We agree that a negative-DERIVE test means nothing. Therefore, DERIVE  
provides no spoofing protection.

What it does do is potentially provide some assurance of non-spoofing.  
That's a very different thing.

In short, the default condition for an astute user should be "The  
caller ID may or may not be valid". With negative-DERIVE, this doesn't  
change.

With positive-DERIVE, the user should think "This caller-ID works for  
a return routability check. It is more likely to be valid than if I  
didn't have this test, but it might still be faked by a clever badguy".

Otherwise said: Unknown, Claims-to-be, and Can-be-reached-now-at are  
the three possible states produced by DERIVE.

Now, how astute do you think your hypothetical grandmother is likely  
to be?

At the best, we can get three states to such a user: no ID, not  
trusted, and trusted to relatively high level. Those aren't the same  
three states that come out of DERIVE. So is it useful to your  
grandmother, or just confusing?

--
Dean

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Dec 2008 18:32:28 +0100

>         regardless, the caller-id may be correct.

The draft does not debate policies, it debates reverse-verification and 
that's
really the way the IETF protocols have been built. What you are 
suggesting is
a good example but I believe the policies are likely to be more complex. 
I think
of scoring, like with Email, that tries to create a balance among all of the
pieces of information that's known about a call. DERIVE is one such. The 
positive
DERIVE test increases the score to somewhere close to 100%, the negative 
test does
not make it any worse.

> out if it is who it claims to be.

I don't think you have to. Most modern telephones give you a choice of how
you deal with different sorts of calls. I frequently turn on "allow trusted
numbers only" and the rest goes to voicemail. In the default mode for less
busy situations, I choose only strange (anonymous and blacklisted) calls
to go there.

The point is really we cannot devise the policies for the users, but we 
owe them
tools upon which they will be able to build up their policies. "trusted 
numbers
only" is a useful mode, but not entirely if it is too easy to take 
someone else's
 From URI.

> far as the human user is concerned.

Even then DERIVE is going to be very useful.

Let's consider terminal adapters for a while as these devices really cannot
display much information. (for native SIP phones I would recommend 
purchasing
ones with large displays and proper information displayed on it).

If annoying "[email-masked]" calls a DERIVE callee, and 
DERIVE
test is succesful, the DERIVE callee can safely put the caller on a 
blacklist.
(e.g., by pressing ###) When next call from the same caller comes, it goes
directly to voicemail.

The real point is: DERIVE increases trust but does not define policies.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Dec 2008 18:43:53 +0100

Dean Willis wrote:
> We agree that a negative-DERIVE test means nothing. 

Yes.

> Therefore, DERIVE 
> In short, the default condition for an astute user should be "The caller 
> ID may or may not be valid". With negative-DERIVE, this doesn't change.
> 
> With positive-DERIVE, the user should think "This caller-ID works for a 
> return routability check. It is more likely to be valid than if I didn't 
> have this test, but it might still be faked by a clever badguy".

Yes.

I think the closest match in the history is SPF with largely the same
properties. It can't guarantee incoming traffic is evil (someone just
doesn't advertise SPF for his domain, or uses "mobile MTAs"), it can't
guarantee anything if there are clever badguys (who do DNS attacks too),
and still it effectively helps to reduce traffic with spoofed From.
In fact, after we have deployed SPF for our domain, we have seen a dramatic
increase of spoofed-From-emails with our domain name, that were declined.

> 
> 
> Otherwise said: Unknown, Claims-to-be, and Can-be-reached-now-at are the 
> three possible states produced by DERIVE.
> 
> Now, how astute do you think your hypothetical grandmother is likely to be?
> 
> At the best, we can get three states to such a user: no ID, not trusted, 
> and trusted to relatively high level. Those aren't the same three states 
> that come out of DERIVE. So is it useful to your grandmother, or just 
> confusing?

I think this is a user-interface/policy thing. On my cell phone I typically
have two profiles, in one of them the phone rings for whitelisted callers,
in the other for all but blacklisted/anonymous callers.

-jiri

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Dec 2008 13:42:33 -0500

> Henry Sinnreich
> Voice enabled chat rooms (such as iChat, Jabber, etc.), social networks,
> blogs, media web sites and web based customer support are emerging
> communications where DERIVE will just work fine. Note the potential that
> DERIVE can be basically protocol independent, though I hope it will first
> be used by SIP.

I'm confused by that comment.  Are we talking about the same DERIVE draft?
Doesn't it depend on SIP dialog identifiers to check anything?

If you're abstracting DERIVE as a higher level concept than SIP, as a "check this guy is who he claims to be", then this isn't some new concept.  It's been done for years.  For example in online form filling out, when the web server sends an email to the claimed address, with a URL link in the email (with an embedded cookie) that once clicked tells the server that the form is being filled out by someone at that address.  Or what some humans do when their credit card company calls them, and they say "I'll call you back at the number on the card".  Or what SPF or uRPF do, in a passive way.

-hadriel

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Dec 2008 20:22:04 +0100

> How would DERIVE change the behavior of the user in the positive case? 

That's a policy thing. Perhaps (as an example) increase a call atempt score
beyond a threshold that will prevent the call from falling in voicemail.

> How would DERIVE change the behavior of the user in the negative case?

not at all.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Dec 2008 20:37:15 +0100

> So I would welcome any other attempts to write the problem statement.

Hi John,

I think it is really worth to separate the application problem from B2BUA
problems.

I think the DERIVE "B2BUA traversal" is primarily a B2BUA problem. A 
test for
what's the root is for me "is this guaranteed to work with an RFC3261 proxy
server as used in the field"? For DERIVE, the answer is yes. It is the
B2BUA unpredictability which makes UAs enter thin ice. That can be improved
using suggestions like Hadriel has extended.

The Identity problem is possibly on both sides. It is certainly Identity 
problem,
since any field proxy will rewrite SDP for sake of NAT traversal and 
Identity will
fail. (even if there was a CA in the field). If that was fixed, some extra
effort on the B2BUA would be probably needed as well.

I think we shall make progress on those sides. Certainly on DERIVE and I 
belive
on B2BUA too. At least to the extent we understand their shortcoming, 
and the way
one can address them.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Dec 2008 20:39:33 +0100

> - From URI spoofing is a problem

I would revert this question -- I'm really wondering who on the mailing
list thinks From URI is not a problem and we have good tools to deal with
it. (I also kindly ask those who think so to disclose their SIP address
to me.)

-jiri

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 8 Dec 2008 12:00:48 -0800

Hadriel,

Yes, this is what I meant. Thanks for pointing it out.

Henry

On 12/8/08 10:42 AM, "Hadriel Kaplan" <[email-masked]> wrote:

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Dec 2008 21:25:55 +0100

Dean Willis wrote:
> Are we talking about a real UA generating an INVITE request with a bogus 
> identity asserted in it's From: field, or are we talking about a DOS 
> attack (like a voice-hammer generator) where a device that is not a UA 
> is generating an INVITE request that causes the UAS to deliver the 
> attack to the victim?
> 
> 

I think it belongs in this class, but I don't think we have a practicable
solution -- one is too strong, the other one too weak. (whoever doesn't
wish to indulge in a lengthy debate is invited to share his SIP address
with me -- I'll be happy to demonstrate that)

RFC4474 is simply not there. Despite we=iptel/TKLC have implemented in SER,
we found  ourselves to be rather alone with it. I think the root reason
is it is heavier than it seems. Body integrity protection and dependence 
on CAs
makes it just too impracticable. I would say as a hand waving 
guesstimate 90% of
all SDPs on this  planet gets rewritten for sake of NAT traversal and 
there is 0%
SIP deployments  leaning on a CA.

RFC3325, to the same extent as RFC3261 (From header field), buy really too
little. It is to some extent workable within single-domain, but not even 
that
really reliably. (UAs would have to trust an IP address, but we run into the
questions like "which", or UAs would have to use TLS which appears largely
unused as well).

> challenge the request (which tests direct return routability to the UAC) 
> and wait for a response before proceeding to the alerting phase. By 
> direct return routability, I mean that we can follow the via-stack back 
> to the originating UAS (possibly with help for a via-pruning SBC).
> 
> than the existing solution for the second threat, but if we use DERIVE, 
> we get this problem fixed for free. So the question of the work really 
> seems to be its applicability to the first threat.

Yes.

> targeted to that identity will reach the user agent that originated the 
> request. Further, DERIVE assumes that the UA reached by the indirect 
> return routability path has knowledge of the request being examined and 
> that it can attest to that knowledge, thereby establishing the veracity 
> of the identity expressed in the request to the level of "this identity 
> resolves in the routing topology to the node that sent the request".

Yes.

> cryptographically (that is, through secrets known to the identity-holder 
> or to a trusted third party working on behalf of the identity-holder), 
> DERIVE proves it functionally (by the definition of "functionally" 
> meaning "it works", sorry you Haskell fans!).
> 
> Two questions remain:
> 
> Question 1: Usefulness of indirect request return-routability checks in SIP
> 
> address, where the victim's address is used as its source address (i.e, 
> it's "From:"). This initial request is addressed to the broadcast 
> address of a remote subnet. If the attack succeeds, each host on the 
> remote subnet replies, thereby flooding the victim with unexpected ICMP 
> echo request responses.
> 
> Although we have not identified a Smurf-like direct amplification attack 
> in SIP, it's still obviously possible to use a forged From: to cause the 
> victim's phone to ring, thereby making the target UA an attack amplifier 
> against the person (or sanity) of the end user. One might call this the 
> "ring ring ditch" or "ring ring ginger" attack, from the similar 
> childish doorbell prank"
> 
> controls on the victim's phone. Not perfect, but it passes the 
> script-kiddie test.
> 
> 
> Hammer insert's the victim;s address into the SDP of a SIP INVITE. When 
> the target of the request "answers" the call, the target becomes an 
> amplifier, spewing RTP packets at the victim.
> 
> Indirect return routability testing gives us no direct defense here, in 
> that provides some validation of the from: address but we have no way of 
> correlating this address with the one used in the SDP. However, it does 
> make it harder to originate the attack anonymously, as it requires that 
> the attacker establish indirect return routability at the SIP level, 
> which presumably gives us a little better chance of hunting the 
> perpetrator down and apply other mechanisms (such as summary execution) 
> in order to prevent further offenses.
> 

I think that's about it indeed.
I think what we are seeking is something between zero-security and 
heavy-weight
security. None of these two is really practicable. Like in the web -- we 
have
no plain-text HTTP for online shoping, but the shopper don't really 
prove their
identity protocol-wise either (other than sharing credit card number 
over TLS).
Identity is a hard thing to solve, and it is really not easy to get to one's
DNA. (probably it is good so) Therefore what you called "functional proof"
appears more attractive to me.

> caller's expression of identity.

Right -- the consolation comes in that she can trace the caller if she
accepted a DERIVE-tested call and found it uncomfortable.

> party is sufficiently in-control of the expressed identity as to be able 
> to receive calls directed toward that identity. This is better than 
> nothing; it can't prove identity, but it greatly decreases the 

Yes. Thank you indeed for catching this nuances. I think that addresses
some of the concerns on the mailing list, which were result on somehow
inadequately high expectations on DERIVE. This is what it can and can't
do.

> be "strong enough" that we can reasonably reject a call, at the automata 
> level, without bothering the user. No arguments have been made that the 
> mechanism in DERIVE is sufficiently widely deployed that one can reject 
> calls not using it. One might argue that one could add an extension 
> detection mechanism (such as including a modifier in the identity) that 
> says "You can expect calls from me to support DERIVE; if they don't, it 
> isn't me" that might help. But it's still a pretty weak defense against 
> DoS. In the general case, DERIVE does NOT stop script kiddies from known 
> DoS attacks, so it may not be useful here.

So it is. I think success of DERIVE-like tests depends largely on gaining
the critical mass. For that, the key prerequisite is it must be very simple.

> identity. Here DERIVE might be useful. It's more use if we have a reason 
> to believe that calls from a given party should support DERIVE. In the 
> end, it comes down to breadth of availability. Will DERIVE be widespread 
> enough that anybody bothers with it? My hunch is that this is unlikely, 
> but this might be a useful point of discussion.

honestly, I don't know how its adoption will develop. I would historically
compare it to SPF, which required minimum changes and achieved its function
and current level of deployment by simplicity. a 2007 study shows 5%
penetration for it.
http://www.onlamp.com/pub/a/onlamp/2007/01/11/dns-extensions.html
Introduction of SPF for our own domain has quite increased the rejection
rate.

One of the ideas would be actually to give up the reverse check on SIP level
in exchange for DNS. That would similarly show that the caller (at domain
level) is in control of its name. Less granular, still better-than-nothing.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Dec 2008 21:35:30 +0100

> Actually, I would debate that.  Derive and other return-routability checks have the property of: "if I pass then you know I'm good, if I fail then you know nothing (neither good nor bad)".   I woul…

Well, I don't think really this is specific to DERIVE -- most of 
communication technologies
are useful only if used frequently. (economists call it networking I 
recall). The starting
point is obviously zero, the key challenge is a growth strategy and I 
thinkt the key to it
is simplicity.

> For example, if the odds of Derive passing is low in general, then Palin would have had to assume it *was* Sarkozy even if it failed.  Why?  Because she assumes it now, with no such checking, and t…

DERIVE can't do social engineering. DERIVE only verifies routeability. 
DERIVE helps
her to trust [email-masked] if she knows it is a legitimate address. 
If she accepts
[email-masked] with a positive DERIVE test, and dislikes she 
knows after fact
she can put the URI on a blacklist.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Dec 2008 21:39:25 +0100

> Ummmm... no it doesn't.  It stops me from attacking the intended target's phone *directly*, but not as a smurf-style attack.  I simply set my From: to the *target's* URI, then send that INVITE to e…

This is a question IMO: what does the attacker gain here? IMO a free 
topology hiding feature,
he is not getting an amplification. Couldn't we lower the concerns by 
fingerpointing at the
attacker in the DERIVE tests?

-jiri

---

From: Dean Willis <[email-masked]>
Date: Mon, 8 Dec 2008 15:00:48 -0600

>> How would DERIVE change the behavior of the user in the negative  

Well, the Security area wonks are going to want us to have a threat  
assessment. What is the risk? In what scenarios does it occur? What  
are the consequences?

Given the threat assessment, we then need to understand how the  
solution impacts that threat. What are the possible ranges of policy?  
What is the recommended policy? How does it impact behavior in a  
system that uses this solution?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 8 Dec 2008 15:03:53 -0600

> it. (I also kindly ask those who think so to disclose their SIP  

My Linksys ua-du-jour is usually hooked to a black phone with no  
caller-ID display. So what do I care about From: fields?

If I start getting nuisance rings, I might want to turn on null-auth  
so that I at least have a traceback to a responsible IP address so  
that I can send the lawyer-ninjas after somebody. In this context,  
what does DERIVE give me that a null-auth doesn't?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 8 Dec 2008 15:07:37 -0600

On Dec 8, 2008, at 2:39 PM, Jiri Kuthan wrote:

>>> script-
>> Ummmm... no it doesn't.  It stops me from attacking the intended  
>> target's phone *directly*, but not as a smurf-style attack.  I  
>> simply set my From: to the *target's* URI, then send that INVITE to  
>> every number I can.  Thus I get other devices to flood the target  
>> with SUBSCRIBEs.  It's not as annoying as ringing the target's  
>> phone, for sure, but it's still an attack.  And unlike SMURF or  
>> hammer attack, it only requires me to know the target's AoR, not  
>> its IP or MAC.  And unlike a direct INVITE attack, I don't even  
>> need authorization or a path to reach the intended target; I only  
>> need to be able to reach a lot of Derive-capable UA's and hope some  
>> of them can reach the intended target.
>
> he is not getting an amplification. Couldn't we lower the concerns  
> by fingerpointing at the

Actually, for each INVITE, the attacker is potentially getting  
amplification in that SUBSCRIBE will be retransmitted until timeout or  
a response. So if the From: field isn't even pointed at SIP UA, one  
can get some level of amplification in just doing a DOS-flood on it.  
Say, 7 or 8 to 1. Also, since the INVITE can be very small, we might  
be looking at a 20 to 1 amplifier in terms of total data volume.  
Pointing that at a mobile device could be very annoying.

--
dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Dec 2008 19:23:25 -0500

> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Monday, December 08, 2008 3:36 PM
>
> Hadriel Kaplan wrote:
> checks have the property of: "if I pass then you know I'm good, if I fail
> then you know nothing (neither good nor bad)".   I would argue such a
> property is only useful in voice communications if it passes and provides
> a positive/"good" result *frequently*.
>

Sure, but I meant it in the context of even once everyone does it.  Let's assume every UA on the planet supports doing this DERIVE check right now.  If the check only works a small portion of the time when the call is actually good, then I would argue it won't stop Palin from assuming she's talking to Sarkozy - because a failure is not really a failure and can't be treated as a failure.  It's kinda like that annoying "This page contains both secure and nonsecure items" warning you get when you go to www.ietf.org agenda pages.  You get it so often you just ignore it, or turn it off altogether.

Anyway, Derive can't actually detect forgeries - it can only detect (some) non-forgeries.  That's a different property than a 4474-type thing; in a 4474-type thing a verification failure is actually a real failure; the kind of thing to alarm on and log and such. (if we had a working 4474-type thing)

And I didn't mean it as a knock on Derive - I meant that it contradicted Dean's claims, but if and only if Derive fails most of the time when the call is in fact legit.

I believe the cases where Derive fails even when a call is legit (false negatives), are:
1) Multiple contacts for a single AoR - it's a roll of the dice to get the right one
2) No contact for an AoR (e.g., From-URI is the main business number)
3) Can't reach that AoR domain (e.g., the call was forwarded to you, with no applicable SIP direct return path)
4) Can't reach that AoR domain with a SUBSCRIBE, but could an INVITE
5) B2BUA's in the signaling path, but the return path does not cross the same exact B2BUA's
6) B2BUA's in the signaling path, and they don't all support dialog-event package
7) UAC itself doesn't support the dialog-event package
8) UAC's domain doesn't allow subscriptions to dialog-event from outside its domain
9) E.164 Phone numbers, in general
10) Malicious middleboxes

(Some of those above are eventually fixable, BTW)

I believe the cases where Derive passes (says "legit") even though the call is actually a forgery (false positives), are:
1) Malicious middleboxes
2) Baiting attacks
3) From-URI encoding hacks
4) DNS spoofing or other attacks on rfc3263

(Which isn't much worse than any other mechanism, fwiw)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Dec 2008 23:27:34 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiri
> Kuthan
> Sent: Monday, December 08, 2008 3:26 PM
>

I don't think 4474 has failed to get implementation due to CA's.  At least companies don't seem to have trouble getting them for HTTPS. (They're not *that* hard to get AFAIK, though they're not free)  I think 4474 failed to get implementation because (1) most people don't have this problem yet, (2) many don't think they'll have a problem anytime soon, and (3) it won't work in the cases it would actually provide value for. (or at least #3 is why we didn't bother with it)

The main "issue" with 4474 is in fact signing that SDP.  The other issues with it that make it break are all resolvable, I think.

If you're willing to live with ignoring SDP, as DERIVE does, then a concept similar to 4474 can easily be made to work.  But so far we have not gotten consensus in this WG that we can be allowed to ignore the SDP.  (even though we have made the argument that we're not providing media identity - we're providing caller-identity)  :(

-hadriel

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 10 Dec 2008 21:54:50 +0100

> If you're willing to live with ignoring SDP, as DERIVE does, then a concept similar to 4474 can easily be made to work.  But so far we have not gotten consensus in this WG that we can be allowed to…

Possibly yes.

Definitely the SDP is the key obstacle. I mean the WG seems to be quite
insincere to itself if it bets on pristine SDP. For sake of record, we have
been deploying SDP-rewriting proxies since 2003 and till today we would not
be able to run VoIP without it. It almost reminds me when someone during
an applauded NAT rant asked a WG who is using them and about 99% raised
hands (probably applauding in anticipation of turning on IPv6 next month).

Would be RFC4474 rolling out without this limitation -- I'm guessing 
not, but
unlike the SDP fact, it is a guess of mine. We indeed obtained some 
concerns
about the extra CA overhead (more about third party, SLA, etc rather than
technical concerns) but it was more what-if type of concern and we
did not pass the SDP-if. On the scale straight-forward/doable/better-not
I would upgrade it from better-not to doable but not to straight-forward.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 10 Dec 2008 22:34:43 +0100

> Anyway, Derive can't actually detect forgeries - it can only detect (some) non-forgeries.  That's a different property than a 4474-type thing; in a 4474-type thing a verification failure is actuall…

Yes. (Under the assumption that sender domain is using it, otherwise you 
are ending up with "dunno" too.)

> 10) Malicious middleboxes
+ 3pcc, +call-forwarding (could be sub-cases of some of the points above)

> 4) DNS spoofing or other attacks on rfc3263

Yes, that's I think a very good summary.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 11 Dec 2008 00:46:14 +0100

> caller-ID display. So what do I care about From: fields?

if you don't care about who is calling you, then this is clearly
not a problem for you (Even though one could come up with distinctive
ringing but I'm not sure those who generally don't care about who is
calling them will be interested in it.)

I actually find that with GSM, caller-id is the only massively used
telephony features.

> 
> If I start getting nuisance rings, I might want to turn on null-auth so 
> that I at least have a traceback to a responsible IP address so that I 
> can send the lawyer-ninjas after somebody. In this context, what does 
> DERIVE give me that a null-auth doesn't?

just to be safe -- are you referring to
http://www.cs.columbia.edu/sip/drafts/sip/draft-schulzrinne-sip-null-00.pdf?

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 11 Dec 2008 00:47:58 +0100

Dean Willis wrote:
> assessment. What is the risk? In what scenarios does it occur? What are 
> the consequences?
> 
> Given the threat assessment, we then need to understand how the solution 
> impacts that threat. What are the possible ranges of policy? What is the 
> recommended policy? How does it impact behavior in a system that uses 
> this solution?

Thanks, that's helpful, we will try to address it in -01. Hadriel's list
was excellent input too.

-jiri

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 10 Dec 2008 17:48:42 -0700

On Dec 10, 2008, at 1:54 PM, Jiri Kuthan wrote:

>>> RFC4474 is simply not there. Despite we=iptel/TKLC have  
>>> implemented in
>>> SER,
>> I don't think 4474 has failed to get implementation due to CA's.   
>> At least companies don't seem to have trouble getting them for  
>> HTTPS. (They're not *that* hard to get AFAIK, though they're not  
>> free)  I think 4474 failed to get implementation because (1) most  
>> people don't have this problem yet, (2) many don't think they'll  
>> have a problem anytime soon, and (3) it won't work in the cases it  
>> would actually provide value for. (or at least #3 is why we didn't  
>> bother with it)
>> The main "issue" with 4474 is in fact signing that SDP.  The other  
>> issues with it that make it break are all resolvable, I think.
>> If you're willing to live with ignoring SDP, as DERIVE does, then a  
>> concept similar to 4474 can easily be made to work.  But so far we  
>> have not gotten consensus in this WG that we can be allowed to  
>> ignore the SDP.  (even though we have made the argument that we're  
>> not providing media identity - we're providing caller-identity)  :(
>
>
> Possibly yes.
>

Jiri, I would like to make sure I understand exactly what is broken  
here. So, say some B2BUA that implements 4474, like SER is running at  
iptel.org. And I have an account, say [email-masked]. Now my phone  
is registered and sends an INVITE to SER with the From set to "[email-masked] 
". My understanding is SER edits the SDP then does the 4474 signature  
and sends it on.

So in the case you are discussing here, what exactly is broken that  
stops iptel.org from both editing SDP and doing 4474?

Cullen <with my individual contributor role>

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Dec 2008 19:08:41 -0600

On Dec 10, 2008, at 5:46 PM, Jiri Kuthan wrote:
>
>> If I start getting nuisance rings, I might want to turn on null- 
>> auth so that I at least have a traceback to a responsible IP  
>> address so that I can send the lawyer-ninjas after somebody. In  
>> this context, what does DERIVE give me that a null-auth doesn't?
>

Yes, that's the one.

We need to distinguish exactly which likely cases DERIVE might work  
against that null-auth doesn't; this becomes part of the "threat  
model" that is needed to get past the security droids.

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Dec 2008 19:20:13 -0600

On Dec 10, 2008, at 6:48 PM, Cullen Jennings wrote:
> here. So, say some B2BUA that implements 4474, like SER is running  
> at iptel.org. And I have an account, say [email-masked]. Now my  
> phone is registered and sends an INVITE to SER with the From set to "[email-masked] 
> ". My understanding is SER edits the SDP then does the 4474  
> signature and sends it on.
>

I'm not Jiȓi, but:

The INVITE hits the SER proxy at the terminating domain, say FWD,  
which then rewrites the SDP and sends it on. The originating signature  
is now broken. Or the FWD proxy rewrites the signature, and the cert  
doesn't match the domain. Broken.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 10 Dec 2008 18:32:44 -0700

I actually don't think that is the case. My recollection, could be  
very wrong, what that SER edits outbound, not inbound SDP. That said,  
if SER editing my inbound SDP, it would check the signature before  
doing so, and then go and execute my black list that rejected calls at  
2 am form people other than a certain set, then send the call down to  
me. Once again, I not getting what is broken in this case.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Dec 2008 00:04:08 -0500

> Cullen Jennings

1) If the call goes to another SER in another domain that is fixing NAT for its UAS, then that SER will edit the SDP before sending it to the UAS (or at least if it's doing what SBC's have been doing for many years).  If that SER is the verification service then sure it can do as you say, instead of letting the UAS verify it.  But maybe they want to let the UAS make its own decisions. (crazy guys!)

But as we've talked about before, that is just the tip of the iceberg because changing SDP for NAT traversal is only one of a long list of reasons for changing SDP.  And in most cases we're not talking about only the UAS not being able to verify - we're talking the last/terminating domain as a whole being unable to verify. (which was kinda the point of it I thought)  So to continue the list of cases...

2) If the call goes to a 3PCC server that holds onto SDP when it forwards on the INVITE, then the signature breaks.

3) If the call goes to a transcoding element that modifies the SDP codec list when it forwards on the INVITE, then the signature breaks.

4) If the call goes through transit providers (long-distance/wholesale/international), then often SDP gets changed and the signature breaks.

5) If the call goes from an Enterprise PBX over a SIP Trunk to a provider, and they route the invite to another Enterprise PBX, then often SDP gets changed and the signature breaks.

6) If the call goes from an Enterprise PBX over a SIP Trunk to a provider, and they route the invite to a mobile-phone provider, such as a GSMA-IPX one, then often SDP gets changed and the signature breaks.

7) If the call goes from an Enterprise PBX over a SIP Trunk to a provider, and they route the invite to another provider, then often SDP gets changed and the signature breaks.

8) If the call goes from a provider over a SIP Trunk to an Enterprise PBX, and the PBX routes the invite to a branch office over a VPN, then often SDP gets changed and the signature breaks.

9) If the call goes from a branch office over a VPN to an Enterprise PBX, and the PBX routes the invite over a SIP Trunk to its provider, then often SDP gets changed and the signature breaks.

10) If the call goes from anyone anywhere, to anyone who could actually benefit from something like 4474 instead of simply using PAI, then often SDP gets changed and the signature breaks.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Dec 2008 23:32:18 -0600

On Dec 10, 2008, at 7:32 PM, Cullen Jennings wrote:

> very wrong, what that SER edits outbound, not inbound SDP. That  
> said, if SER editing my inbound SDP, it would check the signature  
> before doing so, and then go and execute my black list that rejected  
> calls at 2 am form people other than a certain set, then send the  
> call down to me. Once again, I not getting what is broken in this  
> case.
>

It's not end to end. If your UAS is checking RFC 4474, it's going to  
reject the call.

Now, did you WANT a DTLS-SRTP media fingerprint? If so, then you need  
RFC 4474 end-to-end.

--
Dean

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 11 Dec 2008 17:25:22 +0100

Cullen Jennings wrote:

> iptel.org.

It can be even a proxy (well if we consider it then still legitimate enough
to call it a "SIP proxy" if it rewrites SDP).

>  And I have an account, say [email-masked]. Now my phone is
> registered and sends an INVITE to SER with the From set to 
> "[email-masked]". My understanding is SER edits the SDP then does the 
> 4474 signature and sends it on.

That's a scenario which indeed DOES work -- SDP rewriting occurs before 
signing
and there is no further rewriting before verification. Our 
implementation is done
the way it works under these assumptions.

In detail: caller's proxy thinks the caller is behind a NAT and decides to
rewrite  SDP in INVITE  to include an RTP relay's address in it. it signs
the modified SDP. Note that message integrity check refers to what this 
proxy
is receiving, not sending...which is still fine (at least for me). It 
forwards
to recepient's proxy, which verifies the SDP. Then it can even rewrite 
it too
(for sake of callee's NAT traversal for example) --  as long as downstream
entities trust this proxy to have done its verification job.

The problem is the assumption that we can manage to get the signer and 
verifier
next to each other without an SDP rewriter in between them. It goes too 
far in the
field despite I find it unfortunate. Shortly, there are incredibly many
"middleboxes" that stand in the way and change the SDP.   These include:
SIP-aware firewalls (ALGs are IMO plain broken vehicle but they are in the
field), SBCs,  load-balancers, and transcoders.

To make it clear: I don't think that the 4474 architecture is broken, I 
think
that the assumption of the SIP path not being broken is too brittle. I was
initially hopeful that one could put 4474 in the administrative borders
so that interdomain trust is not damaged by intermediary SDP rewrites.
Unfortunately it seems that in the field any "atomic" link can be
still broken by some SDP re-writers.

The "right" architectural fix would be to make sure that there are no 
SDP rewrites
between signer and verifier (much weaker assumption than end-2-end SDP 
integrity)
which is IMO doable but is for some reason not being done. In lieu of which,
I think giving up on SDP integrity would allow better penetration by 
being more
robust against such networks.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 11 Dec 2008 18:12:22 +0100

Dean Willis wrote:
>> is registered and sends an INVITE to SER with the From set to 
>> "[email-masked]". My understanding is SER edits the SDP then does 
>> the 4474 signature and sends it on.
>>
> The INVITE hits the SER proxy at the terminating domain, say FWD, which 
> then rewrites the SDP and sends it on. The originating signature is now 
> broken.
> Or the FWD proxy rewrites the signature, and the cert doesn't 
> match the domain. Broken.

One could try to find easier scenarios where only the terminating proxy
verifies (and then rewrites SDP and removed Identity), and its UASs 
trust it.
It is not "universal" but in the field I found that even in such scenarios
someone still pops up who breaks the SDP before it gets to the recipient.
(even though it is under administrative control of those who have interest
in making it work). Rather than relying on a "clean SIP path" I would thus
prefer not to have to rely.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 11 Dec 2008 18:22:32 +0100

Cullen Jennings wrote:
> 
> I actually don't think that is the case. My recollection, could be very 
> wrong, what that SER edits outbound, not inbound SDP. That said, if SER 
> editing my inbound SDP, 
> it would check the signature before doing so,
> and then go and execute my black list that rejected calls at 2 am form 
> people other than a certain set, then send the call down to me. Once 
> again, I not getting what is broken in this case.

well both inbound and outbound proxy servers may or may not edit SDP. If
NAT is the driving reasons, inbound proxy can only do so if the caller
appears natted, and outbound proxy can do so if the callee appears natted,
leading all four combinations of inbound/outbound rewriting/leaving.

If one is happy with establishing the secured relationship only between
those two proxies (inbound rewriting *before* signing, outbound rewriting
*after* signing and no rewriting between them), it can work. Not 
representing
everyone's favorite scenario, I think this is of importance. The hard
part is the "no rewriting between them" -- that's broken too frequently.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 11 Dec 2008 18:44:55 +0100

> Now, did you WANT a DTLS-SRTP media fingerprint? If so, then you need 

That I cannot counter.

-jiri

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 11 Dec 2008 20:46:21 +0000

> Sent: 11 December 2008 17:45
> To: Dean Willis
> Cc: Cullen Jennings; SIP List
[JRE] I am not sure you need RFC 4474 end-to-end - you just need
something end-to-end that binds the fingerprint of the DTLS-SRTP
certificate to a substantial part of the SIP message, but that need not
include the entire SDP.

John

---

From: Dean Willis <[email-masked]>
Date: Thu, 11 Dec 2008 18:11:21 -0600

> certificate to a substantial part of the SIP message, but that need  

I don't disagree about what we MIGHT need, but what we DO need, given  
what we wrote into the dtls-srtp spec, is RFC 4474 all the way to the  
UAS.

All of these go together in explaining why we have no deployments of  
RFC 4474 and no deployments of DTLS-SRTP worth mentioning.

Apparently, people prefer public discourse with anonymous/unidentified  
parties. Given what I hear about college sex lives these days, I  
shouldn't be surprised.

--
Dean

---

From: Michael Procter <[email-masked]>
Date: Fri, 12 Dec 2008 10:53:52 +0000

>> http://www.cs.columbia.edu/sip/drafts/sip/draft-schulzrinne-sip-null-00.pdf?

Presumably null-auth will only work if the perpetrator of the nuisance
calls doesn't take advantage of the text:
# The client could also provide the Null credentials immediately if
# it knows that it has no other credentials, avoiding an extra
# round-trip delay.

Maybe the null challenge should round-trip a nonce.  At least that would
show the challenge got back to somewhere useful.

Michael