Subject: [stir] Call Forward/Follow-me

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 18:17:57 +0000

A problem that has been noted is PBXs and other services that implement Call Forward and Follow-me by spoofing From to be the original caller when they originate a call from the PBX to the ultimate destination.  They do this so that the called party sees the original caller when they get the call.

If we outlaw spoofing, these services wouldn't be able to do that.  They would have to use History or other headers to pass the original calling party number.

I believe that we can't continue to allow this kind of spoofing.  There are other headers which are appropriate for use.

One of the arguments given is that in older systems such as POTS or 2G/3G, there is no way to get caller ID to show data from the other headers.  I think we have to accept such limitations.  Newer systems would not have that problem of course.

While it may be unfortunate that something like forward or follow-me doesn't work as well as it did, I think that it's the right tradeoff.

Please note that there are another class of calling party number spoofing circumstances we CAN do something about.  Suppose a doctor wants to place a call on her mobile that appears to come from her office number.  In that case the doctor can authorize the service that arranges that call.  They can get the cert for the office number and authorize the service to place calls with that number by giving them a cert for that authorization.  This also works for, as an example, a call center placing calls for an enterprise.

The difference is, of course, that the "spoofed" number is a number delegated to the entity spoofing, rather than the forward/follow me case where the spoofed number is the calling party and the entity spoofing is authorized by the called party.

Brian

---

From: Alan Johnston <[email-masked]>
Date: Fri, 7 Jun 2013 13:23:16 -0500

I think that History-Info should be the solution going forward, certainly
for SIP networks.

- Alan -

On Fri, Jun 7, 2013 at 1:17 PM, Rosen, Brian <[email-masked]>wrote:

> A problem that has been noted is PBXs and other services that implement
> Call Forward and Follow-me by spoofing From to be the original caller when
> they originate a call from the PBX to the ultimate destination.  They do
> this so that the called party sees the original caller when they get the
> call.
>
> If we outlaw spoofing, these services wouldn't be able to do that.  They
> would have to use History or other headers to pass the original calling
> party number.
>
> I believe that we can't continue to allow this kind of spoofing.  There
> are other headers which are appropriate for use.
>
> One of the arguments given is that in older systems such as POTS or 2G/3G,
> there is no way to get caller ID to show data from the other headers.  I
> think we have to accept such limitations.  Newer systems would not have
> that problem of course.
>
> While it may be unfortunate that something like forward or follow-me
> doesn't work as well as it did, I think that it's the right tradeoff.
>
> Please note that there are another class of calling party number spoofing
> circumstances we CAN do something about.  Suppose a doctor wants to place a
> call on her mobile that appears to come from her office number.  In that
> case the doctor can authorize the service that arranges that call.  They
> can get the cert for the office number and authorize the service to place
> calls with that number by giving them a cert for that authorization.  This
> also works for, as an example, a call center placing calls for an
> enterprise.
>
> The difference is, of course, that the "spoofed" number is a number
> delegated to the entity spoofing, rather than the forward/follow me case
> where the spoofed number is the calling party and the entity spoofing is
> authorized by the called party.
>
> Brian
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jun 2013 15:56:58 -0400

On 6/7/13 2:23 PM, Alan Johnston wrote:
> I think that History-Info should be the solution going forward,
> certainly for SIP networks.

I expect that there will be a variety of "solutions".
We aren't obligated to mandate one. Its only necessary to ban spoofing, 
and let people decide which alternative they want to use.

If H-I was deployed across the full range of equipment out there, I'd 
expect that correct reporting of calling party would be very spotty.

Now that calling is typically cheap enough that most people don't think 
about it, a simple solution to forwarding is 3xx, and to transfer is 
basic REFER. Those will get the calling party right. (Except in cases 
where you *want* the identify of the intermediary to be displayed. And 
that is the easy case.)

	Thanks,
	Paul

