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

[Henning Schulzrinne <[e-mail]>]

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

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:[e-mail]]
Sent: Wednesday, November 06, 2013 3:41 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; [e-mail]<mailto:[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 <[e-mail]<mailto:[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
[e-mail]<mailto:[e-mail]>
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: [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]; [e-mail]<mailto:[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]" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 5, 2013 at 6:05 PM
To: Fernando Mousinho <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]]
Sent: November 05, 2013 4:34 PM
To: [e-mail]<mailto:[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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 1, 2013 at 12:51 PM
To: Brian Rosen <[e-mail]<mailto:[e-mail]>>, "Peterson, Jon" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Richard Shockey <[e-mail]<mailto:[e-mail]>>, "'DOLLY, MARTIN C'" <[e-mail]<mailto:[e-mail]>>, 'Robert Sparks' <[e-mail]<mailto:[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: [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: [e-mail]<mailto:[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" <[e-mail]<mailto:[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: [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: [e-mail]<mailto:[e-mail]>
> >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt
> >>>
> >>> +1
> >>>
> >>> -----Original Message-----
> >>> From: [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: [e-mail]<mailto:[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]
> >>> [e-mail]<mailto:[e-mail]>
> >>>
> >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks"
> >>>> <[e-mail]<mailto:[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: [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
> >>>>>>
> >>>>>> Should the working group adopt this I-D as the starting point for
> >>>>>> the
> >>> STIR threat docuent?
> >>>>>>
> >>>>>> Russ
> >>>>> _______________________________________________
> >>>>> stir mailing list
> >>>>> [e-mail]<mailto:[e-mail]>
> >>>>> https://www.ietf.org/mailman/listinfo/stir
> >>>>
> >>>> _______________________________________________
> >>>> stir mailing list
> >>>> [e-mail]<mailto:[e-mail]>
> >>>> https://www.ietf.org/mailman/listinfo/stir
> >>> _______________________________________________
> >>> stir mailing list
> >>> [e-mail]<mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/stir
> >>>
> >>> _______________________________________________
> >>> stir mailing list
> >>> [e-mail]<mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/stir
> >> _______________________________________________
> >> stir mailing list
> >> [e-mail]<mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/stir
> >
> > _______________________________________________
> > stir mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/stir
>
> _______________________________________________
> stir mailing list
> [e-mail]<mailto:[e-mail]>
> 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
[e-mail]<mailto:[e-mail]>
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.