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

From: <[email-masked]>
Date: Mon, 25 Nov 2013 15:23:39 +0000

Jon,

Apologies for belated comments on this. 

> 1.  Introduction and Scope
> [...]
>therefore they impersonate numbers that are not
>   assigned to them.

Being picky: maybe add "or unassigned." 

> [...]
>   In much of the PSTN, there exists a supplemental service that
>   translates calling party numbers into regular names, including the
>   proper names of people and businesses, for rendering to the called
>   user.  These services (frequently termed 'Caller ID' )

No doubt people will say we're debating regional differences but the above looks more like "Caller Name Presentation" than Caller ID to me (which I tend to use for numbers instead). 

> [TBD: should this include an attacker that can capture
>      signaling that isn't directly sent to it?  Not a factor for
>      robocalling, but perhaps for voicemail hacking, say.]

If I rephrase this as "Should the threat model assume that an attacker can never capture signalling that is not directly sent to it", I don't think it should IMO, although I understand that compromising intermediaries on the call path may be considered out of scope for this document. 

> 3.1.  Voicemail Hacking via Impersonation 
>
>A voicemail service allows users calling from their mobile phones
>   access to their voicemail boxes on the basis of the calling party
>   number.   

Section 3.1 seems to be focused on the most common case: 
a) users accessing the mobile voicemail, and 
b) users doing so only with their own phone.

For a), it seems to me that this section also applies to non-mobile voicemails - including broadband voip voicemails. Maybe you want to remove "mobile" in the first sentence. BB voicemails may actually be an interesting in-net use case for this.

For b) I was wondering whether the exclusion of remote access was deliberate: for most providers, users can actually check their voicemails calling with a a phone different from their own, generally through dialling their regular phone number, interrupt the announcement with a */#... and enter a pin code. In the event of such a user being able to provide a signed CPN on a different phone, the star and the pin code wouldn't be necessary. 

Maybe remote access shouldn't be included but if this is meant to be out of scope, the text should probably say so. 

> 3.2.  Unsolicited Commercial Calling from Impersonated Numbers
[...]
>   When a human callee is to be alerted at call setup time, the time
>   frame for executing any countermeasures is necessarily limited.
>   Ideally, a user would not be alerted that a call has been received
>   until any necessary identity checks have been performed. This could
>   however result in inordinate post-dial delay from the perspective of
>   legitimate callers.

As an aside, if the 'ringing' phase doesn't count as post-dial delay, it wouldn't be uncommon to send a ring back tone to the caller during those necessary identity checks. I agree this is not ideal though.

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, October 12, 2013 1:35 AM
To: [email-masked]
Cc: [email-masked]
Subject: [stir] I-D Action: draft-ietf-stir-threats-00.txt

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(s)       : Jon Peterson
	Filename        : draft-ietf-stir-threats-00.txt
	Pages           : 11
	Date            : 2013-10-11

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

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/

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.