Re: [stir] OOB for Service Providers

Well, the draft today sketches a couple of ways that CPS discovery might happen, which in the short term could be just bilateral agreements. Indeed, if we’re willing to assume a monolithic CPS serving a particular closed service provider community, you could easily solve this with a flat file. That might prove the easiest way to get something like this started.

A mature architecture would need some more universal CPS discovery mechanism. This is indeed analogous to the call routing problem: industry databases exist today that let you looking up the OCN’s associated with called numbers, so even if the CPS advertisement is signed with an OCN cert, that might actually be sufficient for relying parties with access to those databases. The extent that we expect relying parties to look behind the OCNs at individual numbers is still controversial in some circles, but at the end of the day, I think we need to get there one way or another.

For example, an RFC8226 certificate can hold a URL pointing to a by-reference list of telephone numbers associated with the certificate (which may indeed be nothing but a shim layer in front of the aforementioned databases), and at the time of certification, such a by-reference list could be added, which could allow a calling party to figure out if CPS advertisements are legitimate or not. So we have a couple ways to do this that may have some promise. What will work for a given environment may vary. For an IETF spec anyway – even one headed for standards track - I think we may want to enumerate approaches, some of which are mandatory-to-implement, but leave it to deployment profiles to narrow in on particular solutions.

Jon Peterson
Neustar, Inc.

From: Jonathan Rosenberg <jdrosen@jdrosen.net>
Date: Saturday, March 14, 2020 at 11:37 AM
To: "Peterson, Jon" <jon.peterson@team.neustar>
Cc: "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] OOB for Service Providers

Thanks Jon - very interesting concept.

In order for this to work, a call originator needs to figure out which carrier's CPS to send the passport to, for a given dialed number. The draft proposes that this info can be obtained from the TNAuthList in the carriers certificate used to sign the cps advertisement. This presumes that terminating carriers are willing to actually enumerate the set of TNs they own in a certificate, and make this available to enterprises, contact centers or other entities which are going to place calls to those numbers.

I think the jury is still out on whether these certs will end up containing actual numbers and prefixes, as opposed to OCNs. Classic inbound STIR and OOB can work without number lists, whereas this draft requires the TN list in order to facilitate routing (i.e., identifying the terminating cps).

So - I think the key question is whether this routing is going to be feasible in practice or not.

Thx,
Jonathan R.

On Fri, Mar 13, 2020 at 5:04 PM Peterson, Jon <jon.peterson=40team.neustar@dmarc.ietf.org<mailto:40team.neustar@dmarc.ietf.org>> wrote:
So we'll all be sad not to meet in Vancouver this time, but given that we're scheduling a virtual meeting, I did want to give a pointer to a new draft:

https://tools.ietf.org/html/draft-peterson-stir-servprovider-oob-00<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-peterson-stir-servprovider-oob-00__;!!N14HnBHF!vycse32NSVgY87Yd4_4liS413HMx-_Y1pOERQmzLoYDyvuZTsVrmbxuMlPQwOxbZLfCnog$>

This draft works toward a more concrete protocol implementation of out-of-band STIR, for the case where a service provider (could be a carrier, large enterprise, or an OTT service) advertises a CPS that collects PASSporTs for calls that would terminate on its network. Because it is tightly coupled to the terminating side of the call, this flavor of CPS has a different security posture than a public CPS that is necessarily decoupled from call signaling entirely.

I know there is some talk out there about "OOB SHAKEN" these days, and to be clear, this is not an "OOB SHAKEN" draft - this looks at general tools that might ultimately support efforts to deliver SHAKEN out-of-band, but it does not limit its consideration of the problem space to the way that SHAKEN currently handles certification and signing. The plan is to deliver a mechanism that is applicable to a variety of potential policies in that regard.

If folks here are interested in working on this, let's discuss it a bit, and maybe find some agenda time for it.

Jon Peterson
Neustar, Inc.

_______________________________________________
stir mailing list
stir@ietf.org<mailto:stir@ietf.org>
https://www.ietf.org/mailman/listinfo/stir<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!vycse32NSVgY87Yd4_4liS413HMx-_Y1pOERQmzLoYDyvuZTsVrmbxuMlPQwOxbVIpJxmQ$>

--
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net<mailto:jdrosen@jdrosen.net>
http://www.jdrosen.net<https://urldefense.com/v3/__http:/www.jdrosen.net__;!!N14HnBHF!vycse32NSVgY87Yd4_4liS413HMx-_Y1pOERQmzLoYDyvuZTsVrmbxuMlPQwOxbMEtLRUQ$>