Subject: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.

From: Richard Shockey <[email-masked]>
Date: Sat, 17 Oct 2015 21:26:03 -0400

On 10/17/15, 4:20 PM, "stir on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

>On 10/17/15 2:40 PM, Richard Shockey wrote:
>>
>> Martin is correct. The former. The originating provider signs based on the fact that they issued the number to the customer and presumably has the billing relationship.  The terminating provider validates the call and presents to the UE the results.  I’m not worried about the UE actually doing the validation right now. In the future probably but I would prefer to start simple.  "Rings of Defense” KISS for now.
>
>OK. So far so good.
>
>Now, When my UAS gets this with the signature by foobar.com asserting 
>that the number is valid, how do I know that foobar.com is responsible 
>for the number? I never heard of foobar.com. It could be a valid 
>provider somewhere. But it could also be entirely bogus.

RS> Well again pretending that I have been given the Magic Wand and by the Great and Almighty Dingo of Numbering…  The Terminating UAS does not really know if the originating provider has been given that number for issuance to the consumer/enterprise though there are ways of actually checking on that.  The Chain of Trust, which I assume will be written in stone or what passes for stone in regulatory terms, makes an an assumption that ATT trusts Verizon,  Verizon trusts Cox, Cox trusts Rodgers etc. That is because they all are licensed carriers given direct access to the numbering assets ( which are owned by the Government after all) and ultimately read write access to the LNP databases. Joe’s Pizza and Phone Company is not going to get a private key.

Because if something goes wrong then the Gods of Gatineau or 12th street send in the Drones to smite the nefarious evil doers in much the way they do now. This is not the Internet its Telephony. This is Voice USING IP. There is a very very large corpus of rules on how TSP’s are Interconnected via SIP now and there is no reason to believe that is going to change any time soon if ever. 

>
>Does this have *something* to do with the CA for the cert? Or does it 
>rely on me having a whitelist of trusted signers of phone numbers?

RS> its totally about who can issue valid credentials. The trusted list of signers is presumed to be TSP’s who have been issued the appropriate licenses by their government.  I know who they are.  In the US they typically have NECA OCN numbers.

https://www.neca.org/Code_Administration.aspx

>
>Having specialized CA certs for this would help. Then I wouldn't need to 
>know every phone provider. I could instead choose to trust any one that 
>has a CA I trust for this purpose.
>
>And it would be better yet if it was tied back to the formal delegation 
>of phone numbers.

RS> Right.  

>
>> There are going to have to be some profiles about how transit providers treat the data etc but I don’t want to wade into the weeds about that right now. I’d prefer to see a classic SIP trapezoidal model emerge for the first round.
>
>If what you say is true, then transit providers should simply leave the 
>cert untouched.

RS> Essentially yes but there are some use cases where the transit providers could act in various ways by testing the claims. 

>
>> The preference is certainly to let the UE decide, however that does not preclude the terminating carrier from acting directly on behalf of the consumer, if that is the consumer preference. That BTW was the clear intent of the FCC robocall order.   I can run spam filters on my mail client or I can pay some one to act on my behalf . That’s a well understood model.
>
>IMO it is fine to allow opt-in network services, that validate according 
>to some known policy and then block failing calls or otherwise treat 
>them specially.
>
>But I would certainly want to have the option of having them step out of 
>the way and let my device handle it as I wish.

RS> Correct they could still validate, do nothing and pass the credential with the JWT along but if you want to get Ring 0 access to the dialers in IOS or Android good luck.  There will be a bunch of profiles here once we see how some of this actually works in a Operational environment.

>
>In this way it is a lot like spam filters.
>
>> Speaking of which .. Paul do you have any thoughts on where we could put Validation data so the UE could display it?  I can’t get a reasonable answer from folks about that.
>
>Here I think it would be good to "let a 1000 flowers bloom".
>Phones come in so many different form factors now, and people use them 
>in so many different ways, that I don't think there is one right answer.

RS> I don’t know about that. In VoLTE the INVITE reaches the UE directly. I don’t think you can ignore what Header some data from the UAS that preforms the validation needs to be inserted.  CALL-INFO? What are semi-colon for after all.  I don’t know.  But you are entirely correct how the device displays or embellishes said data is where the 1000 flowers should bloom and where TSP’s can add value if they choose to do so. 