> - Alan -
>
>
> On Fri, Jun 7, 2013 at 1:17 PM, Rosen, Brian <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     A problem that has been noted is PBXs and other services that
>     implement Call Forward and Follow-me by spoofing From to be the
>     original caller when they originate a call from the PBX to the
>     ultimate destination.  They do this so that the called party sees
>     the original caller when they get the call.
>
>     If we outlaw spoofing, these services wouldn't be able to do that.
>       They would have to use History or other headers to pass the
>     original calling party number.
>
>     I believe that we can't continue to allow this kind of spoofing.
>       There are other headers which are appropriate for use.
>
>     One of the arguments given is that in older systems such as POTS or
>     2G/3G, there is no way to get caller ID to show data from the other
>     headers.  I think we have to accept such limitations.  Newer systems
>     would not have that problem of course.
>
>     Please note that there are another class of calling party number
>     spoofing circumstances we CAN do something about.  Suppose a doctor
>     wants to place a call on her mobile that appears to come from her
>     office number.  In that case the doctor can authorize the service
>     that arranges that call.  They can get the cert for the office
>     number and authorize the service to place calls with that number by
>     giving them a cert for that authorization.  This also works for, as
>     an example, a call center placing calls for an enterprise.
>
>     delegated to the entity spoofing, rather than the forward/follow me
>     case where the spoofed number is the calling party and the entity
>     spoofing is authorized by the called party.
>
>     Brian
>     [email-masked] <mailto:[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Jun 2013 16:10:13 -0400

I'm getting confused by this thread.
History-Info (or Diversion) is only useful to know the original *called* destination party, not *calling* source party.

I.e., if the To-username gets changed by the PBX, Hist-info might tell you what it used to be... if the req-uri matched the To, and the PBX does Hist-Info, and all downstream devices pass it on, and if the final UAS could decipher which Hist-info to look at, and if the stars aligned.

But if the From username got changed nothing will tell you what it used to be.  I think Brian was arguing the From should be changed by the PBX to be the new source of the new call, namely the PBX's main number or the To-number being forwarded from - because otherwise it's spoofing the From for this "new" call - but I don't think it should change the From because I contend it's not spoofing, but just routing the same call as a B2BUA.

-hadriel

On Jun 7, 2013, at 3:56 PM, Paul Kyzivat <[email-masked]> wrote:

> We aren't obligated to mandate one. Its only necessary to ban spoofing, and let people decide which alternative they want to use.
> 
> If H-I was deployed across the full range of equipment out there, I'd expect that correct reporting of calling party would be very spotty.
> 
> Now that calling is typically cheap enough that most people don't think about it, a simple solution to forwarding is 3xx, and to transfer is basic REFER. Those will get the calling party right. (Except in cases where you *want* the identify of the intermediary to be displayed. And that is the easy case.)
> 
> 	Thanks,
> 	Paul
> 
>> - Alan -
>> 
>>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 Jun 2013 15:06:49 -0700

Hadriel said:

"But if the From username got changed nothing will tell you what it
used to be.  I think Brian was arguing the From should be changed by
the PBX to be the new source of the new call, namely the PBX's main
number or the To-number being forwarded from - because otherwise it's
spoofing the From for this "new" call - but I don't think it should
change the From because I contend it's not spoofing, but just routing
the same call as a B2BUA."

[BA] I think what is being advocated is not to break the original
signature, however it is done.  So if the signature is over the To:
and From: field but not the Request-URI, then the PBX could re-target
without having to recompute (or invalidate) the signature.
Re-targeting without changing the "From:" would not be considered
"spoofing".

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Jun 2013 22:23:31 -0400

> Please note that there are another class of calling party number spoofing circumstances we CAN do something about.  Suppose a doctor wants to place a call on her mobile that appears to come from he…

That's probably something we might want to flesh out a bit. My very rough vision in the central database case would be something like the following:

(1) Owner [doctors' office] says: "Please mint a cert that entitles Doctor Smith [public key attached] to use our number 555 1234." [signed by assignee]

(2) Database returns cert, which is handed to doctor.

(4) Doctor uses cert just like any other.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 7 Jun 2013 23:12:50 -0400

The RPKI has a protocol for this, known colloquially as the "up/down"
protocol.
<http://tools.ietf.org/html/rfc6492>

Certificate request:
<http://tools.ietf.org/html/rfc6492#section-3.4.1>

On Fri, Jun 7, 2013 at 10:23 PM, Henning Schulzrinne <[email-masked]>wrote:

> spoofing circumstances we CAN do something about.  Suppose a doctor wants
> to place a call on her mobile that appears to come from her office number.
>  In that case the doctor can authorize the service that arranges that call.
>  They can get the cert for the office number and authorize the service to
> place calls with that number by giving them a cert for that authorization.
>  This also works for, as an example, a call center placing calls for an
> enterprise.
>
>
> That's probably something we might want to flesh out a bit. My very rough
> vision in the central database case would be something like the following:
>
> (1) Owner [doctors' office] says: "Please mint a cert that entitles Doctor
> Smith [public key attached] to use our number 555 1234." [signed by
> assignee]
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 Jun 2013 14:18:51 -0400

> (4) Doctor uses cert just like any other.

If we want such a thing to work in the near-term timeframe, I don't think it can work that way.  For one thing I don't expect phones to be able to do the signing themselves, nor their access service providers to believe/trust the phones.  As far as I know, today the Doctor phone's service provider has to be in on it, and the provider equipment is provisioned to know the Doctor's phone can claim another caller-id (e.g., P-Associated-URI).  I think it's a big jump to expect them to let any subscriber to claim to be any number just because the supposed holder of that number "authorized" them to.  Even ignoring the P/S-CSCF type equipment, there're a lot of other systems involved in this stuff, for billing, CALEA, troubleshooting, etc.

A more likely scenario is:
(1) Doctor's office submits a request form with its service provider to add Doctor's phone as authorized user for office number caller-id, or with Doctor phone's service provider as a pull request.

(2) The service providers fax each other authorization forms with legal signatures.

(2b) If there is some big central database model, then the Doctor phone's service provider gets added as second source for the Office number.

(3) The Doctor phone's service provider adds into its databases the Office caller-id as an authorized associated number for the phone to use for outbound calls, which triggers associated identity handling during next phone registration.

(4) The Doctor makes an outbound call using the Office number, which the service provider authorizes and signs using its own cert.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Sat, 8 Jun 2013 18:30:11 +0000

Question:  Do we really care how many redirections occurred in the middle
network hops if we know what the original source of the signaling was?

Put another way, if we have a legitimate scape-goat for a problem call, do
you need to catch all the stooges all at once?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Saturday, June 08, 2013 2:19 PM
To: Henning Schulzrinne
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] Permitted spoofing

> (4) Doctor uses cert just like any other.

If we want such a thing to work in the near-term timeframe, I don't think it
can work that way.  For one thing I don't expect phones to be able to do the
signing themselves, nor their access service providers to believe/trust the
phones.  As far as I know, today the Doctor phone's service provider has to
be in on it, and the provider equipment is provisioned to know the Doctor's
phone can claim another caller-id (e.g., P-Associated-URI).  I think it's a
big jump to expect them to let any subscriber to claim to be any number just
because the supposed holder of that number "authorized" them to.  Even
ignoring the P/S-CSCF type equipment, there're a lot of other systems
involved in this stuff, for billing, CALEA, troubleshooting, etc.

A more likely scenario is:
(1) Doctor's office submits a request form with its service provider to add
Doctor's phone as authorized user for office number caller-id, or with
Doctor phone's service provider as a pull request.

(2) The service providers fax each other authorization forms with legal
signatures.

(2b) If there is some big central database model, then the Doctor phone's
service provider gets added as second source for the Office number.

(3) The Doctor phone's service provider adds into its databases the Office
caller-id as an authorized associated number for the phone to use for
outbound calls, which triggers associated identity handling during next
phone registration.

(4) The Doctor makes an outbound call using the Office number, which the
service provider authorizes and signs using its own cert.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 Jun 2013 15:02:48 -0400

I think the hope was to proactively prevent a bogus call from succeeding, as opposed to reactively hunting down the perpetrators after it happened.  The latter case should be possible now, since CDRs record enough to backtrack to the upstream provider, and that provider's CDRs can find its upstream provider, etc.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 8 Jun 2013 16:22:53 -0400

Hadriel's thinking here makes a great deal of sense but we are coming really
close to dealing with issues that are the ultimately the provenance of the
NRA.  

First, it would be very helpful if anyone has any URL's that could point to
other legislation similar to the US Truth in Caller ID act.  It might be
helpful to understand some other views here.  Has the EC done anything
similar especially in relation to their Privacy Directives?

Second if you actually look at the FCC report to Congress Henning provided
you can pretty easily read between the lines here.  IMHO as an amateur
telecom lawyer you can easily see that Truth in Caller ID Act is pretty
useless.  First enforcement requires proof of "intent to defraud" which is
really hard to prove. So what is intent?  Sort of like "absence of malice"
in US Libel laws.  Second it gave the FCC zero "authority to act" in dealing
with third party service providers. 

The better solution would have been to make ALL spoofing of the signaling
data illegal period, except in the cases where the consumer or enterprise
could demonstrate a genuine need based on a strict set of criterion. Then
the consumer or enterprise could present a "certificate of need" to the
service provider that could provision the requirements as Hadriel suggests.
The FCC report clearly saw that Congress understood the legitimate need for
some permitted spoofing but took the wrong path to enforcing the
requirement. 

KISS .. keying off the Full E.164 should be relatively easy to do even in
intranational calling situations.  The To: and From: should always be
converted to + whenever possible at session origination. Describing how
Permitted Spoofing COULD BE achieved is useful to document. 

In any event we certainly have to understand these issues but ultimately the
definition of Permitted Spoofing is a NRA issue since the E.164 namespace is
under the absolute control of the nation state.    None of you wants to hear
any sad tales about ENUM and e164.arpa I'm sure. 

-----Original Message-----

-hadriel

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 12:57:12 +0000

I agree, the point is to prevent bad calls.  I understand that following calls back through CDRs  is very difficult and time consuming from the point of view of the law enforcement agency doing the tracking.  That's why Henning would like us to come up with a way of automating that traceback.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jun 2013 17:07:14 -0400

Hadriel,

You are right. I wasn't thinking clearly.

What H-I *can* do is identify who forwarded a call. This might be 
important to the forwardee - he might not want to answer unless it is 
from someone he knows. So H-I *can* serve as an alternative to an 
intermediary changing From or To when forwarding. (But it then leaves 
the recipient with difficulty in deciding which number it will display.)

	Thanks,
	Paul

---

From: Michael Hammer <[email-masked]>
Date: Tue, 11 Jun 2013 06:12:53 +0000

If you stop it at the start, wouldn't that solve some fraction of the
problem?

Do we know how many calls are spoofed from the start versus from
redirections?

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Saturday, June 08, 2013 10:03 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Permitted spoofing

I think the hope was to proactively prevent a bogus call from succeeding, as
opposed to reactively hunting down the perpetrators after it happened.  The
latter case should be possible now, since CDRs record enough to backtrack to
the upstream provider, and that provider's CDRs can find its upstream
provider, etc.

-hadriel

On Jun 8, 2013, at 2:30 PM, Michael Hammer <[email-masked]>
wrote:

> Question:  Do we really care how many redirections occurred in the 
> middle network hops if we know what the original source of the signaling
was?
> 
> Put another way, if we have a legitimate scape-goat for a problem 
> call, do you need to catch all the stooges all at once?
> 
> Mike
>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 11 Jun 2013 07:01:34 +0000

But, I'll note having following the thread, that the issue seems to devolve
to 
who wants to assert the presented caller ID value, sign it and 
be ultimately responsible for the prior chain of events.

Mike

p.s.  I see a re-hash of prior history of various existing headers, but
wondering 
if using what didn't work before amounts to hitting ones head against a wall
and wondering why it hurts?
I'm not against trying to get existing to work, but don't necessarily want
to repeat history.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Hammer
Sent: Tuesday, June 11, 2013 9:13 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Permitted spoofing

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Saturday, June 08, 2013 10:03 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Permitted spoofing

-hadriel

was?

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 13:03:51 +0000

For the problems we're aiming at (robocalling, vishing and swatting), they are 100% spoofed from the start.  MITM is a potential problem, which would be desirable to cut off, but it's not the stated problem we're trying to solve.

There may be some number of service providers in the path that are tolerant of the problem, but not really complicit.   The goal is to make them be intolerant of their customers not providing verifiable identity.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 13:04:53 +0000

Of course!

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Jun 2013 09:12:20 -0700

On 6/11/2013 6:03 AM, Rosen, Brian wrote:
> MITM is a potential problem, which would be desirable to cut off, but it's not the stated problem we're trying to solve.
>
> There may be some number of service providers in the path that are tolerant of the problem, but not really complicit.

This could have a pretty substantial effect on design choices.

For example, session-based SSL authentication -- that is, without server 
validation (certs) -- permits MITM, which seems to be often/generally 
acceptable in terms of actual practice, although rhetoric claims otherwise.

But in general, I've had the impression that any effort at 
authentication or confidentiality comes with an expectation of 
resistance to MITM compromises.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 11 Jun 2013 22:37:03 +0200

Guess this is MITM is the next VoIP issue to come up.

Both way authentication is not considered for VoIP because service providers are trusted by default. ;-)

