Subject: [stir] I-D Action: draft-ietf-stir-threats-01.txt

From: [email-masked]
Date: Tue, 04 Feb 2014 16:48:18 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Secure Telephone Identity Revisited Working Group of the IETF.

        Title           : Secure Telephone Identity Threat Model
        Author          : Jon Peterson
	Filename        : draft-ietf-stir-threats-01.txt
	Pages           : 11
	Date            : 2014-02-04

Abstract:
   As the Internet and the telephone network have become increasingly
   interconnected and interdependent, attackers can impersonate or
   obscure calling party numbers when orchestrating bulk commercial
   calling schemes, hacking voicemail boxes or even circumventing multi-
   factor authentication systems trusted by banks.  This document
   analyzes threats in the resulting system, enumerating actors,
   reviewing the capabilities available to and used by attackers, and
   describing scenarios in which attacks are launched.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stir-threats/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stir-threats-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-stir-threats-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Robert Sparks <[email-masked]>
Date: Wed, 05 Feb 2014 13:45:29 -0600

I'm working on the shepherd writeup for this draft.

I'd like to hear from those that provided comments that they believe 
their comments have been addressed.

I'd also very much like to hear from more people in the group that they 
read the document and believe it is ready to ship.

RjS

On 2/4/14, 6:48 PM, [email-masked] wrote:
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Brian Rosen <[email-masked]>
Date: Wed, 5 Feb 2014 14:50:16 -0500

I have read the document and think it is ready to publish.

Brian

On Feb 5, 2014, at 2:45 PM, Robert Sparks <[email-masked]> wrote:

> I'd like to hear from those that provided comments that they believe their comments have been addressed.
> 
> I'd also very much like to hear from more people in the group that they read the document and believe it is ready to ship.
> 
> RjS
>

---

From: "David Frankel" <[email-masked]>
Date: Wed, 5 Feb 2014 11:55:31 -0800

Robert,

I read the draft and am fine with the updates. (There's always more that
could be done, but we have to save something for the next round!)

David Frankel
ZipDX LLC

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, February 5, 2014 11:50 AM
To: Robert Sparks
Cc: [email-masked] List
Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-01.txt

Brian

>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at
tools.ietf.org.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Feb 2014 15:40:17 -0500

I was once trying to follow all the discussion on the stir list, but 
finally I stopped when it began taking too much time. So I haven't seen 
most of the discussion on this draft. But I just now read it, and have a 
few comments. (Pretty much nit-level issues) I'm sorry if these issues 
have been previously discussed.

Section 1 - Use of 'Caller ID' to mean the name of the calling party:

Maybe I have the wrong understanding, but I consider the term "Caller 
ID" to describe the delivery of the calling party number, or perhaps 
both the number and optionally the name. I find it quite confusing to 
see it used to mean just the delivery of the name, not the number.

ISTM it would be better to use Caller ID to refer to the calling party 
number, and another term for the calling party name.

Wikipedia says: "Caller ID is made up of two separate pieces of 
information: the calling number and the billing (or subscriber) name 
where available." So that must be right. :-)

Section 3.2 says:

    When a human callee is to be alerted at call setup time, the time
    frame for executing any countermeasures is necessarily limited.
    ...  For text
    messages, a delay for executing anti-impersonation countermeasures is
    much less likely to degrade perceptible service.

IMO this is frequently not the case. Often SMS-style text messages are 
used in an interactive conversation style. In that case I suspect that 
the delay sensitivity is similar to that for call setup type.

Otherwise this seemed good to me.

	Thanks,
	Paul

On 2/5/14 2:45 PM, Robert Sparks wrote:
>> submission

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Feb 2014 18:59:45 +0000

Thanks for these notes, Paul.

>where available." So that must be right. :-)

Yeah, we¹re trying to keep that straight, so I¹ll replace any lingering
misreferences to Caller ID with CPN.

>the delay sensitivity is similar to that for call setup type.

Hmm. My intuition would be the other way. If you have to wait, say, ten
seconds after receiving a call before you start alerting the callee, the
caller may hang up - whether you¹re playing ringing audio to the caller
that whole time or (worse, I think) just dead air, they may lose patience.
But if I¹m getting a text message for the first time from an unfamiliar
source, I don¹t mind if its delivery is delayed ten or twenty seconds, if
that will cut down significantly on spam. SMS delivery is unreliable, and
senders are accustomed to not receiving immediate responses.

In text message conversations where there¹s quick back-and-forth, that
delay might be intolerable, sure. But in those cases both parties have
already established that they are participating in desired communications.
So from a mechanism perspective, this is a case where you wouldn¹t have to
acquire new credentials, check delegation chains or what have you for each
incoming message, provided messages from the same source use the same
credentials. 

Make sense?

>Otherwise this seemed good to me.

Thanks again,

Jon Peterson
Neustar, Inc.

---

From: Dan York <[email-masked]>
Date: Thu, 6 Feb 2014 20:06:48 +0000

Robert,

>read the document and believe it is ready to ship.

I have read the document and have no fundamental objection to publishing.
I have only several editorial comments for Jon's consideration.

======================
1.   In section one, I found this paragraph a bit confusing, particularly
the last sentence:
----
   In SIP and even many traditional telephone protocols, call signaling
   can be renegotiated after the call has been established.  Using
   various transfer mechanisms common in telephone systems, a callee can
   easily be connected to, or conferenced in with, telephone numbers
   other than the original calling number once a call has been
   established.  These post-setup changes to the call are outside the
   scope of impersonation considered in this model.  Furthermore,
   impersonating a reached number to the originator of a call is outside
   the scope of this threat model.

