Subject: [stir] WG Last Call on draft-ietf-stir-threats-00.txt

From: Russ Housley <[email-masked]>
Date: Thu, 2 Jan 2014 12:46:42 -0500

The authors have posted an updated Internet-Draft on the STIR threat model.  It can be found here: http://www.ietf.org/id/draft-ietf-stir-threats-00.txt.

Is this document ready for the STIR WG to pass to the IESG, requesting publication as an Informational RFC?  Please provide your input on this mail list by end-of-business on 16 January 2014.  If you have issues or concerns, please tell us what changes to the document are necessary to resolve them.

Russ

---

From: Robert Sparks <[email-masked]>
Date: Tue, 21 Jan 2014 11:13:57 -0600

There have been no on-list responses to this last call.
We're extending it through this Friday, Jan 24.

Please let us know that you've reviewed this document and believe it is 
ready for publication, or if you have any issues that still need to be 
resolved.
Capturing your review on list is important, even if it's just a "ready" 
note.

RjS

On 1/2/14, 11:46 AM, Russ Housley wrote:
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 21 Jan 2014 10:43:15 -0800

Some comments on draft-ietf-stir-threats-00.txt:

1.  Introduction:  Remove the word "commercial".  Not all schemes (e.g., some DoS schemes which may be enabled by falsifying ID) are commercial.

2.  Scope:  Question:  Why are the identities of parties to the call out of scope?  It seems to me that this should be considered, at least in the interest of commonality between setup auth and connection endpoint auth.  

3.  Scope, last paragraph:  Change "improve" to "improves"

4.  3.2, 2nd paragraph:  Currently, most text spam comes from phones (not Internet) in many countries.  But there's no need to correct it; just make the point that it can originate anywhere and be gatewayed to the other networks.  Change "Almost always, these messages
   originate on the Internet, though they may ultimately reach endpoints
   over traditional telephone network protocols or the Internet. " to "These messages
   may originate and terminate on the Internet, cellular and/or traditional telephony networks."

5.  Attack Scenarios (or perhaps a new attack -- 3.3.):  IMO it would be good to add a TDoS scenario in which obfuscation of caller (e.g., randomization) complicates blocking.  Blocklists and rate limits depend on secure identity, typically caller but also calling network identity.

6.  Should we also point to the need to authenticate the service provider?  We have in some ways explicitly stated that it's just the calling party that's to be authenticated.  However, many of the proposals include authentication of the originating service provider.  For example, the crypto signing of an INVITE by the originating service provider actually authenticates both caller and service provider (SP).  We should consider the fact that calling parties are using multiple service providers (i.e., there exists authorized spoofing), and decide whether or not the origination service provider should also be authenticated.  IMO, it is extremely important to know the originating SP, both to provide feedback to the SP and to block calls. It is the originating SP that can most directly and drastically take action against an abusive caller.  And if a service provider is negligent, compromised or complicit, it may be necessary to take action against the service provider and/or all calls they originate.  

Best Regards,

Alex

> -----Original Message-----
> From: stir [mailto:[email-masked]] On Behalf Of Robert Sparks
> Sent: Tuesday, January 21, 2014 9:14 AM
> To: [email-masked]
> Subject: [stir] WG Last Call Extended : Responses Needed (was Re: WG Last
> Call on draft-ietf-stir-threats-00.txt)
> 
> ready for publication, or if you have any issues that still need to be resolved.
> > The authors have posted an updated Internet-Draft on the STIR threat
> model.  It can be found here: http://www.ietf.org/id/draft-ietf-stir-threats-
> 00.txt.
> >
> > Is this document ready for the STIR WG to pass to the IESG, requesting
> publication as an Informational RFC?  Please provide your input on this mail
> list by end-of-business on 16 January 2014.  If you have issues or concerns,
> please tell us what changes to the document are necessary to resolve them.
> >
> > Russ
> >

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Fri, 24 Jan 2014 17:41:38 +0000

