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

Dan York <york@isoc.org> Thu, 06 February 2014 20:06 UTC

Return-Path: <york@isoc.org>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DE41A0472 for <stir@ietfa.amsl.com>; Thu, 6 Feb 2014 12:06:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 327bietA5Erx for <stir@ietfa.amsl.com>; Thu, 6 Feb 2014 12:06:52 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id 82D351A0458 for <stir@ietf.org>; Thu, 6 Feb 2014 12:06:52 -0800 (PST)
Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB241.namprd06.prod.outlook.com (10.242.191.148) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 20:06:49 +0000
Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.117]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.77]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 20:06:49 +0000
From: Dan York <york@isoc.org>
To: Robert Sparks <rjsparks@nostrum.com>, "stir@ietf.org" <stir@ietf.org>
Thread-Topic: [stir] I-D Action: draft-ietf-stir-threats-01.txt
Thread-Index: AQHPIgv+TU1Mt2a8wEe8JLbFMf0W95qnEY2AgAFEdoA=
Date: Thu, 06 Feb 2014 20:06:48 +0000
Message-ID: <CF1947DE.60845%york@isoc.org>
In-Reply-To: <52F294D9.2080005@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.255.101.4]
x-forefront-prvs: 0114FF88F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(479174003)(377454003)(24454002)(199002)(189002)(56816005)(90146001)(2656002)(46102001)(81342001)(47446002)(87266001)(31966008)(93136001)(74706001)(81816001)(81542001)(74876001)(76176001)(85306002)(79102001)(92566001)(51856001)(36756003)(77096001)(80022001)(54316002)(49866001)(47736001)(76482001)(56776001)(86362001)(65816001)(93516002)(87936001)(74662001)(54356001)(92726001)(74366001)(94946001)(19580405001)(76786001)(77982001)(59766001)(50986001)(80976001)(83072002)(74502001)(63696002)(4396001)(47976001)(85852003)(19580395003)(83322001)(81686001)(76796001)(94316002)(69226001)(53806001)(95416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB241; H:BLUPR06MB243.namprd06.prod.outlook.com; CLIP:10.255.101.4; FPR:FE2CF2F6.86FA5D01.31D9714B.4EF5D161.20514; InfoNoRecordsA:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F70179063156E34C9CB900E9710F2A7F@namprd06.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-01.txt
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 20:06:56 -0000

Robert,


On 2/5/14 2:45 PM, "Robert Sparks" <rjsparks@nostrum.com> wrote:

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

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