Subject: Re: [stir] draft-peterson-stir-threats-00.txt

From: "Fernando Mousinho (fmousinh)" <[email-masked]>
Date: Tue, 5 Nov 2013 22:34:14 +0000

I would suggest we add a new attack type to section 3. More and more companies are using the caller ID for account validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my home phone number, I’m informed that I don’t need to provide any further identification because my number is on file. Some (all?) companies that implement this type of validation rely on SS7 today.

Ultimately, this is yet another variation of impersonation – but in this case, the “victim” is a business, unlike the other two scenarios we’ve listed so far.

Addressing this scenario would actually turn STIR into a feature, given it would enable contact centers of all sizes to eliminate the need for caller identification from known TNs.

From: Alex Bobotek <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 1, 2013 at 12:51 PM
To: Brian Rosen <[email-masked]<mailto:[email-masked]>>, "Peterson, Jon" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Richard Shockey <[email-masked]<mailto:[email-masked]>>, "'DOLLY, MARTIN C'" <[email-masked]<mailto:[email-masked]>>, 'Robert Sparks' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Jon,

Thanks for the response.  The intention in #1 below is to clarify the following sentence:

The primary attack vector is

   therefore one where the attacker contrives for the calling telephone

   number in signaling to be a particular chosen number, one that the

   attacker does not have the authority to call from, in order for that

   number to be rendered on the terminating side.

This might be misconstrued as indicating that the objective of spoofing is simply the rendering of a spoofed number on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information.  No issues with leaving this as it’s a valid point.  Another (increasing) motivation is to evade network and/or endpoint defenses that may block based on CPN.

So however it’s worded, I think it’s important to allow for both attack objectives of a spoofed presentation at the endpoint and in transit.

Regards,

Alex

> -----Original Message-----

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of

> Brian Rosen

> Sent: Tuesday, October 01, 2013 9:29 AM

> To: Peterson, Jon

> Cc: [email-masked]<mailto:[email-masked]>; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard

> Shockey

> Subject: Re: [stir] draft-peterson-stir-threats-00.txt

> Don't think there is much MESSAGE.  MSRP is about all we see, and XMPP is

> more likely than that.

> Brian

> On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <[email-masked]<mailto:[email-masked]>>

> wrote:

> > Thanks for these notes, Alex. Some responses below.

> >> Here are several comments that should feed into the IETF Peterson draft:

> >> *   Remove any assumptions that the solution cannot be in-network

> [IMO,

> >> both endpoint and in-network solutions should be facilitated]

> > Agreed that both in-band and out-of-band solutions can usually be

> > implemented in either endpoints or in intermediaries of various kinds.

> > If I see text that implies otherwise, I'll certainly change it.

> >> *   Add a sessionless attack scenario.  A spam payload may be carried in

> a

> >> SIP INVITE or MESSAGE, which might contain stock market advice even

> >> in a display name field.  These attacks do NOT require session

> establishment.

> >> More generally, we should be mindful of the fact that SIP is used in

> >> telephony form more than voice session setup.

> > Probably if we were going to include a sessionless attack scenario, it

> > would be with regular text messages (whether carried on the PSTN over

> > TCAP or with some Internet protocol, including MESSAGE) rather than

> > with an INVITE, which typically wouldn't result in a payload being

> > immediately rendered to a user. More on this below with your suggested

> text.

> >> Here's some suggested markup:

> >> 1.    Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with:

> >> The primary attack vector is

> >>  therefore one where the attacker contrives for the calling telephone

> >> number in signaling to be a particular chosen number that the

> >> attacker does not have the authority to call from.

> > What you want here is to remove the implication that the number will

> > be rendered on the terminating side? While there are some attacks

> > where that isn't significant, perhaps, I would say it is significant

> > in the primary attack vectors that concern us.

> >> 2.  Replace 3rd paragraph of 2.1 Endpoints with:

> >>     Smart devices are generally based on computers with some degree

> >> of programmability, the capacity to access the Internet, and

> >> capabilities of rendering text, audio and/or images.  This includes

> >> smart phones, telephone applications on desktop and laptop computers,

> >> IP private branch exchanges, and so on.

> > I can add the notion that smart devices can render text, audio and/or

> > images as you suggest.

> >> 3.  Add to 3.3 Attack Scenarios:

> >>       Impersonation, IP-Mobile Text Message

> >>        An attacker with an computer sends a high volume of SIP MESSAGE

> >> spam message to IP-enabled smart phones using randomized calling

> >> party numbers.

> >>       Countermeasure: in-band authenticated identity

> > Provided we're talking about end-to-end SIP use of MESSAGE, agreed

> > that in-band would be the right countermeasure. I am curious though

> > whether practically speaking there is enough use of MESSAGE in this

> > fashion that we're actually seeing high-volume spam over MESSAGE

> > today. Either way, no problem having an attack scenario of this form in the

> document.

> > Jon Peterson

> > Neustar, Inc.

> >> Regards,

> >> Alex

> >>> -----Original Message-----

> >>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

> >>> Of Richard Shockey

> >>> Sent: Monday, September 30, 2013 1:11 PM

> >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks'

> >>> Cc: [email-masked]<mailto:[email-masked]>

> >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt

> >>> +1

> >>> -----Original Message-----

> >>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

> >>> Of DOLLY, MARTIN C

> >>> Sent: Monday, September 30, 2013 12:58 PM

> >>> To: Robert Sparks

> >>> Cc: [email-masked]<mailto:[email-masked]>

> >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt

> >>> Yes, ok

> >>> Martin Dolly

> >>> Lead Member of Technical Staff

> >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network

> >>> Technology

> >>> +1-609-903-3360

> >>> [email-masked]<mailto:[email-masked]>

> >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks"

> >>>> <[email-masked]<mailto:[email-masked]>>

> >>> wrote:

> >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote:

> >>>>> With Hadriel comments incorporated, it is a start

> >>>> Hi Martin -