I'd like to suggest a somewhat different taxonomy for the document:
I think there is one basic threat:  delivery of a calling number that the caller is not authorized to use.
This threat enables two kinds of attacks building on that threat:
-impersonation to hide caller identity (e.g., in support of robocalling)
-impersonation of the specific identity associated with the calling number (voicemail hacking, phishing)

I think the " Endpoints" section might be better called "Targets"

Section 4.1 on solution specific attacks either needs to be expanded with sufficient detail to be meaningful or else deleted before the document can become and RFC.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Tuesday, January 21, 2014 12:14 PM
To: [email-masked]
Subject: [stir] WG Last Call Extended : Responses Needed (was Re: WG Last Call on draft-ietf-stir-threats-00.txt)

RjS

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 25 Jan 2014 02:47:45 +0000

>I'd like to suggest a somewhat different taxonomy for the document:

Thanks for these notes, Penn.

>number (voicemail hacking, phishing)

I went through a spin on this document already with Steve Kent about what
should be considered an ³attack² versus a ³threat² versus what have you. I
take it in the security community these are terms with a particular
meaning, and I tried to bring the text here into conformance with his
guidance. I don¹t think we¹d say the ³threat² is the delivery of the
calling number in that fashion; that¹s a technique used by attackers to
accomplish their attacks.

>I think the " Endpoints" section might be better called "Targets"

In the architecture that the Actors section describes, endpoints originate
calls and receive them, and so necessarily originators of calls aren¹t in
that sense ³targets.² There goal of the Actors section is to explain who
the all parties are that originate, forward, and receive calls, just so
the Attacks and Attack Scenarios can refer to these.

>Section 4.1 on solution specific attacks either needs to be expanded with
>sufficient detail to be meaningful or else deleted before the document
>can become and RFC.

Here, agreed. I don¹t want to lose those bullet points though; maybe the
right thing to do is to just say that these points are out of scope, but
that future work should remember to consider issues like these.

Jon Peterson
Neustar, Inc.

>>model.  It can be found here:
>>http://www.ietf.org/id/draft-ietf-stir-threats-00.txt.
>>
>>publication as an Informational RFC?  Please provide your input on this
>>mail list by end-of-business on 16 January 2014.  If you have issues or
>>concerns, please tell us what changes to the document are necessary to
>>resolve them.
>>
>> Russ
>>

---

From: Alex Bobotek <[email-masked]>
Date: Fri, 24 Jan 2014 19:36:48 -0800

Jon,

Thanks much for the response.  

Some clarifications and response to it: 

On comment #4, most text spam comes from cellular devices (i.e., devices with prepaid SIMs in them); it would be incorrect to say that it usually comes from the Internet.  

Jon and others:  

On comment #6:  much of the abuse we see today involves unauthorized spoofing of an identity issued by one service provider on calls originating from a different service provider (SP).  While there are some solutions (e.g., delegation of authority chains) that could probably address much of this without identifying the originating service provider, knowing the originating SP has proven to be extremely useful in TDoS and robocall defense.  For example, there are many cases in which a TDoS victim may wish to block all calls from specific service providers.  Additionally, complaints can be directed to the correct SP.  Since the same calling party ID may be used in originating calls from multiple service providers (legitimately in addition to illegitimately), knowing the originating service provider may be necessary for some optimal defense mechanisms.  Some solutions, such as SP crypto-signing of INVITEs authenticate both SP and caller.  Personally, I believe that managing robocalls and TDoS requires a mechanism for securely identifying the originating SP, as the originating SP may need to take some action (e.g., neutralizing accounts that are participating in DoS).  The operational need for SP identification exists.  I feel it's best to at least mention and consider this, but possibly not _require_ it in a solution.  

I hope this helps.

Regards,

Alex

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Friday, January 24, 2014 6:48 PM
To: Alex Bobotek; Robert Sparks; [email-masked]
Subject: Re: [stir] WG Last Call Extended : Responses Needed (was Re: WG Last Call on draft-ietf-stir-threats-00.txt)