>
>Calls could be sorted into different trust levels, and that could be 
>signaled via differing ring tones, or different colors when the call is 
>displayed. Or with all sorts of different visual decorations on the 
>screen. There are many more options on a smart phone than on a black phone.

RS> Exactly . WARNING WARNING WILL ROBINSON.  

Use Case #1. ITS RACHEL FROM CARDMEMBER SERVICES. 

Use Case #2  ITS YOUR MOTHER. 

>
>I would like to be able to choose phone call filter apps for my phone, 
>just like choose other apps.
>
>That assumes that the UAS is doing the analysis of the cert itself. If 
>some network service is doing it on my behalf, then if call is passed 
>through to the phone it may be necessary to still convey nuances 
>determined by the service. Given that I will know the service is in the 
>path, this could be done with Alert-Info (using RFC7462), or callee-caps 
>(RFC3840). Either way some new tags will likely need to be defined.

RS> Hummm interesting suggestion. Will take under advisement. 

>
>	Thanks,
>	Paul
>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 18 Oct 2015 12:44:12 -0400

> RS> Well again pretending that I have been given the Magic Wand and by the Great and Almighty Dingo of Numbering…  The Terminating UAS does not really know if the originating provider has been give…

This is why I asked whether you were assuming transitive trust, or if 
the cert from the originator is passed to the recipient.

If foobar.com originates the call and provides the cert, what do the 
other carriers do when the they get this call? Do they reject it? If so, 
then I, the recipient haven't been given the right of decision. If they 
don't reject it, then I don't know whether they trust it or not.

And clearly there are cases where the major carriers accept calls from 
untrustworthy sources, else we wouldn't have the problem now. This is at 
least so for calls from other countries.

Or are you thinking that there is a class of screening that they do: if 
they know the number belongs to one carrier then they reject calls 
signed by somebody else?

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 18 Oct 2015 16:51:31 +0000

Calls from other countries will always be a problem. Is it possible to mark calls at the international gateway with "International Call", such that the CdP can use this for deciding to accept or reject?

We are not talking about transitive trust. If that was the case PAI would be the answer, but PAI without signing is tainted.

Lastly, carriers can only block calls with the customers consent. Lack of that the carrier passes the information to the user, and the user decides.

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Sunday, October 18, 2015 12:44 PM
To: [email-masked]
Subject: Re: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.

On 10/17/15 9:26 PM, Richard Shockey wrote:
>> that the number is valid, how do I know that foobar.com is 
>> responsible for the number? I never heard of foobar.com. It could be 
>> a valid provider somewhere. But it could also be entirely bogus.
>
>

This is why I asked whether you were assuming transitive trust, or if the cert from the originator is passed to the recipient.

If foobar.com originates the call and provides the cert, what do the other carriers do when the they get this call? Do they reject it? If so, then I, the recipient haven't been given the right of decision. If they don't reject it, then I don't know whether they trust it or not.

And clearly there are cases where the major carriers accept calls from untrustworthy sources, else we wouldn't have the problem now. This is at least so for calls from other countries.

Or are you thinking that there is a class of screening that they do: if they know the number belongs to one carrier then they reject calls signed by somebody else?

	Thanks,
	Paul

>> Having specialized CA certs for this would help. Then I wouldn't need 
>> to know every phone provider. I could instead choose to trust any one 
>> that has a CA I trust for this purpose.
>>
>> And it would be better yet if it was tied back to the formal 
>> delegation of phone numbers.
>
>
> RS> Right.
>
>
>>
>> If what you say is true, then transit providers should simply leave 
>> the cert untouched.
>
>> IMO it is fine to allow opt-in network services, that validate 
>> according to some known policy and then block failing calls or 
>> otherwise treat them specially.
>>
>> But I would certainly want to have the option of having them step out 
>> of the way and let my device handle it as I wish.
>
>
>> Phones come in so many different form factors now, and people use 
>> them in so many different ways, that I don't think there is one right answer.
>
>
>> signaled via differing ring tones, or different colors when the call 
>> is displayed. Or with all sorts of different visual decorations on 
>> the screen. There are many more options on a smart phone than on a black phone.
>
>> I would like to be able to choose phone call filter apps for my 
>> phone, just like choose other apps.
>>
>> That assumes that the UAS is doing the analysis of the cert itself. 
>> If some network service is doing it on my behalf, then if call is 
>> passed through to the phone it may be necessary to still convey 
>> nuances determined by the service. Given that I will know the service 
>> is in the path, this could be done with Alert-Info (using RFC7462), 
>> or callee-caps (RFC3840). Either way some new tags will likely need to be defined.
>
>