DANE WG with their DNSsec approach might be a solution for this MITM issues as well?

BTWY:
We had nasty routing issues in pure PSTN as well. There the MITM could pretend being a fixed network operator instead of a mobile operator to "optimize" their business case on termination fees.

Willi

On 11.06.2013, at 18:12, Dave Crocker wrote:

> For example, session-based SSL authentication -- that is, without server validation (certs) -- permits MITM, which seems to be often/generally acceptable in terms of actual practice, although rhetoric claims otherwise.
> 
> But in general, I've had the impression that any effort at authentication or confidentiality comes with an expectation of resistance to MITM compromises.
> 
> d/
> 
> -- 
> Dave Crocker

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 20:41:46 +0000

This is not just MITM.

The bad guy just needs to receive any good call, and then use it to
impersonate the person who called them.

I think we need the To, From, some form of call-id and a timestamp to get
a decent signature.

We don't have domains in this discussion - we have telephone numbers, so I
think DANE can't help us.

Brian

On 6/11/13 4:37 PM, "Wilhelm Wimmreuter" <[email-masked]> wrote:

>We had nasty routing issues in pure PSTN as well. There the MITM could
>pretend being a fixed network operator instead of a mobile operator to
>"optimize" their business case on termination fees.
>
>Willi
>
>
>
>
>>> MITM is a potential problem, which would be desirable to cut off, but
>>>it's not the stated problem we're trying to solve.
>>> 
>>> There may be some number of service providers in the path that are
>>>tolerant of the problem, but not really complicit.
>> 
>> 
>> For example, session-based SSL authentication -- that is, without
>>server validation (certs) -- permits MITM, which seems to be
>>often/generally acceptable in terms of actual practice, although
>>rhetoric claims otherwise.
>>

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 11 Jun 2013 23:35:05 +0200

> I think we need the To, From, some form of call-id and a timestamp to get
Yes,
... confessed in my previous message already ;-)

> think DANE can't help us.

 OK, but server authentication is definitely next.
DNS is the only way to reach these servers today. We are farther on the Internet than typical PSTN paradigms allow us to follow.

 SIP does not have decent server authentication and therefore one can pretend to be your telecom server of choice.

Willi

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Jun 2013 14:42:53 -0700

>   SIP does not have decent server authentication and therefore one can pretend to be your telecom server of choice.

Well...

Server authentication is needed if the model is trust via the channel.

It isn't needed if the trust goes with the data object, independent of 
the channel.

DNSSec and DKIM are object-based.  Of course, TLS is channel-based.

d/

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Wed, 12 Jun 2013 10:43:12 +0200

For the sake of strong authentication like secure Caller-ID we definitely need object-based proof only.

This is an important distinction I guess and we shall keep that in mind.

Willi

On 11.06.2013, at 23:42, Dave Crocker wrote:

> It isn't needed if the trust goes with the data object, independent of the channel.
>