Subject: Re: [stir] Application servers - Re: Call Center Implications

From: Dan York <[email-masked]>
Date: Fri, 1 Nov 2013 22:07:34 +0000

Brian,

On 10/30/13 3:21 PM, "Brian Rosen" <[email-masked]> wrote:

>We have a separate list for caller name (cnit).

Ah, cool! I missed the notice back in late August that this list was
created.

>I don¹t see any difference between these authorized users of a TN and a
>BPO.  The customer can get a credential authorized by the service
>provider who delegated the TN to him.  The customer can then ³delegate²
>the BPO or the mass calling service provider to use that number on its
>behalf.  There is no difference from our point of view why the authorized
>entity is placing the call, what kind of service it offers, or how many
>calls it places.  If it¹s authorized by the subscriber to use the TN,
>then the contractor can use the TN and sign for it.

Agreed.  At the highest level, it's fundamentally the same problem we're
trying to solve. My main point in raising it was that some of these
services may be very automated - even to the point of being entirely
self-service.  Again, it's not really any different from a huge call
center at a conceptual level.

Dan

---

From: Brian Rosen <[email-masked]>
Date: Fri, 1 Nov 2013 18:22:24 -0400

Look at this case from two points of view.

The one we’re concerned about here in stir right now is the call chain.

I think the only thing that matters is that there can be multiple credentials per number, including in this case, the service provider who provides the actual TN service (who would handle a return call to the TN), its subscriber (the enterprise), and the automated special service provider you are concerned about.  They all have different credentials, any of which can be used to sign for an outgoing call.  If the mass call out processor has the credential, it can make calls, even if they don’t come from the same service provider that serves the subscriber.  That’s good.  

Verifying has to be able to deal with this multiple credential per number dealie.  I’ll note that if the TN came through a reseller path, there might be 6 or 7, or even more, authorized entities who can sign.  That leads us towards some way to select the right credential that appears in the signaling.  A query by TN to a database (regardless of protocol) would have to return each of the credentials and the verifier would have to try them sequentially unless it knew by something in the signaling which was the right one.  The notion of sending a URI to the credential fixes this, but there are other ways.

Now, this also means we need a highly automated way for these delegations to be instantiated, so your automated self-service entity can get the credential it needs without a human in the path.  I think that means that the upwind delegator has to have an automated interface to create the delegation, and the delegate has to have an automated interface to create or retrieve the credential.

I have a bunch of thoughts on that, but I think we need to get the call chain stuff completely worked out before we start worrying about the provisioning aspects.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Nov 2013 15:33:28 -0700

> I have a bunch of thoughts on that, but I think we need to get the call chain stuff completely worked out before we start worrying about the provisioning aspects.

It occurs to me that this delegation may present different issues for 
cnit than it does for stir. When somebody acquires a number, there might 
be multiple names that they should be allowed to use with it. And when 
delegating, they might not want to delegate the right to use all of 
those names.

I mention it here because it might mean that stir and cnit have 
different delegation needs. But if cnit wants to ride on stir's 
delegation coat tails, it will have to be considered from the start.

	Thanks,
	Paul

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

---

From: Brian Rosen <[email-masked]>
Date: Fri, 1 Nov 2013 20:19:43 -0400

Yeah, could be.  We ought to at least be thinking about it.

Maybe a delegation can limit what name can be used.

Brian

On Nov 1, 2013, at 6:33 PM, Paul Kyzivat <[email-masked]> wrote:

> It occurs to me that this delegation may present different issues for cnit than it does for stir. When somebody acquires a number, there might be multiple names that they should be allowed to use with it. And when delegating, they might not want to delegate the right to use all of those names.
> 
> I mention it here because it might mean that stir and cnit have different delegation needs. But if cnit wants to ride on stir's delegation coat tails, it will have to be considered from the start.
> 
> 	Thanks,
> 	Paul
> 
>> Brian
>>

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 2 Nov 2013 17:46:16 -0400

I have to admit all of this discussion increasingly makes me uncomfortable.

Complexity is the enemy of deployability and security. 

That is BTW the core problem some of us see in the PREPASS discussion. 

“We have met the enemy and it is us.”

Validation of the Caller ID number and maybe possibly the Verbose Calling
Party data [CNAM+] better be pretty simple.  The chain of authority IMHO is
still derived at the first order from the Carrier of Record.  We can debate
the rest.  

I make no pretentions to being a Security expert.  One of our Co-Chairs is.
What I have not been able to see over some serious searching is the real
story about PKI. What are its successes and failures?  DANE vs DKIM vs WEB
PKI whatever. What do we say to NRA’s?  Well this might work this might not
.  

Now we start playing the game of Economics.  President Truman was quoted.  

“GIVE me a one-handed economist,” demanded a frustrated American president.
“All my economists say, ‘on the one hand...on the other'”. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Friday, November 01, 2013 8:20 PM
To: Paul Kyzivat
Cc: [email-masked] List
Subject: Re: [stir] Application servers - Re: Call Center Implications

Brian

On Nov 1, 2013, at 6:33 PM, Paul Kyzivat <[email-masked]
<mailto:[email-masked]> > wrote:

I think the only thing that matters is that there can be multiple
credentials per number, including in this case, the service provider who
provides the actual TN service (who would handle a return call to the TN),
its subscriber (the enterprise), and the automated special service provider
you are concerned about.  They all have different credentials, any of which
can be used to sign for an outgoing call.  If the mass call out processor
has the credential, it can make calls, even if they don’t come from the same
service provider that serves the subscriber. That’s good.

Verifying has to be able to deal with this multiple credential per number
dealie.  I’ll note that if the TN came through a reseller path, there might
be 6 or 7, or even more, authorized entities who can sign.  That leads us
towards some way to select the right credential that appears in the
signaling.  A query by TN to a database (regardless of protocol) would have
to return each of the credentials and the verifier would have to try them
sequentially unless it knew by something in the signaling which was the
right one.  The notion of sending a URI to the credential fixes this, but
there are other ways.

Now, this also means we need a highly automated way for these delegations to
be instantiated, so your automated self-service entity can get the
credential it needs without a human in the path.  I think that means that
the upwind delegator has to have an automated interface to create the
delegation, and the delegate has to have an automated interface to create or
retrieve the credential.

I have a bunch of thoughts on that, but I think we need to get the call
chain stuff completely worked out before we start worrying about the
provisioning aspects.

It occurs to me that this delegation may present different issues for cnit
than it does for stir. When somebody acquires a number, there might be
multiple names that they should be allowed to use with it. And when
delegating, they might not want to delegate the right to use all of those
names.

I mention it here because it might mean that stir and cnit have different
delegation needs. But if cnit wants to ride on stir's delegation coat tails,
it will have to be considered from the start.

               Thanks,
               Paul

Brian

On Nov 1, 2013, at 6:07 PM, Dan York <[email-masked] <mailto:[email-masked]> >
wrote:

Brian,

On 10/30/13 3:21 PM, "Brian Rosen" <[email-masked]
<mailto:[email-masked]> > wrote:

Dan

_______________________________________________
stir mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/stir