> >>>> Just to make sure - I think you're referring to Hadriel's comments

> >>>> on the

> >>> problem statement document?

> >>>> I don't think Hadriel's commented directly on stir-threats yet.

> >>>> In any case, we _are_ talking about a starting place, not a

> >>>> finished

> >>> product.

> >>>> If there's no other objection, I'd like to get Jon to submit the

> >>>> threats

> >>> document as a WG -00 as soon as it's convenient.

> >>>> RjS

> >>>>> -----Original Message-----

> >>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On

> >>>>> Behalf Of Russ Housley

> >>>>> Sent: Thursday, September 26, 2013 4:37 PM

> >>>>> To: IETF STIR Mail List

> >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt

> >>>>> It has been six days, I'd like to hear from more people about this

> >>> document.  Martin asked for an additional week, so I'm sure we will

> >>> hear from him soon.

> >>>>> Russ

> >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote:

> >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt

> >>>>>> Should the working group adopt this I-D as the starting point for

> >>>>>> the

> >>> STIR threat docuent?

> >>>>>> Russ

> >>>>> _______________________________________________

> >>>>> 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

> >>> _______________________________________________

> >>> 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

> >> _______________________________________________

> >> 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

> _______________________________________________

> stir mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/stir

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Tue, 5 Nov 2013 23:05:05 +0000

I agree with your characterization of businesses as victim of caller ID fraud however contact centers also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the call center.  So I don't agree that STIR would "eliminate the need for caller identification from known TNs."

But perhaps I misunderstood your last sentence?

