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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 1 Oct 2013 16:24:18 +0000

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]] On Behalf Of
>> Richard Shockey
>> Sent: Monday, September 30, 2013 1:11 PM
>> To: 'DOLLY, MARTIN C'; 'Robert Sparks'
>> Cc: [email-masked]
>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt
>> 
>> +1
>> 
>> -----Original Message-----
>> From: [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]
>> 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]
>> 
>> > On Sep 30, 2013, at 12:47 PM, "Robert Sparks" <[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]] 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]
>> >> https://www.ietf.org/mailman/listinfo/stir
>> >
>> > _______________________________________________
>> > stir mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/stir
>> _______________________________________________
>> stir mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/stir
>> 
>> _______________________________________________
>> stir mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/stir
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir

---

From: Brian Rosen <[email-masked]>
Date: Tue, 1 Oct 2013 12:28:56 -0400

Don't think there is much MESSAGE.  MSRP is about all we see, and XMPP is more likely than that.

Brian

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 1 Oct 2013 10:39:10 -0700

The reason for considering MESSAGE is that it's the predominant transport in IP-based mobile text messaging (i.e., RMS).  It is targeted to replace SMS, and is also being integrated into landline telephone numbers by non-carriers.  It's expected that >50% of phone numbers will use it a few years from now as IP-based telephony replaces current technologies.   

Similarly, SIP INVITE may carry message payload.  

I hope this helps explain the relevance of SIP MESSAGE.

Regards,

Alex

> Brian Rosen
> Sent: Tuesday, October 01, 2013 9:29 AM
> To: Peterson, Jon
> Cc: [email-masked]; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard
> Shockey
> > implemented in either endpoints or in intermediaries of various kinds.
> > If I see text that implies otherwise, I'll certainly change it.
> >
> >> SIP INVITE or MESSAGE, which might contain stock market advice even
> >> in a display name field.  These attacks do NOT require session
> establishment.
> > 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.
> >
> > 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.
> >
> >>     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.
> >
> >> 	 An attacker with an computer sends a high volume of SIP MESSAGE
> >> spam message to IP-enabled smart phones using randomized calling
> >> party numbers.
> >>
> > 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
> >>
> >>> Of Richard Shockey
> >>> Of DOLLY, MARTIN C
> >>>> Just to make sure - I think you're referring to Hadriel's comments
> >>>> on the
> >>>>> From: [email-masked] [mailto:[email-masked]] On
> >>>>> Behalf Of Russ Housley
> >>> document.  Martin asked for an additional week, so I'm sure we will
> >>> hear from him soon.
> >>>>>
> >>>>> Russ
> >>>>>
> >>>>>

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 1 Oct 2013 10:51:34 -0700

Jon,

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

   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

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

> more likely than that.

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

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

> [IMO,

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

> a

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

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

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

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

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

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

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

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

> >>>> finished

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

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

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

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

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

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

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

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