Secure Telephone Identity Threat Model
draft-ietf-stir-threats-04

[Ballot comment]

- section 1, last para: I'm glad the names stuff is out of
scope, thanks.

- 2.3, 2nd last para: I don't get why an attacker who
compromises an intermediary is out of scope here. Do you only
mean within the PSTN though? (Which I'd understand.) The last
sentence there is also ambiguous - I think the countermeasures
you mean are those to be defined by STIR, but that isn't what
is stated.

[Ballot comment]
I'm a yes, and found the document mostly well-written and helpful. Let's start with that.

I agree with Benoit's point about the list of attacks with no details.

In addition, the document title sounds like it's a complete analysis of STIR threats, but if I'm reading it correctly, there are a number of threats that aren't being considered (because the threats related to robocalling are considered to be the major concerns, did I get that right?).

You might want to consider adjusting the document title a bit to reflect that.

[Ballot comment]
I'm a yes. Let's start with that.

I agree with Benoit's point about the list of attacks with no details.

In addition, the document title sounds like it's a complete analysis of STIR threats, but if I'm reading it correctly, there are a number of threats that aren't being considered (because the threats related to robocalling are considered to be the major concerns, did I get that right?).

You might want to consider adjusting the document title a bit.

[Ballot comment]
The draft was an interesting read, thanks for your work on it to develop the threat models.  I just have some questions from thinking about a few of the discussion point and not being familiar with the controls currently in place, so please bear with me (all non-blocking questions/comments):

In Sect 3.2, The following seems odd to me, wouldn't the robocall program know to avoid numbers that raise suspicion and why aren't they just blocked outright as source numbers?
  A robocaller may impersonate
  a number that is not an assignable number (for example, in the United
  States, a number beginning with 0),

Beyond checking that a number is valid, is there really much that can be done?  If there is some sort of validation check against incoming numbers, helpful robocalling or texting could be blocked (local robocalls for storms, airlines notifying on changes, etc.).  Source numbers can change, if you block based on an unknown source (maybe something you have not subscribed to receive), you may miss something important.  If someone has not opted out (asked to not receive unsolicited calls), in the US at least, nothing prevents the caller from placing the call (legally).  Is anything changing on that or are we bound to those restrictions?

I'll also watch for a response to Benoit's comments.  Thanks.

[Ballot comment]
Not sure what the following text adds to the document. Either there is too much or too little information.
I have no idea what some of these attacks mean:

  Some of the attacks that should be considered in the future include
  the following:

  Attacks Against In-band

      Token replay

      Baiting a call to a chosen number with a REFER

      Removal of in-band signaling features

  Attacks Against Out-of-Band

      Provisioning Garbage CPRs

      Data Mining

  Attacks Against Either Approach

      Attack on directories/services that say whether you should expect
      authenticated calling number data or not

      Canonicalization attacks

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-stir-threats-03, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Secure Telephone Identity Threat Model) to Informational RFC


The IESG has received a request from the Secure Telephone Identity
Revisited WG (stir) to consider the following document:
- 'Secure Telephone Identity Threat Model'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-07-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-stir-threats/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-stir-threats/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested?

This threat model should be published as an Informational RFC

(2) Please provide a Document Announcement Write-Up.

Technical Summary

  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.

Working Group Summary

  This document is a product of the STIR working group.

Document Quality

  This document was developed in parallel with the problem statement.
  It has received significant cross-area review.

Personnel

  Robert Sparks is the document shepherd.
  Richard Barnes is the Responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

The shepherd has reviewed this version of the document and its predecessors
to ensure it reflects working group discussions and to ensure it is ready
for wider review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 

No concerns.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

We have had good cross-area participation in the development of this document, particularly from individuals that participate heavily in the security area.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

There are no specific concerns to call out.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.

Yes.

(8) Has an IPR disclosure been filed that references this document?

No IPR disclosures have been filed referencing this document.

(9) How solid is the WG consensus behind this document?

The document has been thoroughly discussed by the group and has a solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

There has been no threat of appeal or significant discontent expressed with the content of this document.

(11) Identify any ID nits the Document Shepherd has found in this document.

All known nits have been addressed.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

This document contains no content needing this type of formal review.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?

There are no such references.

(15) Are there downward normative references references (see RFC 3967)?

THere are no such references.

(16) Will publication of this document change the status of any existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations section.

The IANA Consideration section contains:

    This memo includes no request to IANA.

(18) List any new IANA registries that require Expert Review for future allocations.

There are none.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal languages used in this document.