---

From: Richard Shockey <[email-masked]>
Date: Sun, 18 Oct 2015 17:02:13 -0400

Echoing Martin here.. We certainly understand that a lot of the problem comes from wholesale carriers and from one way SIP traffic.  There have been several ideas kicking around on how to label that traffic as it crosses the gateways. Pseudo-ANI labeling (my 666 NPA code idea) ..maybe even using this signing methodology to assert that the session might not be untrusted.  This goes to the problem the Enforcement folks have about track and trace.

Martin is correct no one is suggesting that there would be blocking without affermative consumer/enterprise consent. No one is suggesting that existing protections for anonymous calls or Alternative Calling Party Display would be comprimised. The hope is eventually to bring the consumer/enterprise more affirmatively into the call acceptance loop. Which is why I keep asking questions on what Headers could we use to have the terminating UAS signal the UE about data this whole process might generate and let our friends in 3GPP get involved as well.  

Some of us really don’t want to go through the hassle of endless arguments about new SIP Headers if it can be reasonably avoided. This ART Class the IESG put in place is a fustercluck as it is and we don’t need to go into the obvious problem of IETF process at this point. 

Its one thing to have a totally closed loop silo like Skype which is fine but that should not be the ultimate goal. You can say what you want about the PSTN but the global any to any model using E 164 still works and still has an enormous value proposition for TSP's.  For better or worse it still underpins the economic structure of the Internet itself.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Oct 2015 03:04:52 +0000

Since the carriers have ultimate control of the number, there's a somewhat simpler approach than delegation:

The carrier listed for the number (i.e., the OCN) gets the certificate signing request (CSR) for the number from the end customer and passes the cert down to the customer if they agree with the request. After all, the customer will already have a trust relationship with the carrier (i.e., login credentials). Separate private key, separate revocation, etc. No need for the carrier to operate a CA or create certificates, but the carrier can just ask the mythical signing LNPA-or-whatever to revoke the customer cert, e.g., when the customer gets ported or doesn't pay their bill. Other carriers just see the "usual" cert ("Number X has been assigned to the entity presenting this cert.").

Clearly, the classical chaining approach works (and has some advantages), but there may be alternatives that are simpler to implement and may avoid the "customer relationship leakage" problem, i.e., revealing to third parties who is customer of whom.

Henning

________________________________________
From: stir <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Sunday, October 18, 2015 12:44 PM
To: [email-masked]
Subject: Re: [stir] OK I'll change the thread to. That which should not be spoken of in polite company, in other words credentials.

        Thanks,
        Paul

---

From: Eric Burger <[email-masked]>
Date: Mon, 26 Oct 2015 20:09:51 -0400

Am I blue in the face yet? I’ll say it again: delegation is a Red Herring™.

All one needs to know is if this call turns out to be evil, I know who to serve (as in the legal process, not IETF server).

It does us NO PRACTICAL GOOD to have a nicely engineered, convoluted, infinitely extensible, handles all corner cases certificate delegation model. The bad guys will get a nice, sweet, signed certificate that will pass at the UAS. Then, you have to walk up the certificate chain to find the carrier that will be able to track down the bad guy. In other words, the carrier certificate in the first place. Otherwise, we are specifying a lot of code that does nothing in the real world.

Being able to point to the carrier that accepted the call and that can point to the miscreant is all we need to do to mitigate SPIT, SWATting, Robocalling, etc.

All having a complex certificate delegation system does is ensure we will add a few YEARS to the deployment timeline. While some people might like that, the populace will be coming at us with pitchforks if we do not build something practical, deployable, does something to mitigate the social problem, and gets deployed.

> On Oct 18, 2015, at 11:04 PM, Henning Schulzrinne <[email-masked]> wrote:
>