----

Specifically the use of "reached number" is something I don't see anywhere
else in the document.  I also just find it strange to have that last
sentence tacked on to a paragraph that covers another topic.  It might be
better as something like:

----
   In SIP and even many traditional telephone protocols, call signaling
can be renegotiated after the call has been established. Using
various transfer mechanisms common in telephone systems, a callee can
easily be connected to, or conferenced in with, telephone numbers
other than the original calling number once a call has been
established. These post-setup changes to the call are outside the
scope of impersonation considered in this model.

Furthermore, this threat model does not include in its scope the
verification of
the called party number back to the originator of the call. There is no
assurance to the originator that they are reaching the correct number. This
threat model is focused only on verifying the caller party number to the
callee.
----

Maybe that's too wordy but I think it would be helpful to those trying to
understand STIR to be clear that spoofing the called party number is out
of scope.

======================

2. In section "3.1.  Voicemail Hacking via Impersonation", the end of the
first paragraph says:
----
   the
   attacker may try to impersonate the calling party number using one of
   the scenarios described below.
----
I'm not clear what the "scenarios described below" are as I don't see any
scenarios in this section 3.1.  Is it referring to the later section 4?
If so, you might want to reword it along the lines of "the scenarios
describe in the later section on "Attack Scenarios"."

======================

3. In section "3.2.  Unsolicited Commercial Calling from Impersonated
Numbers", third paragaph:
----
If there were a service that
   could inform the terminating side of that it should expect an
   identity signature in calls or texts from that number, however, that
   would also help in the robocalling case.
----

The "of that it" doesn't work in my brain.  I think the "of" needs to be
dropped.

======================

4. In section "3.3.  Telephony Denial-of-Service Attacks", first
paragraph, there is an extra "a" in "attaacks":
----
These attaacks might target a
   business, an individual or a public resource like emergency

   responders; the attack may intend to extort the target or have other
   motivations.

----
I also personally don't like this usage of the semi-colon and might
suggest these would be best as two separate sentences... but that's a
style thing.  
<insert semi-colon rat hole / flame war here>

======================

5. In section "4. Attack Scenarios", the acronyms "CPN" and "IAM" are used
 without expansion in the first paragraph and then CPN is defined in the
second paragraph.  It might be better to put "PSTN-PSTN" first.  I don't
know whether "IAM" warrants expanding.

I also would suggest putting "IP-IP" first in the scenarios given that
most folks reading this should be familiar with SIP and that is by far the
easiest example for people to understand.  The flow of the scenarios could
be: 
IP-IP
PSTN-PSTN
IP-PSTN
IP-PSTN-IP

----
 Impersonation, IP-PSTN

   An attacker on the Internet uses a commercial WebRTC service to send
   a call to the PSTN with a chosen calling party number.  The service
   contacts an Internet-to-PSTN gateway, which inserts the attacker's
   chosen calling party number into the SS7 call setup message (the CPN
   field of an IAM).  When the call setup message reaches the
   terminating telephone switch, the terminal renders the attacker's
   chosen calling party number as the calling identity.

   Impersonation, PSTN-PSTN

   An attacker with a traditional PBX (connected to the PSTN through
   ISDN) sends a Q.931 SETUP request with a chosen calling party number
   which a service provider inserts into the corresponding SS7 calling
   party number (CPN) field of a call setup message (IAM).  When the
   call setup message reaches the endpoint switch, the terminal renders
   the attacker's chosen calling party number as the calling identity.

----

======================

6. In section "4. Attack Scenarios", the term "calling identity" is used
at the end of each scenario in the text "the terminal renders the
attacker's chosen calling party number as the calling identity."  That's
the only usage of that phrase in the document.   I don't know that this is
wrong, but I just wondered if it was in keeping with the terminology that
is being used across other STIR documents.  (And I don't really have an
alternative that comes to my mind.)

======================

Regards,
Dan

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2014 16:09:01 -0500

> misreferences to Caller ID with CPN.

Thx.

> incoming message, provided messages from the same source use the same

*If* the delay is only on the first message, then fine.

It was the quick back-and-forth that I was concerned with.

If all the delay is in the endpoint, and it can skip the rechecking then 
fine. I was imagining that the delay would be from some intermediary 
that wouldn't have the history to do that.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 7 Feb 2014 00:14:42 +0000

Thanks Dan, some notes below.

>threat model is focused only on verifying the caller party number to the

I¹m fine splitting this into two as you suggest. The reason why these
things were lumped into one paragraph is that all these sentences show
that the only form of telephone identity in scope of this thread model is
the kind conveyed to identify the originator of a call.

>understand STIR to be clear that spoofing the called party number is out

I¹ll just put in a ref to that section.

I think you¹re right. Well caught.

The extra a¹s is for emphasis, as in ³attaaaaaaaack!² No really, I¹ll fix
it.

><insert semi-colon rat hole / flame war here>

I think I like that semicolon.

We probably should just put a ref to Q.761 or something in here, and maybe
Q.931 as well. The draft is really reference-light.

>easiest example for people to understand.  The flow of the scenarios could

No strong feelings here; I can shuffle these.

>   the attacker's chosen calling party number as the calling identity.

Erm. It¹s probably okay.

Thanks again,

Jon Peterson
Neustar, Inc.