From: Fernando Mousinho (fmousinh) [mailto:[email-masked]]
Sent: November 05, 2013 4:34 PM
To: [email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

I would suggest we add a new attack type to section 3. More and more companies are using the caller ID for account validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my home phone number, I'm informed that I don't need to provide any further identification because my number is on file. Some (all?) companies that implement this type of validation rely on SS7 today.

Ultimately, this is yet another variation of impersonation - but in this case, the "victim" is a business, unlike the other two scenarios we've listed so far.

Jon,

This might be misconstrued as indicating that the objective of spoofing is simply the rendering of a spoofed number on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information.  No issues with leaving this as it's a valid point.  Another (increasing) motivation is to evade network and/or endpoint defenses that may block based on CPN.

So however it's worded, I think it's important to allow for both attack objectives of a spoofed presentation at the endpoint and in transit.

Regards,

Alex

> https://www.ietf.org/mailman/listinfo/stir

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: "Fernando Mousinho (fmousinh)" <[email-masked]>
Date: Tue, 5 Nov 2013 23:25:57 +0000

Let me rephrase it… it may eliminate the need for other forms of caller identification beyond what STIR will provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to be unblocked by an IVR (and as I said earlier, many companies do it today). In other use cases, the TN alone is not sufficient information – my health care provider will want to know which member of the family is calling.

I agree that ANI is already broadly used to improve customer service today. However, it is not usually deemed as a secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things like SS7. STIR would make this type of validation available to a broader number of companies.

Going on a tangent… perhaps this is out of scope, but there is not a lot of discussion about called party hijacking. Couldn’t a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it’s really them before carrying a conversation, but wouldn’t they want the same?

From: <Gorman>, "Pierce A [NTK]" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 5, 2013 at 6:05 PM
To: Fernando Mousinho <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

I agree with your characterization of businesses as victim of caller ID fraud however contact centers also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the call center.  So I don’t agree that STIR would “eliminate the need for caller identification from known TNs.”

From: Fernando Mousinho (fmousinh) [mailto:[email-masked]]
Sent: November 05, 2013 4:34 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Jon,

Regards,

Alex

---

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

I agree with Pierce here and respectfully disagree that STIR might eliminate
the need for other forms of caller identification.  Though your use case of
credit card validation is a useful one and you are right there are still
applications that use SS7 for things that have nothing to do with call
setup. I agree with you STIR may have more applications beyond the obvious
ones of realtime session validation. 

It's been my experience recently that there is a use case for something MORE
in the identification of the session as it is presented to the called party.
This is the CNAM + idea we are kicking around on the CNIT list.

cnit mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/cnit

But your use case of a bank wanting to make sure they could properly
identify themselves to the consumer before establishing a conversation is
exactly what this process is about.  STIR is essential but it's a
multi-faceted problem that may require multi-faceted solutions.. and
enhanced CNAM + being only one of them.   Its not unreasonable to discuss
those. 

The obviously analogy is I would want to see some real identification of a
utility worker before I let them into my house to make repairs.  I would
want some validation that the call to me to reconfirm the appointments was
in fact from the utility in question. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fernando Mousinho (fmousinh)
Sent: Tuesday, November 05, 2013 6:26 PM
To: Gorman, Pierce A [NTK]; [email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Let me rephrase it. it may eliminate the need for other forms of caller
identification beyond what STIR will provide, depending on the specific use
case. For example, a credit card company may choose to rely entirely on STIR
before allowing a card to be unblocked by an IVR (and as I said earlier,
many companies do it today). In other use cases, the TN alone is not
sufficient information - my health care provider will want to know which
member of the family is calling.

I agree that ANI is already broadly used to improve customer service today.
However, it is not usually deemed as a secure enough mechanism to validate
the caller (therefore this WG!), except if you are a large organization that
can leverage things like SS7. STIR would make this type of validation
available to a broader number of companies.

Going on a tangent. perhaps this is out of scope, but there is not a lot of
discussion about called party hijacking. Couldn't a man-in-the-middle try to
answer calls on my behalf? If my bank is calling me, I want to make sure
it's really them before carrying a conversation, but wouldn't they want the
same? 

From: <Gorman>, "Pierce A [NTK]" <[email-masked]
<mailto:[email-masked]> >
Date: Tuesday, November 5, 2013 at 6:05 PM
To: Fernando Mousinho <[email-masked] <mailto:[email-masked]> >,
"[email-masked] <mailto:[email-masked]> " <[email-masked]>
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

I agree with your characterization of businesses as victim of caller ID
fraud however contact centers also use TN as a key to improve information
available to call agents to reduce average time-per-call and increase
capacity of the call center.  So I don't agree that STIR would "eliminate
the need for caller identification from known TNs."

 

From: Fernando Mousinho (fmousinh) [mailto:[email-masked]] 
Sent: November 05, 2013 4:34 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

I would suggest we add a new attack type to section 3. More and more
companies are using the caller ID for account validation. For example, if I
call my credit card provider from my office number, they ask me for
identification. If I call from my home phone number, I'm informed that I
don't need to provide any further identification because my number is on
file. Some (all?) companies that implement this type of validation rely on
SS7 today.

Ultimately, this is yet another variation of impersonation - but in this
case, the "victim" is a business, unlike the other two scenarios we've
listed so far.

Addressing this scenario would actually turn STIR into a feature, given it
would enable contact centers of all sizes to eliminate the need for caller
identification from known TNs.

From: Alex Bobotek <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, October 1, 2013 at 12:51 PM
To: Brian Rosen <[email-masked] <mailto:[email-masked]> >, "Peterson,
Jon" <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >, Richard Shockey <[email-masked]
<mailto:[email-masked]> >, "'DOLLY, MARTIN C'" <[email-masked]
<mailto:[email-masked]> >, 'Robert Sparks' <[email-masked]
<mailto:[email-masked]> >
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Jon,

Thanks for the response.  The intention in #1 below is to clarify the
following sentence:

This might be misconstrued as indicating that the objective of spoofing is
simply the rendering of a spoofed number on the receiving display, causing
mistaken conclusions that defenses might be limited to securing the rendered
information.  No issues with leaving this as it's a valid point.  Another
(increasing) motivation is to evade network and/or endpoint defenses that
may block based on CPN.  

So however it's worded, I think it's important to allow for both attack
objectives of a spoofed presentation at the endpoint and in transit.   

Regards,

Alex

> From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of

> Cc: [email-masked] <mailto:[email-masked]> ; Alex Bobotek; 'Robert Sparks';
'DOLLY, MARTIN C'; Richard

> On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <
<mailto:[email-masked]> [email-masked]>

> >>> From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf

> >>> Cc:  <mailto:[email-masked]> [email-masked]

> >>> From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf

> >>> Cc:  <mailto:[email-masked]> [email-masked]

> >>>  <mailto:[email-masked]> [email-masked]

> >>>> < <mailto:[email-masked]> [email-masked]>

> >>>>> From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On

> >>>>>>  <http://www.ietf.org/id/draft-peterson-stir-threats-00.txt>

> >>>>>  <mailto:[email-masked]> [email-masked]

> >>>>>  <https://www.ietf.org/mailman/listinfo/stir>

> >>>>  <mailto:[email-masked]> [email-masked]

> >>>>  <https://www.ietf.org/mailman/listinfo/stir>

> >>>  <mailto:[email-masked]> [email-masked]

> >>>  <https://www.ietf.org/mailman/listinfo/stir>

> >>>  <mailto:[email-masked]> [email-masked]

> >>>  <https://www.ietf.org/mailman/listinfo/stir>

> >>  <mailto:[email-masked]> [email-masked]

> >>  <https://www.ietf.org/mailman/listinfo/stir>

> >  <mailto:[email-masked]> [email-masked]

> >  <https://www.ietf.org/mailman/listinfo/stir>

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/stir>

  _____  

This e-mail may contain Sprint proprietary information intended for the sole
use of the recipient(s). Any use by others is prohibited. If you are not the
intended recipient, please contact the sender and delete all copies of the
message.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Nov 2013 12:40:58 -0800

We’ve considered adding some information that is not number and is not name, but is something like “bank”, which might have some sort of validation behind it.

Is that along the lines you were thinking?

Brian
On Nov 6, 2013, at 5:25 AM, Richard Shockey <[email-masked]> wrote:

> I agree with Pierce here and respectfully disagree that STIR might eliminate the need for other forms of caller identification.  Though your use case of credit card validation is a useful one and you are right there are still applications that use SS7 for things that have nothing to do with call setup. I agree with you STIR may have more applications beyond the obvious ones of realtime session validation.
>  
> It’s been my experience recently that there is a use case for something MORE in the identification of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list.
>  
> But your use case of a bank wanting to make sure they could properly identify themselves to the consumer before establishing a conversation is exactly what this process is about.  STIR is essential but it’s a multi-faceted problem that may require multi-faceted solutions.. and enhanced CNAM + being only one of them.   Its not unreasonable to discuss those.
>  
> The obviously analogy is I would want to see some real identification of a utility worker before I let them into my house to make repairs.  I would want some validation that the call to me to reconfirm the appointments was in fact from the utility in question.
>  
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Fernando Mousinho (fmousinh)
> From: <Gorman>, "Pierce A [NTK]" <[email-masked]>
> To: Fernando Mousinho <[email-masked]>, "[email-masked]" <[email-masked]>
> From: Alex Bobotek <[email-masked]>
> To: Brian Rosen <[email-masked]>, "Peterson, Jon" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Richard Shockey <[email-masked]>, "'DOLLY, MARTIN C'" <[email-masked]>, 'Robert Sparks' <[email-masked]>
> > Cc: [email-masked]; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard
> > Shockey
> > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <[email-masked]>
> > wrote:
> >
> > >>> From: [email-masked] [mailto:[email-masked]] On Behalf
> > >>> Of Richard Shockey
> > >>> Cc: [email-masked]
> > >>> From: [email-masked] [mailto:[email-masked]] On Behalf
> > >>> Of DOLLY, MARTIN C
> > >>> Cc: [email-masked]
> > >>> [email-masked]
> > >>>> <[email-masked]>
> > >>>>> From: [email-masked] [mailto:[email-masked]] On
> > >>>>> Behalf Of Russ Housley
> > >>>>> [email-masked]
> > >>>> [email-masked]
> > >>> [email-masked]
> > >>> [email-masked]
> > >> [email-masked]
> > > [email-masked]
> > [email-masked]
> [email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 6 Nov 2013 16:10:55 -0500

URI for a JCARD in the CALL INFO header provisioned by the calling party and
ultimately signed by the responsible entity.  The carrier could provision
this for their mobile or hosted customers.  Enterprises could do this
themselves.  This also has advantages in Enterprise to Enterprise UC as well
where the data is derived from the Enterprise "directory" and could
facilitate end to end PPX to PBX communications especially in point to point
video communications. 

There are certainly privacy and security issues to be addressed.  The Push
vs Pull model.  This really would be PII in the clear but then its done
voluntarily. 

There would have to be some work around restructuring the Header and adding
some parameters but it's underutilized right now and this Use Case is a
perfectly appropriate use. 

https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06

Obviously it would need to be signed but we don't need to worry about that
..yet. 

>From 3261 

20.9 Call-Info

   The Call-Info header field provides additional information about the

   caller or callee, depending on whether it is found in a request or

   response.  The purpose of the URI is described by the "purpose"

   parameter.  The "icon" parameter designates an image suitable as an

   iconic representation of the caller or callee.  The "info" parameter

   describes the caller or callee in general, for example, through a web

   page.  The "card" parameter provides a business card, for example, in

   vCard [36] or LDIF [37] formats.  Additional tokens can be registered

   using IANA and the procedures in Section 27.

   Use of the Call-Info header field can pose a security risk.  If a

   callee fetches the URIs provided by a malicious caller, the callee

   may be at risk for displaying inappropriate or offensive content,

   dangerous or illegal content, and so on.  Therefore, it is

   RECOMMENDED that a UA only render the information in the Call-Info

   header field if it can verify the authenticity of the element that

   originated the header field and trusts that element.  This need not

   be the peer UA; a proxy can insert this header field into requests.

   Example:

   Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,

     <http://www.example.com/alice/> ;purpose=info

From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, November 06, 2013 3:41 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; [email-masked] List
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

We've considered adding some information that is not number and is not name,
but is something like "bank", which might have some sort of validation
behind it.

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey <[email-masked]
<mailto:[email-masked]> > wrote:

cnit mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/cnit>
https://www.ietf.org/mailman/listinfo/cnit

 

From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Fernando Mousinho (fmousinh)
Sent: Tuesday, November 05, 2013 6:26 PM
To: Gorman, Pierce A [NTK]; [email-masked] <mailto:[email-masked]> 
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

 

From: <Gorman>, "Pierce A [NTK]" < <mailto:[email-masked]>
[email-masked]>
Date: Tuesday, November 5, 2013 at 6:05 PM
To: Fernando Mousinho < <mailto:[email-masked]> [email-masked]>, "
<mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]>
[email-masked]>
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

 

From: Fernando Mousinho (fmousinh) [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: November 05, 2013 4:34 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

From: Alex Bobotek < <mailto:[email-masked]> [email-masked]>
Date: Tuesday, October 1, 2013 at 12:51 PM
To: Brian Rosen < <mailto:[email-masked]> [email-masked]>, "Peterson,
Jon" < <mailto:[email-masked]> [email-masked]>
Cc: " <mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]>
[email-masked]>, Richard Shockey < <mailto:[email-masked]>
[email-masked]>, "'DOLLY, MARTIN C'" < <mailto:[email-masked]>
[email-masked]>, 'Robert Sparks' < <mailto:[email-masked]>
[email-masked]>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Jon,

Regards,

Alex

> From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf Of

> Cc:  <mailto:[email-masked]> [email-masked]; Alex Bobotek; 'Robert Sparks';

  _____  

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Nov 2013 21:59:09 -0800

I think this would be a heavy lift.

If the responsible entity was a carrier, then it would have to validate the data, which it has very little basis to validate.  It could get a 3rd party to do the validation, but then it’s putting its reputation on the back of some hired hand validator.

If the responsibility is the end user/device, then the signature has no value.

I do not argue that Call-Info is suitable,  it is.

I do question JCARD vs xCard, but that’s an encoding detail.  All of SIP Is XML described by schema, not json.

Brian

On Nov 6, 2013, at 1:10 PM, Richard Shockey <[email-masked]> wrote:

> URI for a JCARD in the CALL INFO header provisioned by the calling party and ultimately signed by the responsible entity.  The carrier could provision this for their mobile or hosted customers.  Enterprises could do this themselves.  This also has advantages in Enterprise to Enterprise UC as well where the data is derived from the Enterprise “directory” and could facilitate end to end PPX to PBX communications especially in point to point video communications.
>  
> There are certainly privacy and security issues to be addressed.  The Push vs Pull model.  This really would be PII in the clear but then its done voluntarily.
>  
> There would have to be some work around restructuring the Header and adding some parameters but it’s underutilized right now and this Use Case is a perfectly appropriate use.
>  
> Obviously it would need to be signed but we don’t need to worry about that ..yet.
>  
> From 3261
>  
> 20.9 Call-Info
>

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Thu, 7 Nov 2013 14:53:38 +0000

I'll admit I am not familiar with v/x/jcard encoding differences or the implications of their use so I'll encourage educating me if it isn't too onerous.

I'm not sure what is the concern with a 3rd party providing "validation" though.  There are numerous examples of 3rd parties providing validation of information including NASDAQ, NYSE, Barron's, Moody's, and the federal reserve banking system to name a few.

Pierce

From: Brian Rosen [mailto:[email-masked]]
Sent: November 06, 2013 11:59 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; [email-masked] List; [email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

If the responsible entity was a carrier, then it would have to validate the data, which it has very little basis to validate.  It could get a 3rd party to do the validation, but then it's putting its reputation on the back of some hired hand validator.

I do question JCARD vs xCard, but that's an encoding detail.  All of SIP Is XML described by schema, not json.

Brian

On Nov 6, 2013, at 1:10 PM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:

URI for a JCARD in the CALL INFO header provisioned by the calling party and ultimately signed by the responsible entity.  The carrier could provision this for their mobile or hosted customers.  Enterprises could do this themselves.  This also has advantages in Enterprise to Enterprise UC as well where the data is derived from the Enterprise "directory" and could facilitate end to end PPX to PBX communications especially in point to point video communications.

There would have to be some work around restructuring the Header and adding some parameters but it's underutilized right now and this Use Case is a perfectly appropriate use.

Obviously it would need to be signed but we don't need to worry about that ..yet.

20.9 Call-Info

   Example:

From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, November 06, 2013 3:41 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; [email-masked]<mailto:[email-masked]> List
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

We've considered adding some information that is not number and is not name, but is something like "bank", which might have some sort of validation behind it.

Brian
On Nov 6, 2013, at 5:25 AM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:

It's been my experience recently that there is a use case for something MORE in the identification of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list.

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

But your use case of a bank wanting to make sure they could properly identify themselves to the consumer before establishing a conversation is exactly what this process is about.  STIR is essential but it's a multi-faceted problem that may require multi-faceted solutions.. and enhanced CNAM + being only one of them.   Its not unreasonable to discuss those.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Fernando Mousinho (fmousinh)
Sent: Tuesday, November 05, 2013 6:26 PM
To: Gorman, Pierce A [NTK]; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Let me rephrase it... it may eliminate the need for other forms of caller identification beyond what STIR will provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to be unblocked by an IVR (and as I said earlier, many companies do it today). In other use cases, the TN alone is not sufficient information - my health care provider will want to know which member of the family is calling.

Going on a tangent... perhaps this is out of scope, but there is not a lot of discussion about called party hijacking. Couldn't a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it's really them before carrying a conversation, but wouldn't they want the same?

Jon,

Regards,

Alex

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Nov 2013 15:00:16 +0000

As a thought experiment, Kumiko Ono and I had published a draft

http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00

to allow third parties to validate property information. If the validating party (e.g., a bank regulator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist's office or, more lowly, to the health departments rating in a restaurant window, and it can be tied to a phone number, this shouldn't be too hard.

It's a bit harder if the certifying authority (regulator, Realtor board, local bar association, ...) is not involved.

Henning

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [NTK]
Sent: Thursday, November 07, 2013 9:54 AM
To: Brian Rosen; Richard Shockey
Cc: [email-masked] List; [email-masked]; Fernando Mousinho (fmousinh)
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

Pierce

From: Brian Rosen [mailto:[email-masked]]
Sent: November 06, 2013 11:59 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; [email-masked]<mailto:[email-masked]> List; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Brian

20.9 Call-Info

   Example:

Brian

Jon,

Regards,

Alex

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 7 Nov 2013 10:16:09 -0500

Like CNAM is so accurate today. ??  When certain companies get the data from
scanning phone books that are not even printed anymore? 

The carrier has the billing relationship. As you well know that is where the
data comes from now but it is not granular.  

The carrier permits the customer to create the record(s). What are you
trying to validate? The Accuracy of the data?  . In any event none of that
is our problem.   We make the tools. Someone else worries about policy.

You are making this way too complicated thus defeating the basic use case.

Well from time to time I've discovered I'm not a big fan of the end to end
principal.  It just doesn't work for every use case.  This is a carrier
service or in certain cases hosted.

Much like I'm convinced the out of band solution in STIR is total fantasy
and like VIPR will almost never actually be used in practice. 

As for encoding I mentioned JCARD since there seems to be a faction in the
IETF that is anti-XML 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Thursday, November 07, 2013 12:59 AM
To: Richard Shockey
Cc: [email-masked] List; Gorman, Pierce A [NTK]; [email-masked]; Fernando
Mousinho (fmousinh)
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

If the responsible entity was a carrier, then it would have to validate the
data, which it has very little basis to validate.  It could get a 3rd party
to do the validation, but then it's putting its reputation on the back of
some hired hand validator.

If the responsibility is the end user/device, then the signature has no
value.

I do question JCARD vs xCard, but that's an encoding detail.  All of SIP Is
XML described by schema, not json.

Brian

On Nov 6, 2013, at 1:10 PM, Richard Shockey <[email-masked]
<mailto:[email-masked]> > wrote:

20.9 Call-Info

   Example:

From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, November 06, 2013 3:41 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; [email-masked]
<mailto:[email-masked]>  List
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Brian

cnit mailing list

 

 

 

 

 

Jon,

Regards,

Alex

  _____

---

From: Michael Hammer <[email-masked]>
Date: Thu, 7 Nov 2013 15:28:28 +0000

So, would you trust a certificate from the City of Reston, Virginia police
department?

(Hint:  you can find Reston on a map, but there is no City of Reston.  

  The only police are Fairfax County.)

My concern is that one you dilute or disperse authority, it becomes a
free-for-all again, and anybody's guess.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Thursday, November 07, 2013 10:00 AM
To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey
Cc: [email-masked] List; Fernando Mousinho (fmousinh); [email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

to allow third parties to validate property information. If the validating
party (e.g., a bank regulator) is willing to sign a certificate, similar in
spirit to the framed gold-leaf diplomas in your dentist's office or, more
lowly, to the health departments rating in a restaurant window, and it can
be tied to a phone number, this shouldn't be too hard.

It's a bit harder if the certifying authority (regulator, Realtor board,
local bar association, .) is not involved.

Henning 

Gorman, Pierce A [NTK]

I'll admit I am not familiar with v/x/jcard encoding differences or the
implications of their use so I'll encourage educating me if it isn't too
onerous.

I'm not sure what is the concern with a 3rd party providing "validation"
though.  There are numerous examples of 3rd parties providing validation of
information including NASDAQ, NYSE, Barron's, Moody's, and the federal
reserve banking system to name a few.

Pierce

List; [email-masked]

Brian

20.9 Call-Info

   Example:

Brian

cnit mailing list

 

 

 

 

 

Jon,

Regards,

Alex

  _____  

 

  _____

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Nov 2013 16:12:50 +0000

Yes, that's a problem, but as long as the number of categories is small, you can build UIs that only render information that's appropriate to the declaration. For practical reasons, I think the number of useful categories is likely going to be fairly limited:

-          Financial institution (FDIC and a few others)

-          Health care (each health care facility has a gov't number)

-          Charity (501c3, state registered)

-          Contractor (state-licensed)

-          Public safety organization (police, fire)

-          Lawyer (bar association)

-          Local, state and federal government (.gov in the US)

I suspect that list encompasses a large fraction of the fraudulent (impersonation) calls. For all of the above, at least within a country, it's pretty clear who can attest to the membership. Yes, this requires some UI work or some server logic, but these categories and the organizations don't change all that often - in most cases, the certifying entities have probably been the same for the past 50+ years. I'm not as worried about figuring out whether the beautician, mortician or florist is licensed and properly identified, although I'm sure we can all come up with potential fraud stories.

From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 10:28 AM
To: Henning Schulzrinne; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

So, would you trust a certificate from the City of Reston, Virginia police department?

My concern is that one you dilute or disperse authority, it becomes a free-for-all again, and anybody's guess.

Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Thursday, November 07, 2013 10:00 AM
To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey
Cc: [email-masked]<mailto:[email-masked]> List; Fernando Mousinho (fmousinh); [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Henning

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Gorman, Pierce A [NTK]
Sent: Thursday, November 07, 2013 9:54 AM
To: Brian Rosen; Richard Shockey
Cc: [email-masked]<mailto:[email-masked]> List; [email-masked]<mailto:[email-masked]>; Fernando Mousinho (fmousinh)
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

Pierce

Brian

20.9 Call-Info

   Example:

Brian

Jon,

Regards,

Alex

---

From: Brian Rosen <[email-masked]>
Date: Thu, 7 Nov 2013 09:03:22 -0800

Right.  I believe we can do this pretty easily.  We probably could have a 100 categories that would have similar authorities, and there are classifications maintained by folks like Dun Bradstreet that can go even farther.

What I think would be substantially harder is to validate an entire V/X/J card.  How is a validator to know your nickname is Fluffy?  Name, phone number and, if a business, a classification, yes, we can do that.  Content of a business card - very hard.

Brian

On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne <[email-masked]> wrote:

> Yes, that’s a problem, but as long as the number of categories is small, you can build UIs that only render information that’s appropriate to the declaration. For practical reasons, I think the number of useful categories is likely going to be fairly limited:
> -          Health care (each health care facility has a gov’t number)
> I suspect that list encompasses a large fraction of the fraudulent (impersonation) calls. For all of the above, at least within a country, it’s pretty clear who can attest to the membership. Yes, this requires some UI work or some server logic, but these categories and the organizations don’t change all that often – in most cases, the certifying entities have probably been the same for the past 50+ years. I’m not as worried about figuring out whether the beautician, mortician or florist is licensed and properly identified, although I’m sure we can all come up with potential fraud stories.
>  
> My concern is that one you dilute or disperse authority, it becomes a free-for-all again, and anybody’s guess.
>  
> Mike
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
> to allow third parties to validate property information. If the validating party (e.g., a bank regulator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist’s office or, more lowly, to the health departments rating in a restaurant window, and it can be tied to a phone number, this shouldn’t be too hard.
>  
> It’s a bit harder if the certifying authority (regulator, Realtor board, local bar association, …) is not involved.
>  
> Henning
>  
> I’ll admit I am not familiar with v/x/jcard encoding differences or the implications of their use so I’ll encourage educating me if it isn’t too onerous.
>  
> I’m not sure what is the concern with a 3rd party providing “validation” though.  There are numerous examples of 3rd parties providing validation of information including NASDAQ, NYSE, Barron’s, Moody’s, and the federal reserve banking system to name a few.
>  
> Pierce
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Nov 2013 17:09:17 +0000

For businesses, the incorporation record contains the address, but that may well be Delaware.

The carrier generally knows the correct service address for landline (and the billing address for most cell calls), for obvious reasons.

I agree that names are hard and should probably be left to the originator in many cases. It's much more helpful if the caller ID says "John Smith, ABC Bank" or "Wire department", even if the carrier has no idea whether that's really John Smith or that particular department calling. (It's helpful to the callee because they may recognize John Smith as their financial advisor, for example.)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, November 07, 2013 12:03 PM
To: Henning Schulzrinne
Cc: [email-masked]; Richard Shockey; [email-masked]; [email-masked]; Michael Hammer; [email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Brian

On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 10:28 AM
To: Henning Schulzrinne; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

Mike

Henning

Pierce

Brian

20.9 Call-Info

   Example:

Brian

Jon,

Regards,

Alex

---

From: Brian Rosen <[email-masked]>
Date: Thu, 7 Nov 2013 09:10:14 -0800

We’re agreeing CNAM doesn’t work, it lies, and we have to fix that.

Billing relationships are useful, but only give you return routability properties.  Not very interesting, and billing addresses aren’t often what is wanted.  Given various corporate relationships that are tolerated by carriers, it would be trivial to make the billing name be anything you wanted it to be and get service from most carriers.  

I think it IS possible to validate a name, as long as you allow a probability of that validation to be carried, because the techniques we have aren’t definitive.  

See prior reply on the category idea, which I think is workable.

FWIW, I am in favor of an in band solution for CNAM - display name of From.

You proposed a VCARD.  I think that is unworkable.  Name is hard enough.  We might be able to get an address.  All the other fields in a VCARD are pretty dicey.

On Nov 7, 2013, at 7:16 AM, Richard Shockey <[email-masked]> wrote:

>  
> Like CNAM is so accurate today… ??  When certain companies get the data from scanning phone books that are not even printed anymore?
>  
> The carrier has the billing relationship. As you well know that is where the data comes from now but it is not granular. 
>  
> The carrier permits the customer to create the record(s). What are you trying to validate? The Accuracy of the data?  … In any event none of that is our problem.   We make the tools. Someone else worries about policy.
>  
> Well from time to time I’ve discovered I’m not a big fan of the end to end principal.  It just doesn’t work for every use case.  This is a carrier service or in certain cases hosted.
>  
> Much like I’m convinced the out of band solution in STIR is total fantasy and like VIPR will almost never actually be used in practice.
>  
> As for encoding I mentioned JCARD since there seems to be a faction in the IETF that is anti-XML
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
> Cc: [email-masked] List; Gorman, Pierce A [NTK]; [email-masked]; Fernando Mousinho (fmousinh)

---

From: Michael Hammer <[email-masked]>
Date: Thu, 7 Nov 2013 17:10:24 +0000

So, how does the average user know who is an authority?

(Note, we are not designing for IETF geniuses here.)

Is some well-known central authority going to certify all of these?

Are each of these going to cross-certify all the others? (federated model)

We need to always answer that fundamental user question:

Why should I TRUST this information?

Mike

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 12:03 PM
To: Henning Schulzrinne
Cc: Michael Hammer; [email-masked]; Richard Shockey;
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Right.  I believe we can do this pretty easily.  We probably could have a
100 categories that would have similar authorities, and there are
classifications maintained by folks like Dun Bradstreet that can go even
farther.

What I think would be substantially harder is to validate an entire V/X/J
card.  How is a validator to know your nickname is Fluffy?  Name, phone
number and, if a business, a classification, yes, we can do that.  Content
of a business card - very hard.

Brian

On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne
<[email-masked]> wrote:

Yes, that's a problem, but as long as the number of categories is small, you
can build UIs that only render information that's appropriate to the
declaration. For practical reasons, I think the number of useful categories
is likely going to be fairly limited:

I suspect that list encompasses a large fraction of the fraudulent
(impersonation) calls. For all of the above, at least within a country, it's
pretty clear who can attest to the membership. Yes, this requires some UI
work or some server logic, but these categories and the organizations don't
change all that often - in most cases, the certifying entities have probably
been the same for the past 50+ years. I'm not as worried about figuring out
whether the beautician, mortician or florist is licensed and properly
identified, although I'm sure we can all come up with potential fraud
stories.

To: Henning Schulzrinne; [email-masked]; [email-masked];
[email-masked]

Mike

From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Thursday, November 07, 2013 10:00 AM
To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey
Cc:  <mailto:[email-masked]> [email-masked] List; Fernando Mousinho
(fmousinh);  <mailto:[email-masked]> [email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 <http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00>
http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00

Henning

From:  <mailto:[email-masked]> [email-masked]
<mailto:[mailto:[email-masked]]> [mailto:[email-masked]] On
Behalf Of Gorman, Pierce A [NTK]
Sent: Thursday, November 07, 2013 9:54 AM
To: Brian Rosen; Richard Shockey
Cc:  <mailto:[email-masked]> [email-masked] List;  <mailto:[email-masked]>
[email-masked]; Fernando Mousinho (fmousinh)
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

Pierce

From: Brian Rosen [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: November 06, 2013 11:59 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK];
<mailto:[email-masked]> [email-masked] List;  <mailto:[email-masked]>
[email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Brian

On Nov 6, 2013, at 1:10 PM, Richard Shockey < <mailto:[email-masked]>
[email-masked]> wrote:

 <https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06>
https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06

20.9 Call-Info

   Example:

   Call-Info: < <http://wwww.example.com/alice/photo.jpg>
http://wwww.example.com/alice/photo.jpg> ;purpose=icon,

     < <http://www.example.com/alice/> http://www.example.com/alice/>
;purpose=info

From: Brian Rosen [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Wednesday, November 06, 2013 3:41 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK];
<mailto:[email-masked]> [email-masked] List
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey < <mailto:[email-masked]>
[email-masked]> wrote:

cnit mailing list

 

To: Gorman, Pierce A [NTK];  <mailto:[email-masked]> [email-masked]

 

 

 

 

Jon,

Regards,

Alex

  _____  

 

  _____

---

From: Brian Rosen <[email-masked]>
Date: Thu, 7 Nov 2013 09:14:48 -0800

Yeah, I think we can work out a central authority in a country to handle it.  Don’t think cross certifying would work.
In the US, we have an agency (Federal Trade Commission) that is intimately familiar with, and very motivated to do something about spoofing of called id information, and could reasonably certify the certifiers.  Similar agencies exist in other countries that are experiencing the problems we are addressing.

Note that ALL you get out of this is the category.  But, like Henning, I think this is a VERY helpful, workable idea.

Brian

On Nov 7, 2013, at 9:10 AM, Michael Hammer <[email-masked]> wrote:

> Cc: Michael Hammer; [email-masked]; Richard Shockey; [email-masked]; [email-masked]; [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Nov 2013 17:15:05 +0000

The user shouldn't and wouldn't - they would trust a third party (often, their carrier, I suspect) to figure out who can attest to the bankiness of a bank. This is not new - there are a number of existing outfits that do this for web sites. (Example: Avast has a bar graph that shows trustworthiness.)

From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 12:10 PM
To: [email-masked]; Henning Schulzrinne
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

Mike

From: Brian Rosen [mailto:[email-masked]]
Sent: Thursday, November 07, 2013 12:03 PM
To: Henning Schulzrinne
Cc: Michael Hammer; [email-masked]<mailto:[email-masked]>; Richard Shockey; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Brian

Mike

Henning

Pierce

Brian

20.9 Call-Info

   Example:

Brian

Jon,

Regards,

Alex

---

From: Michael Hammer <[email-masked]>
Date: Thu, 7 Nov 2013 17:21:07 +0000

Agree, the user may trust the carrier or someone like FTC or FCC.

But, if it goes beyond a small handful, forget it.

Bottom line, the average user needs to know that someone has actually 

gone to the business site and knocked on the door, met the people, 

and seen that it is a real business.

Not, just some fly-by-night operation that logged into some website.

Mike

From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 12:15 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

The user shouldn't and wouldn't - they would trust a third party (often,
their carrier, I suspect) to figure out who can attest to the bankiness of a
bank. This is not new - there are a number of existing outfits that do this
for web sites. (Example: Avast has a bar graph that shows trustworthiness.)

From: Michael Hammer [mailto:[email-masked]] 
Sent: Thursday, November 07, 2013 12:10 PM
To: [email-masked]; Henning Schulzrinne
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

Mike

Brian

Mike

Henning

Pierce

Brian

20.9 Call-Info

   Example:

Brian

cnit mailing list

 

 

 

 

 

Jon,

Regards,

Alex

  _____  

 

  _____

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Thu, 7 Nov 2013 18:39:17 +0000

The issues we keep circling are trust and value.

For practical reasons, carriers are going to continue to want to use CNAM clearinghouse information providers, and consumers are going to continue to want better information.  If the consumes are like me, they're going to be willing to pay a little extra to get better information, or be unwilling to pay but willing to just deal with liars calling.  Nobody is forced to answer or to believe anything they're told if they do answer.

Mechanisms are already in place to support real-time per-call per-subscriber 3rd party telecommunications services.  If KPMG or Prudential started offering information security services for CNAM, I'd pay for it.

IMHO, the focus of STIR and CNIT WGs should be mechanisms which 1) validate that a calling number is authentic (not trustworthy), and 2) provide a carrier or CNAM provider a key for retrieving (potentially untrustworthy)  information that has been associated with that calling number.

Ensuring the trustworthiness of the calling number or the information associated with the calling number should not be the domain of the IETF.

If trustworthiness of information is VALUABLE (and we've described multiple examples of this being so), then the marketplace can determine how the value is to be extracted and applied.

Pierce

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: November 07, 2013 11:21 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Gorman, Pierce A [NTK]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

Mike

Mike

Right.  I believe we can do this pretty easily.  We probably could have a
100 categories that would have similar authorities, and there are classifications maintained by folks like Dun Bradstreet that can go even farther.

Brian

I suspect that list encompasses a large fraction of the fraudulent
(impersonation) calls. For all of the above, at least within a country, it's pretty clear who can attest to the membership. Yes, this requires some UI work or some server logic, but these categories and the organizations don't change all that often - in most cases, the certifying entities have probably been the same for the past 50+ years. I'm not as worried about figuring out whether the beautician, mortician or florist is licensed and properly identified, although I'm sure we can all come up with potential fraud stories.

Mike

From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Thursday, November 07, 2013 10:00 AM
To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey
Cc:  <mailto:[email-masked]> [email-masked] List; Fernando Mousinho (fmousinh);  <mailto:[email-masked]> [email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

It's a bit harder if the certifying authority (regulator, Realtor board, local bar association, .) is not involved.

Henning

From:  <mailto:[email-masked]> [email-masked] <mailto:[mailto:[email-masked]]> [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [NTK]
Sent: Thursday, November 07, 2013 9:54 AM
To: Brian Rosen; Richard Shockey
Cc:  <mailto:[email-masked]> [email-masked] List;  <mailto:[email-masked]> [email-masked]; Fernando Mousinho (fmousinh)
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

I'm not sure what is the concern with a 3rd party providing "validation"
though.  There are numerous examples of 3rd parties providing validation of information including NASDAQ, NYSE, Barron's, Moody's, and the federal reserve banking system to name a few.

Pierce

From: Brian Rosen [ <mailto:[email-masked]> mailto:[email-masked]]
Sent: November 06, 2013 11:59 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; <mailto:[email-masked]> [email-masked] List;  <mailto:[email-masked]> [email-masked]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Brian

On Nov 6, 2013, at 1:10 PM, Richard Shockey < <mailto:[email-masked]> [email-masked]> wrote:

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 7 Nov 2013 18:32:51 -0500

VCARD SCHMEECARD.. whatever. I don't think you want to reinvent the wheel
here but I won't argue about that. 

The issue is defining what set of data from a called party increases the
level of trust in the session establishment process that the consumer
generally would understand and can the network validate that data in a
reasonable manner that does not increase costs or significantly increase
post dial delay.  

Oh ..how would it be displayed . what would Google and Apple need to do to
put the data on the devices?  WebRTC for that matter since IMHO its going to
end up being used as a SIP client quite often. 

And again I think a in band solution will not work and never actually be
used by..sort of like VIPR. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Thursday, November 07, 2013 12:10 PM
To: Richard Shockey
Cc: [email-masked] List; Gorman, Pierce A [NTK]; Fernando Mousinho
(fmousinh); [email-masked]
Subject: Re: [stir] [cnit] draft-peterson-stir-threats-00.txt

We're agreeing CNAM doesn't work, it lies, and we have to fix that.

Billing relationships are useful, but only give you return routability
properties.  Not very interesting, and billing addresses aren't often what
is wanted.  Given various corporate relationships that are tolerated by
carriers, it would be trivial to make the billing name be anything you
wanted it to be and get service from most carriers.  

I think it IS possible to validate a name, as long as you allow a
probability of that validation to be carried, because the techniques we have
aren't definitive.  

You proposed a VCARD.  I think that is unworkable.  Name is hard enough.  We
might be able to get an address.  All the other fields in a VCARD are pretty
dicey.

On Nov 7, 2013, at 7:16 AM, Richard Shockey <[email-masked]
<mailto:[email-masked]> > wrote:

From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, November 07, 2013 12:59 AM
To: Richard Shockey
Cc: [email-masked] <mailto:[email-masked]>  List; Gorman, Pierce A [NTK];
[email-masked] <mailto:[email-masked]> ; Fernando Mousinho (fmousinh)
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

Brian

20.9 Call-Info

   Example:

Brian

cnit mailing list

 

 

 

 

 

Jon,

Regards,

Alex

  _____