Thanks for these notes Alex:

>1.  Introduction:  Remove the word "commercial".  Not all schemes 
>(e.g., some DoS schemes which may be enabled by falsifying ID) are commercial.

The word ³commercial² there applies to one of three listed scenarios, all of which are just examples. Mentioning bulk commercial calling schemes does not exclude the possibility that the solution here would be relevant to TDoS attacks of various kinds.

>2.  Scope:  Question:  Why are the identities of parties to the call 
>out of scope?  It seems to me that this should be considered, at least 
>in the interest of commonality between setup auth and connection endpoint auth.

Long story, but the most important reason is because our motivating cases here are robocalling and voicemail hacking, and solving connected identity is not required for either of those problems. Authenticating who you connect to is also a difficult problem to solve because in many cases, the originator of a call can¹t know for sure who a call is supposed to reach, thanks to forwarding and related conditions.  There is a SIP solution for this (connected identity, RFC4916), but it adds some significant complexity, and ultimately it¹s not clear how often it would be useful.

>3.  Scope, last paragraph:  Change "improve" to "improves"

Done.

>4.  3.2, 2nd paragraph:  Currently, most text spam comes from phones 
>(not
>Internet) in many countries.  But there's no need to correct it; just 
>make the point that it can originate anywhere and be gatewayed to the 
>other networks.  Change "Almost always, these messages

I¹m not sure what you mean when you say text spam comes from phones.
Surely you don¹t mean literally from people thumbing these texts in repeatedly?

I¹ll change ³almost always² to ³usually,² though, if that helps.

>5.  Attack Scenarios (or perhaps a new attack -- 3.3.):  IMO it would 
>be good to add a TDoS scenario in which obfuscation of caller (e.g.,
>randomization) complicates blocking.  Blocklists and rate limits depend 
>on secure identity, typically caller but also calling network identity.

I¹d be happy to add a TDoS attack; I think that would be under Attacks and not Attack Scenarios. That would require some new text. The problem-statement does already allude (twice) to TDoS attacks. I can put some thoughts together, but definitely any text people feel like sending would be welcome.

>6.  Should we also point to the need to authenticate the service 
>provider?  We have in some ways explicitly stated that it's just the 
>calling party that's to be authenticated.  However, many of the 
>proposals include authentication of the originating service provider.  
>For example, the crypto signing of an INVITE by the originating service 
>provider actually authenticates both caller and service provider (SP).  
>We should consider the fact that calling parties are using multiple 
>service providers (i.e., there exists authorized spoofing), and decide 
>whether or not the origination service provider should also be 
>authenticated.  IMO, it is extremely important to know the originating 
>SP, both to provide feedback to the SP and to block calls. It is the 
>originating SP that can most directly and drastically take action 
>against an abusive caller.  And if a service provider is negligent, 
>compromised or complicit, it may be necessary to take action against 
>the service provider and/or all calls th  ey originate.

Again, if the scope of the work here is preventing robocalling and voicemail hacking (and well, okay, helping create greater accountability for TDoS), I¹m not sure how authenticating the service provider is on our plate as a problem. The degree to which a service provider vouches for a call is kind of solution-specific: it may be relevant to some in-band approaches, and not others; unclear how relevant it would be to out-of-band approaches. It is not in an meaningful sense a primary goal of this work for service providers to authenticate themselves to users, I think. Certainly service providers will play a role in some solutions, and reporting problems to a service provider will as well just as it does in a pre-STIR environment

>Best Regards,

Thanks again,

Jon Peterson
Neustar, Inc.

>> Subject: [stir] WG Last Call Extended : Responses Needed (was Re: WG 
>>Last  Call on draft-ietf-stir-threats-00.txt)
>> 
>> Please let us know that you've reviewed this document and believe it 
>>is  ready for publication, or if you have any issues that still need 
>>to be resolved.
>> publication as an Informational RFC?  Please provide your input on 
>>this mail  list by end-of-business on 16 January 2014.  If you have 
>>issues or concerns,  please tell us what changes to the document are 
>>necessary to resolve them.
>> >
>> > Russ
>> >

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Sun, 26 Jan 2014 15:41:57 +0000

