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

[Michael Hammer <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, November 07, 2013 12:15 PM
To: Michael Hammer; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
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:[e-mail]] 
Sent: Thursday, November 07, 2013 12:10 PM
To: [e-mail]; Henning Schulzrinne
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

 

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:[e-mail]] 
Sent: Thursday, November 07, 2013 12:03 PM
To: Henning Schulzrinne
Cc: Michael Hammer; [e-mail]; Richard Shockey;
[e-mail]; [e-mail]; [e-mail]
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
<[e-mail]> 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:

-          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:[e-mail]] 
Sent: Thursday, November 07, 2013 10:28 AM
To: Henning Schulzrinne; [e-mail]; [e-mail];
[e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

 

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

 

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

 

 <http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00>
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:  <mailto:[e-mail]> [e-mail]
<mailto:[mailto:[e-mail]]> [mailto:[e-mail]] On
Behalf Of Gorman, Pierce A [NTK]
Sent: Thursday, November 07, 2013 9:54 AM
To: Brian Rosen; Richard Shockey
Cc:  <mailto:[e-mail]> [e-mail] List;  <mailto:[e-mail]>
[e-mail]; Fernando Mousinho (fmousinh)
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

 

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:[e-mail]> mailto:[e-mail]] 
Sent: November 06, 2013 11:59 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK];
<mailto:[e-mail]> [e-mail] List;  <mailto:[e-mail]>
[e-mail]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

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 < <mailto:[e-mail]>
[e-mail]> 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.

 

 <https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06>
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>
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:[e-mail]> mailto:[e-mail]] 
Sent: Wednesday, November 06, 2013 3:41 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK];
<mailto:[e-mail]> [e-mail] 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.

 

Is that along the lines you were thinking?

 

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey < <mailto:[e-mail]>
[e-mail]> 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.

 

_______________________________________________

cnit mailing list

 <mailto:[e-mail]> [e-mail]

 <https://www.ietf.org/mailman/listinfo/cnit>
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:  <mailto:[e-mail]> [e-mail] [
<mailto:[e-mail]> mailto:[e-mail]] On Behalf Of
Fernando Mousinho (fmousinh)
Sent: Tuesday, November 05, 2013 6:26 PM
To: Gorman, Pierce A [NTK];  <mailto:[e-mail]> [e-mail]
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]" < <mailto:[e-mail]>
[e-mail]>
Date: Tuesday, November 5, 2013 at 6:05 PM
To: Fernando Mousinho < <mailto:[e-mail]> [e-mail]>, "
<mailto:[e-mail]> [e-mail]" < <mailto:[e-mail]>
[e-mail]>
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."

 

But perhaps I misunderstood your last sentence?

 

 

From: Fernando Mousinho (fmousinh) [ <mailto:[e-mail]>
mailto:[e-mail]] 
Sent: November 05, 2013 4:34 PM
To:  <mailto:[e-mail]> [e-mail]
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 < <mailto:[e-mail]> [e-mail]>
Date: Tuesday, October 1, 2013 at 12:51 PM
To: Brian Rosen < <mailto:[e-mail]> [e-mail]>, "Peterson,
Jon" < <mailto:[e-mail]> [e-mail]>
Cc: " <mailto:[e-mail]> [e-mail]" < <mailto:[e-mail]>
[e-mail]>, Richard Shockey < <mailto:[e-mail]>
[e-mail]>, "'DOLLY, MARTIN C'" < <mailto:[e-mail]>
[e-mail]>, 'Robert Sparks' < <mailto:[e-mail]>
[e-mail]>
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:  <mailto:[e-mail]> [e-mail] [
<mailto:[e-mail]> mailto:[e-mail]] On Behalf Of

> Brian Rosen

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

> To: Peterson, Jon

> Cc:  <mailto:[e-mail]> [e-mail]; 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" <
<mailto:[e-mail]> [e-mail]>

> 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:  <mailto:[e-mail]> [e-mail] [
<mailto:[e-mail]> mailto:[e-mail]] On Behalf

> >>> Of Richard Shockey

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

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

> >>> Cc:  <mailto:[e-mail]> [e-mail]

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

> >>>

> >>> +1

> >>>

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

> >>> From:  <mailto:[e-mail]> [e-mail] [
<mailto:[e-mail]> mailto:[e-mail]] On Behalf

> >>> Of DOLLY, MARTIN C

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

> >>> To: Robert Sparks

> >>> Cc:  <mailto:[e-mail]> [e-mail]

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

> >>> [phone]

> >>>  <mailto:[e-mail]> [e-mail]

> >>>

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

> >>>> < <mailto:[e-mail]> [e-mail]>

> >>> 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:  <mailto:[e-mail]> [e-mail] [
<mailto:[e-mail]> mailto:[e-mail]] 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>
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

> >>>>>  <mailto:[e-mail]> [e-mail]

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

> >>>>

> >>>> _______________________________________________

> >>>> stir mailing list

> >>>>  <mailto:[e-mail]> [e-mail]

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

> >>> _______________________________________________

> >>> stir mailing list

> >>>  <mailto:[e-mail]> [e-mail]

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

> >>>

> >>> _______________________________________________

> >>> stir mailing list

> >>>  <mailto:[e-mail]> [e-mail]

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

> >> _______________________________________________

> >> stir mailing list

> >>  <mailto:[e-mail]> [e-mail]

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

> >

> > _______________________________________________

> > stir mailing list

> >  <mailto:[e-mail]> [e-mail]

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

> 

> _______________________________________________

> stir mailing list

>  <mailto:[e-mail]> [e-mail]

>  <https://www.ietf.org/mailman/listinfo/stir>
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.

_______________________________________________
stir mailing list
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/stir>
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.