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

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

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]
<mailto:[email-masked]> > wrote:

On 11/1/13 3:22 PM, Brian Rosen wrote:

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.

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:

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

_______________________________________________
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

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 6 Nov 2013 08:29:24 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
York
Sent: Thursday, October 31, 2013 8:24 PM
To: Richard Shockey
Cc: [email-masked]; DISPATCH; Brian Rosen
Subject: Re: [cnit] [stir] Application servers - Re: Call Center
Implications

Richard,

> On Oct 31, 2013, at 5:34 PM, "Richard Shockey" <[email-masked]> wrote:
> 
> I am very interested in working on improving caller name.
> 
> [RS> ]  So I'm not completely insane?  :-)  

Welllllll... we can debate that! ;-) But... If you are insane then a number
of us are because I, too, am interested in working on this.

> Ok then it seams the
> conversation is worth having and there is productive work here ..

I will admit that when we started working on STIR, I had it in my head that
when we talking about "secure origin identification" we were talking about
BOTH the phone number and the displayed caller name. I don't think securing
ONLY the phone number fully helps regular users, because the regular person
out there usually looks at (and trusts!) the displayed "Caller ID". 

If we secure the phone number but not the display name, attackers/spammers
are simply going to figure out ways to send a valid phone number but a
confusing display name. Sure, the secured phone number may help track the
attacker down, but in the meantime victims have been fooled into giving up
information. 

[RS> ]  I agree.  We will have to do both eventually.  

So I think we have to look at how we secure both.

> See you in
> London.  

Why London? Are you not in Vancouver? Or were you just saying this is
post-Vancouver work?

[RS> ]  Obviously not enough time to organize a Goals and Requirements or a
draft charter etc.  I'm not in Vancouver. Its something to properly organize
and present in London. 

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