Thanks, Jon
I'll defer to you on terminology. I do think that the attack sections 3.1 and 3.2 should be made more generic along the lines I suggest:
-impersonation to hide caller identity (e.g., in support of robocalling)
-impersonation of the specific identity associated with the calling number (voicemail hacking, phishing)

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Friday, January 24, 2014 9:48 PM
To: PFAUTZ, PENN L; [email-masked]
Subject: Re: [stir] WG Last Call Extended : Responses Needed (was Re: WG Last Call on draft-ietf-stir-threats-00.txt)

Jon Peterson
Neustar, Inc.

---

From: "David Frankel" <[email-masked]>
Date: Sun, 26 Jan 2014 10:39:06 -0800

Just a few more thoughts on the sorts of "attacks" (or at least abuses) that
involve Caller-ID, which I think support the sort of distinction Penn is
making:

1) Robocalling / SPIT: The caller's objective is to get the called party to
answer the phone and engage in some interaction (initially automated, then
human). Caller-ID is manipulated for at least three reasons:

A. Encourage the called party to answer (or at least discourage them from
ignoring the call). 

B. Provide anonymity; avoid trace-back; evade blocking schemes. 

C. Lend credibility to the call.

These objectives can be achieved to varying degrees through several
mechanisms including: misappropriating a number belonging to some legitimate
institution, or by using a (perhaps random) number from the local calling
area (making it look like a neighbor or local business), or by acquiring
numbers specifically for this purpose (see, for example, www.callerid4u.com,
which permits their clients to associate a specific calling NAME with an
acquired number).

These are "mass calling" campaigns where, typically, the called party is
non-specific.

2) Denial-of-Service: The caller attacks a specific target (PSAP, other
service provider, or even an individual), perhaps as part of an extortion
scheme. Caller-ID is manipulated primarily to provide anonymity, avoid
trace-back and evade blocking, using schemes similar to those noted above.

3) Impersonation / Hacking: By using a specific caller-ID belonging to a
particular individual, the caller is trying to gain access to an institution
or system that relies on caller-ID for "authentication." Voice-mail hacking
is perhaps the most obvious example (and is not specific to "mobile"
telephones noted in first sentence of 3.1), but there are other systems in
use at banks, airlines, calling-card services, conferencing providers, ISPs
and other "customer support" operations where callers are fully or partially
granted access to information or services based on caller-ID.

4) Impersonation targeting an individual: The caller uses an ID with some
"trust" association to fool the called party for nefarious purposes. For
example, a student-loan debt collector might call you with the ID of your
bank or mortgage lender or even your employer to add credence to some threat
if you don't pay up. Or an estranged spouse/parent might call a women's
shelter using "POLICE" or "FBI" to extract the whereabouts of somebody they
seek to harm or kidnap.

I'm not suggesting all this go into the document; just trying to help
clarify the range of threats and nuances associated therewith. (Perhaps some
of this could augment section 3.)

Also, by the way, the last two paragraphs of section 2.1 appear to be
near-duplicates (assuming I'm looking at the latest version).

David Frankel
ZipDXR LLC

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L
Sent: Sunday, January 26, 2014 7:42 AM
To: 'Peterson, Jon'; [email-masked]
Subject: Re: [stir] WG Last Call Extended : Responses Needed (was Re: WG

Thanks, Jon
I'll defer to you on terminology. I do think that the attack sections 3.1
and 3.2 should be made more generic along the lines I suggest:
-impersonation to hide caller identity (e.g., in support of robocalling)
-impersonation of the specific identity associated with the calling number
(voicemail hacking, phishing)

Penn Pfautz
AT&T Access Management
+1-732-420-4962