From nobody Fri May 9 12:06:43 2014 Return-Path: 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 7FEC51A033E; Fri, 9 May 2014 12:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ne2qsDvExa_R; Fri, 9 May 2014 12:06:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA88E1A030E; Fri, 9 May 2014 12:06:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140509190634.18233.43270.idtracker@ietfa.amsl.com> Date: Fri, 09 May 2014 12:06:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/Ow_t6ALsbAZ2WyC8z_w2vnRQCfY Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-problem-statement-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 19:06:37 -0000 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 Problem Statement and Requirements Authors : Jon Peterson Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-stir-problem-statement-04.txt Pages : 25 Date : 2014-05-09 Abstract: Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall security of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to 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. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack of effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult, and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stir-problem-statement-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stir-problem-statement-04 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 nobody Fri May 9 12:11:56 2014 Return-Path: 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 12A351A033B; Fri, 9 May 2014 12:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jBfNqnqeZqoB; Fri, 9 May 2014 12:11:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7811A0053; Fri, 9 May 2014 12:11:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140509191150.18198.72539.idtracker@ietfa.amsl.com> Date: Fri, 09 May 2014 12:11:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/b2KXJT796KhwyT-EJLzjGOKzNI0 Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-problem-statement-05.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 19:11:52 -0000 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 Problem Statement and Requirements Authors : Jon Peterson Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-stir-problem-statement-05.txt Pages : 25 Date : 2014-05-09 Abstract: Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall security of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to 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. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack of effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult, and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stir-problem-statement-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stir-problem-statement-05 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 nobody Fri May 9 12:16:50 2014 Return-Path: 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 1BAE51A0076 for ; Fri, 9 May 2014 12:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 EXsVHRg_s0nB for ; Fri, 9 May 2014 12:16:48 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id E3C211A0053 for ; Fri, 9 May 2014 12:16:47 -0700 (PDT) Received: from stntexhc11.cis.neustar.com (stntexhc11.va.neustar.com [10.31.58.70]) by chihiron1.nc.neustar.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 4d9f_c789_5da00b19_db68_4d08_b4fe_ae292b872f9a; Fri, 09 May 2014 15:16:42 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 9 May 2014 15:11:53 -0400 From: "Peterson, Jon" To: "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-problem-statement-04.txt Thread-Index: AQHPa7nV9uNBsgQ2sUaCYMsdeR7mY5s4a02A Date: Fri, 9 May 2014 19:11:53 +0000 Message-ID: References: <20140509190634.18233.43270.idtracker@ietfa.amsl.com> In-Reply-To: <20140509190634.18233.43270.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.129.149] Content-Type: text/plain; charset="us-ascii" Content-ID: <91B4B490EFC94F4D8E337FA93AAE0C0E@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/yJFMyYjaApP1HUccm2v_zliptDs Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 19:16:50 -0000 This version of the document reflects IESG review fixes. One resounding comment from the IESG was that the document contained some high-level requirements but did not mention requirements in its title or abstract; that has been amended. The most substantial change is the addition of section 6.6, "Concerns about Pervasive Monitoring," to the list of current events that are motivating our work. There were also a number of smaller editorial changes, including some last-minute nits that Sanjay found. Comments still welcome, but this should be pretty much good to go. Jon Peterson Neustar, Inc. On 5/9/14, 12:06 PM, "internet-drafts@ietf.org" wrote: > >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 Problem Statement and >Requirements > Authors : Jon Peterson > Henning Schulzrinne > Hannes Tschofenig > Filename : draft-ietf-stir-problem-statement-04.txt > Pages : 25 > Date : 2014-05-09 > >Abstract: > Over the past decade, Voice over IP (VoIP) systems based on SIP have > replaced many traditional telephony deployments. Interworking VoIP > systems with the traditional telephone network has reduced the > overall security of calling party number and Caller ID assurances by > granting attackers new and inexpensive tools to 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. Despite previous > attempts to provide a secure assurance of the origin of SIP > communications, we still lack of effective standards for identifying > the calling party in a VoIP session. This document examines the > reasons why providing identity for telephone numbers on the Internet > has proven so difficult, and shows how changes in the last decade may > provide us with new strategies for attaching a secure identity to SIP > sessions. It also gives high-level requirements for a solution in > this space. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-stir-problem-statement-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-problem-statement-04 > > >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 >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Wed May 14 06:10:08 2014 Return-Path: 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 6D97B1A007B; Wed, 14 May 2014 06:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 swuFi85C5QLa; Wed, 14 May 2014 06:10:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDFF1A008A; Wed, 14 May 2014 06:10:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140514131000.8342.38710.idtracker@ietfa.amsl.com> Date: Wed, 14 May 2014 06:10:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/_90K2WvlxrgdoGDaUAxBpe6EN14 Cc: stir mailing list , stir chair , RFC Editor Subject: [stir] Document Action: 'Secure Telephone Identity Problem Statement and Requirements' to Informational RFC (draft-ietf-stir-problem-statement-05.txt) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 13:10:04 -0000 The IESG has approved the following document: - 'Secure Telephone Identity Problem Statement and Requirements' (draft-ietf-stir-problem-statement-05.txt) as Informational RFC This document is the product of the Secure Telephone Identity Revisited Working Group. The IESG contact persons are Richard Barnes and Alissa Cooper. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ Technical Summary Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall security of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to 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. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack of effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult, and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. Working Group Summary This document is a product of the STIR working group. Document Quality This document and its predecessors received significant review from during the working group formation stages to its current form. There is solid consensus that it reflects the problem the working group intends to address. Personnel Robert Sparks is the document shepherd. Richard Barnes is the Responsible AD. From nobody Wed May 28 13:22:09 2014 Return-Path: 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 BCDEA1A022A for ; Wed, 28 May 2014 13:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 g01Xe0ZRiqAh for ; Wed, 28 May 2014 13:22:04 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CCB51A014A for ; Wed, 28 May 2014 13:22:03 -0700 (PDT) Received: from stntexhc10.cis.neustar.com (unknown [10.31.58.69]) by chihiron1.nc.neustar.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 200c_04e5_4ae2e84b_f1bb_45ee_a263_f8192d2d77d2; Wed, 28 May 2014 16:21:59 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc10.cis.neustar.com ([169.254.4.116]) with mapi id 14.03.0158.001; Wed, 28 May 2014 16:21:58 -0400 From: "Rosen, Brian" To: "stir@ietf.org" Thread-Topic: A possible exploit for stir Thread-Index: AQHPerJ5w+uzXeFVlEazJOjgEY/ylA== Date: Wed, 28 May 2014 20:21:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.33.192.21] Content-Type: multipart/alternative; boundary="_000_CFABBDA56CE9Abrianrosenneustarbiz_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/rb8HR0AVzSXD2RktOd8OouzoNRQ Subject: [stir] A possible exploit for stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 20:22:05 -0000 --_000_CFABBDA56CE9Abrianrosenneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Suppose a caller with TN1 is on a call with TN2, and TN2 is served by evil.= com. If evil sends TN1 a REFER to TN3@evil.com, it should create, and sign, an I= NVITE From TN1, To TN3 and forward it to evil. Evil can then call TN3, claim it=92s from TN1 and exploit. As a practical matter, TN1=92s attempt to address a call to TN3@evil.com wo= n=92t actually work. The domain will get rewritten, and the call will be r= outed by TN rules, and not domains. But strictly speaking, an exploit like this is possible, and we should docu= ment it. Devices should not create random extra calls based on a REFER to = domains they don=92t trust. Paul Kyzivat pointed this possibility out in a discussion on how to handle = a problem in another domain. Brian --_000_CFABBDA56CE9Abrianrosenneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Suppose a caller with TN1 is on a call with TN2, and TN2 is served by = evil.com.

If evil sends TN1 a REFER to TN3@evil.com, it should create, and sign,= an INVITE From TN1, To TN3 and forward it to evil.

Evil can then call TN3, claim it=92s from TN1 and exploit.

As a practical matter, TN1=92s attempt to address a call to TN3@evil.c= om won=92t actually work.  The domain will get rewritten, and the call= will be routed by TN rules, and not domains.

But strictly speaking, an exploit like this is possible, and we should= document it.  Devices should not create random extra calls based on a= REFER to domains they don=92t trust.

Paul Kyzivat pointed this possibility out in a discussion on how to ha= ndle a problem in another domain.

Brian
--_000_CFABBDA56CE9Abrianrosenneustarbiz_-- From nobody Wed May 28 13:57:41 2014 Return-Path: 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 4E84D1A023E for ; Wed, 28 May 2014 13:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 8yQrimktkeDe for ; Wed, 28 May 2014 13:57:38 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 75BEE1A022D for ; Wed, 28 May 2014 13:57:38 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id 7Tgk1o0020xGWP853YxaAM; Wed, 28 May 2014 20:57:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 7Yxa1o00c3ZTu2S3YYxaRw; Wed, 28 May 2014 20:57:34 +0000 Message-ID: <53864DBE.4020301@alum.mit.edu> Date: Wed, 28 May 2014 16:57:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: stir@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401310654; bh=ish4O3WKjGNDjteYJYG1OGtMzep4CfJmY70yhAuH6Vo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=q96ryQU7RPvb3hjYChyhUbf0ppWlKhUPdr+YCR5TEUjpq7uUDL0DRNx8T00av/u+W aLzRCm7L0z0cl/l23j/1U/C2lMzYDE99RQ0G9ygyQTTHPYGNBmbBvN4s4l2rmfHfOZ A5KcfJHo2W1OZuMvh0dWVYUwNPQ3jIO0D9AmOTt2neO1A9yWkFghykvFBpIqboia5P UI3iEPbY7IO7L9jRZW9ev4hoeSLm2IV/qqF0T9J/kZn3Ujz35LQ+xaNPztVQbJ1Jzm u9q1Gvw2RDaOxVXC9qctBfpoWNvAvcLslUdmf8ZZuo3kNZtYori4U0OPmDI1uD/ZlH Y81k2Zlf79lrA== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/NxX0QxnBRMwrjDIQolIYC1aLdsE Subject: Re: [stir] A possible exploit for stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 20:57:39 -0000 On 5/28/14 4:21 PM, Rosen, Brian wrote: > Suppose a caller with TN1 is on a call with TN2, and TN2 is served by > evil.com. > > If evil sends TN1 a REFER to TN3@evil.com, it should create, and sign, > an INVITE From TN1, To TN3 and forward it to evil. > > Evil can then call TN3, claim it’s from TN1 and exploit. > > As a practical matter, TN1’s attempt to address a call to TN3@evil.com > won’t actually work. The domain will get rewritten, and the call will > be routed by TN rules, and not domains. I don't know if that is true or not. There are *many* ways of handling transfer. In the cases I'm familiar with, some server in the domain of the party initiating the transfer wants to remain in the signaling and media paths. There are multiple reasons for this. Taking responsibility for the cost of the new call is one. Keeping control for "lawful" intercept is another. In those cases, if the domain in control doesn't have signing authority for the number of the remaining party in the call, then it won't be able to sign the new call that way. It can probably sign on behalf of the departing party (transferrer). In some cases that may be acceptable, or even a feature. In other cases it might be a change from current behavior, for good or bad. And are we sure that there aren't any practical cases where REFER would work without intervention? > But strictly speaking, an exploit like this is possible, and we should > document it. Devices should not create random extra calls based on a > REFER to domains they don’t trust. > > Paul Kyzivat pointed this possibility out in a discussion on how to > handle a problem in another domain. Don't sell yourself short. You invented this exploit as a feature. I just recognized it as an exploit. Thanks, Paul From nobody Wed May 28 16:38:26 2014 Return-Path: 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 111591A02B0 for ; Wed, 28 May 2014 16:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 uCENih_bcfVd for ; Wed, 28 May 2014 16:38:21 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABEB1A0290 for ; Wed, 28 May 2014 16:38:20 -0700 (PDT) Received: from stntexhc10.cis.neustar.com (unknown [10.31.58.69]) by chihiron1.nc.neustar.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 2010_a3f0_27daa21c_29b9_42ff_9914_d846a1fa7a9b; Wed, 28 May 2014 19:38:11 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc10.cis.neustar.com ([169.254.4.116]) with mapi id 14.03.0158.001; Wed, 28 May 2014 19:38:11 -0400 From: "Peterson, Jon" To: Paul Kyzivat , "stir@ietf.org" Thread-Topic: [stir] A possible exploit for stir Thread-Index: AQHPerJ5w+uzXeFVlEazJOjgEY/ylJtWvI4A//+3VAA= Date: Wed, 28 May 2014 23:38:11 +0000 Message-ID: References: <53864DBE.4020301@alum.mit.edu> In-Reply-To: <53864DBE.4020301@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.128.83] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1D98B38F66E74A49A0580FF794774824@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/4DVSMk5Gvnn3-YHLq-G9U_-nNQQ Subject: Re: [stir] A possible exploit for stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 23:38:23 -0000 Yes, there are many ways of implementing and handling transfer, so many that it's difficult to get too specific about what the threat here might be. The threats document already notes that "using transfer mechanisms common in telephone systems, a callee can easily be connected to, or conferenced with, telephone numbers other than the original calling number once a call has been established." But evaluating the risks of this type of transfer will be highly solution-specific, and for the moment we're deferring solution-specific threats to the solution documents, rather than the threat document. Speculating along solution lines for a moment, this specific example begs questions about replay protection, URL handling, REFER authorization and many other issues. Any intermediary in a SIP call path can try to act as a man-in-the-middle, and what this REFER really does is to bait a call to a specific number so that an intermediary can man-in-the-middle it. We've set the scope of STIR to explicitly not address man-in-the-middle attacks, but perhaps the baiting dimension justifies addressing this. Evil's ability to cut-and-paste the Identity token in the caller's INVITE depends largely on the solution's scope of protection. It is possible to create a scope of protection for a signature which is tied to the actual source and sinks of media employed by the caller - this is the effect of signing the SDP, for example. Of course the modification of those fields by SBCs often renders this approach impractical. Maybe though for the case where the caller receives a REFER like this, they would want to trigger signing the SDP, and if the signature shows up broken, well, the callee then would know not to trust the calling party number. Or maybe more modestly, some other optional indication could be added to the message/signature just to warn the recipient, "hey, this was a REFER, so all bets are off." To the URL handling question, if evil.com forwards a call To sip:xyz@evil.com to gateway.com, what is the behavior we expect from gateway.com? Is it different if "xyz" is a telephone number? Our expectations is that requests will be routed differently to TNs, but this is highly implementation-specific, despite our best efforts to standardize behavior (see RFC3262 vs. RFC3824). But we may have an opportunity in defining the STIR solution to propose authorization mechanisms for gateway.com that could allow them to identify abuse more easily. Ultimately, STIR is creating an Internet service that makes it possible to figure out who has authority over telephone numbers: while we are initially using that to answer the question of who should sign requests, maybe it could also be leveraged to figure out that a call to TN3 shouldn't go to evil.com. That could be part of a REFER authorization decision at the caller, even. Jon Peterson Neustar, Inc. On 5/28/14, 1:57 PM, "Paul Kyzivat" wrote: >On 5/28/14 4:21 PM, Rosen, Brian wrote: >> Suppose a caller with TN1 is on a call with TN2, and TN2 is served by >> evil.com. >> >> If evil sends TN1 a REFER to TN3@evil.com, it should create, and sign, >> an INVITE From TN1, To TN3 and forward it to evil. >> >> Evil can then call TN3, claim it=B9s from TN1 and exploit. >> >> As a practical matter, TN1=B9s attempt to address a call to TN3@evil.com >> won=B9t actually work. The domain will get rewritten, and the call will >> be routed by TN rules, and not domains. > >I don't know if that is true or not. There are *many* ways of handling >transfer. > >In the cases I'm familiar with, some server in the domain of the party >initiating the transfer wants to remain in the signaling and media >paths. There are multiple reasons for this. Taking responsibility for >the cost of the new call is one. Keeping control for "lawful" intercept >is another. > >In those cases, if the domain in control doesn't have signing authority >for the number of the remaining party in the call, then it won't be able >to sign the new call that way. It can probably sign on behalf of the >departing party (transferrer). In some cases that may be acceptable, or >even a feature. In other cases it might be a change from current >behavior, for good or bad. > >And are we sure that there aren't any practical cases where REFER would >work without intervention? > >> But strictly speaking, an exploit like this is possible, and we should >> document it. Devices should not create random extra calls based on a >> REFER to domains they don=B9t trust. >> >> Paul Kyzivat pointed this possibility out in a discussion on how to >> handle a problem in another domain. > >Don't sell yourself short. You invented this exploit as a feature. I >just recognized it as an exploit. > > Thanks, > Paul > >_______________________________________________ >stir mailing list >stir@ietf.org >https://urldefense.proofpoint.com/v1/url?u=3Dhttps://www.ietf.org/mailman/= li >stinfo/stir&k=3DlQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=3D8DMZR2OPVO0EflFSzDaVn8= Q%2B >31F1WQyjSQmLQXwHuHE%3D%0A&m=3DdSuvTgTyCXcnEPBvLhXaCRz2UjhIJMH4ckE9L3atntk%= 3D >%0A&s=3D19d2d578965bf7e9937d402cde8b4502528251e7fd46ded654e7dd557fdf43b2 From nobody Wed May 28 18:05:12 2014 Return-Path: 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 A81321A6F1E for ; Wed, 28 May 2014 18:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 he681LgRfkkb for ; Wed, 28 May 2014 18:05:09 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4156B1A0836 for ; Wed, 28 May 2014 18:05:09 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 1c786835.2b4926823940.4678178.00-2461.12055703.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 29 May 2014 01:05:05 +0000 (UTC) X-MXL-Hash: 538687c14d8348b0-4c26cc098d7f6c5764bdc9ec318685311bff084d Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 0c786835.0.4678175.00-2308.12055681.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 29 May 2014 01:05:04 +0000 (UTC) X-MXL-Hash: 538687c07ffa0fa2-91f523292846bd339bd7e2e8d4b6a7fff9f6e5fb Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s4T153Zv012687; Wed, 28 May 2014 21:05:03 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s4T14tSF012616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 May 2014 21:04:56 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 29 May 2014 01:04:44 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0174.001; Wed, 28 May 2014 21:04:44 -0400 From: "DOLLY, MARTIN C" To: "Peterson, Jon" , Paul Kyzivat , "stir@ietf.org" Thread-Topic: [stir] A possible exploit for stir Thread-Index: AQHPerJ5w+uzXeFVlEazJOjgEY/ylJtWvI4A//+3VACAAEpGQA== Date: Thu, 29 May 2014 01:04:43 +0000 Message-ID: References: <53864DBE.4020301@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.86.127] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=HL104PRv c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=aenpGsVFPUAA:10 a=ofMgfj31e3cA:10 a=dDmyvNEpIyAA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=fLVUkWqjAAAA:8 a=BTbihv6mAAAA:8 ] X-AnalysisOut: [a=RpNjiQI2AAAA:8 a=_4XqYQbKAAAA:8 a=e_YVQg47AAAA:8 a=UAMHj] X-AnalysisOut: [508qFq9lMkUTfYA:9 a=wPNLvfGTeEIA:10 a=I4hv-x_q8dwA:10 a=uL] X-AnalysisOut: [Q8plK-Da0A:10 a=ouR-O3tdJ4wA:10 a=lZB815dzVvQA:10 a=p02eMp] X-AnalysisOut: [bfLYAA:10 a=VDW7JXH5qdZpGUqa:21 a=cl2qkniSitNHyoAz:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/stir/IcwJNYBzNvN848AZzVshpYWkYL8 Subject: Re: [stir] A possible exploit for stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 01:05:11 -0000 Typical use of REFER in managed deployments is between the UE/Enterprise an= d the Carrier AS, and it does not transverse the NNI -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, May 28, 2014 7:38 PM To: Paul Kyzivat; stir@ietf.org Subject: Re: [stir] A possible exploit for stir Yes, there are many ways of implementing and handling transfer, so many that it's difficult to get too specific about what the threat here might be. The threats document already notes that "using transfer mechanisms common in telephone systems, a callee can easily be connected to, or conferenced with, telephone numbers other than the original calling number once a call has been established." But evaluating the risks of this type of transfer will be highly solution-specific, and for the moment we're deferring solution-specific threats to the solution documents, rather than the threat document. Speculating along solution lines for a moment, this specific example begs questions about replay protection, URL handling, REFER authorization and many other issues. Any intermediary in a SIP call path can try to act as a man-in-the-middle, and what this REFER really does is to bait a call to a specific number so that an intermediary can man-in-the-middle it. We've set the scope of STIR to explicitly not address man-in-the-middle attacks, but perhaps the baiting dimension justifies addressing this. Evil's ability to cut-and-paste the Identity token in the caller's INVITE depends largely on the solution's scope of protection. It is possible to create a scope of protection for a signature which is tied to the actual source and sinks of media employed by the caller - this is the effect of signing the SDP, for example. Of course the modification of those fields by SBCs often renders this approach impractical. Maybe though for the case where the caller receives a REFER like this, they would want to trigger signing the SDP, and if the signature shows up broken, well, the callee then would know not to trust the calling party number. Or maybe more modestly, some other optional indication could be added to the message/signature just to warn the recipient, "hey, this was a REFER, so all bets are off." To the URL handling question, if evil.com forwards a call To sip:xyz@evil.com to gateway.com, what is the behavior we expect from gateway.com? Is it different if "xyz" is a telephone number? Our expectations is that requests will be routed differently to TNs, but this is highly implementation-specific, despite our best efforts to standardize behavior (see RFC3262 vs. RFC3824). But we may have an opportunity in defining the STIR solution to propose authorization mechanisms for gateway.com that could allow them to identify abuse more easily. Ultimately, STIR is creating an Internet service that makes it possible to figure out who has authority over telephone numbers: while we are initially using that to answer the question of who should sign requests, maybe it could also be leveraged to figure out that a call to TN3 shouldn't go to evil.com. That could be part of a REFER authorization decision at the caller, even. Jon Peterson Neustar, Inc. On 5/28/14, 1:57 PM, "Paul Kyzivat" wrote: >On 5/28/14 4:21 PM, Rosen, Brian wrote: >> Suppose a caller with TN1 is on a call with TN2, and TN2 is served by >> evil.com. >> >> If evil sends TN1 a REFER to TN3@evil.com, it should create, and sign, >> an INVITE From TN1, To TN3 and forward it to evil. >> >> Evil can then call TN3, claim it=B9s from TN1 and exploit. >> >> As a practical matter, TN1=B9s attempt to address a call to TN3@evil.com >> won=B9t actually work. The domain will get rewritten, and the call will >> be routed by TN rules, and not domains. > >I don't know if that is true or not. There are *many* ways of handling >transfer. > >In the cases I'm familiar with, some server in the domain of the party >initiating the transfer wants to remain in the signaling and media >paths. There are multiple reasons for this. Taking responsibility for >the cost of the new call is one. Keeping control for "lawful" intercept >is another. > >In those cases, if the domain in control doesn't have signing authority >for the number of the remaining party in the call, then it won't be able >to sign the new call that way. It can probably sign on behalf of the >departing party (transferrer). In some cases that may be acceptable, or >even a feature. In other cases it might be a change from current >behavior, for good or bad. > >And are we sure that there aren't any practical cases where REFER would >work without intervention? > >> But strictly speaking, an exploit like this is possible, and we should >> document it. Devices should not create random extra calls based on a >> REFER to domains they don=B9t trust. >> >> Paul Kyzivat pointed this possibility out in a discussion on how to >> handle a problem in another domain. > >Don't sell yourself short. You invented this exploit as a feature. I >just recognized it as an exploit. > > Thanks, > Paul > >_______________________________________________ >stir mailing list >stir@ietf.org >https://urldefense.proofpoint.com/v1/url?u=3Dhttps://www.ietf.org/mailman/= li >stinfo/stir&k=3DlQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=3D8DMZR2OPVO0EflFSzDaVn8= Q%2B >31F1WQyjSQmLQXwHuHE%3D%0A&m=3DdSuvTgTyCXcnEPBvLhXaCRz2UjhIJMH4ckE9L3atntk%= 3D >%0A&s=3D19d2d578965bf7e9937d402cde8b4502528251e7fd46ded654e7dd557fdf43b2 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Thu May 29 07:32:11 2014 Return-Path: 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 9CC6B1A097A for ; Thu, 29 May 2014 07:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 sM6759CPqg2f for ; Thu, 29 May 2014 07:32:07 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id D58921A014D for ; Thu, 29 May 2014 07:32:06 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta05.westchester.pa.mail.comcast.net with comcast id 7nry1o0041ei1Bg55qY2p3; Thu, 29 May 2014 14:32:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 7qY21o00f3ZTu2S3kqY27b; Thu, 29 May 2014 14:32:02 +0000 Message-ID: <538744E2.3080806@alum.mit.edu> Date: Thu, 29 May 2014 10:32:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "DOLLY, MARTIN C" , "Peterson, Jon" , "stir@ietf.org" References: <53864DBE.4020301@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401373922; bh=xM6VHicbgOjK17DLXb5Qt3KBM4CBhAVunxSmlUevrq4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=i+4e4OLJTYuYoOSXlEzw1qis8DFNdn7u3IXS+3X9b1i23NMUjenakMg7c5JJ0dGLU xx9/O8bxS/K/yAJ/z4LZzskmBH0aAPI+TQKXIsmUgwauFBJvdGY1T+m4I3C/NaKw2n Ofh1N1rLDRTWLBtrtGP4kQjONlrCTovDtrdXDoWvctA3p19VUJu+oRvb9v1g8uTDSG htDjDdqy1sUPuE3xLxEGZExTCo4FmupyR/dnjC9FQ8kCPW7rpO4G0SWc3bhIS+7mZe pE1SpImTX4qu9kUrrOX2lqiy5IdpQ/sSEJ2pqLY9WEf/Wb1Em8vrY85l6dOrd9xHp2 i2RoeFtKvcs1A== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/h-xIA_c-fXw1t7L0huLmFwm5hNc Subject: Re: [stir] A possible exploit for stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:32:08 -0000 Martin, On 5/28/14 9:04 PM, DOLLY, MARTIN C wrote: > Typical use of REFER in managed deployments is between the UE/Enterprise and the Carrier AS, and it does not transverse the NNI Can you explain in a little more detail? Are you describing the same approach I mentioned earlier in this thread? (Repeating that:) > In the cases I'm familiar with, some server in the domain of the party > initiating the transfer wants to remain in the signaling and media > paths. There are multiple reasons for this. Taking responsibility for > the cost of the new call is one. Keeping control for "lawful" intercept > is another. > > In those cases, if the domain in control doesn't have signing authority > for the number of the remaining party in the call, then it won't be > able to sign the new call that way. It can probably sign on behalf of > the departing party (transferrer). In some cases that may be > acceptable, or even a feature. In other cases it might be a change from > current behavior, for good or bad. IMO this is a fine approach, if it provides the semantics that the transferring party wants. But it constrains what sort of signing is possible. In particular, is it sufficient that the transferred-to party doesn't see the identity of the party to which he will be speaking? Thanks, Paul > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Wednesday, May 28, 2014 7:38 PM > To: Paul Kyzivat; stir@ietf.org > Subject: Re: [stir] A possible exploit for stir > > > Yes, there are many ways of implementing and handling transfer, so many > that it's difficult to get too specific about what the threat here might > be. The threats document already notes that "using transfer mechanisms > common in telephone systems, a callee can easily be connected to, or > conferenced with, telephone numbers other than the original calling number > once a call has been established." But evaluating the risks of this type > of transfer will be highly solution-specific, and for the moment we're > deferring solution-specific threats to the solution documents, rather than > the threat document. > > Speculating along solution lines for a moment, this specific example begs > questions about replay protection, URL handling, REFER authorization and > many other issues. Any intermediary in a SIP call path can try to act as a > man-in-the-middle, and what this REFER really does is to bait a call to a > specific number so that an intermediary can man-in-the-middle it. We've > set the scope of STIR to explicitly not address man-in-the-middle attacks, > but perhaps the baiting dimension justifies addressing this. > > Evil's ability to cut-and-paste the Identity token in the caller's INVITE > depends largely on the solution's scope of protection. It is possible to > create a scope of protection for a signature which is tied to the actual > source and sinks of media employed by the caller - this is the effect of > signing the SDP, for example. Of course the modification of those fields > by SBCs often renders this approach impractical. Maybe though for the case > where the caller receives a REFER like this, they would want to trigger > signing the SDP, and if the signature shows up broken, well, the callee > then would know not to trust the calling party number. Or maybe more > modestly, some other optional indication could be added to the > message/signature just to warn the recipient, "hey, this was a REFER, so > all bets are off." > > To the URL handling question, if evil.com forwards a call To > sip:xyz@evil.com to gateway.com, what is the behavior we expect from > gateway.com? Is it different if "xyz" is a telephone number? Our > expectations is that requests will be routed differently to TNs, but this > is highly implementation-specific, despite our best efforts to standardize > behavior (see RFC3262 vs. RFC3824). But we may have an opportunity in > defining the STIR solution to propose authorization mechanisms for > gateway.com that could allow them to identify abuse more easily. > Ultimately, STIR is creating an Internet service that makes it possible to > figure out who has authority over telephone numbers: while we are > initially using that to answer the question of who should sign requests, > maybe it could also be leveraged to figure out that a call to TN3 > shouldn't go to evil.com. That could be part of a REFER authorization > decision at the caller, even. > > Jon Peterson > Neustar, Inc. > > On 5/28/14, 1:57 PM, "Paul Kyzivat" wrote: > >> On 5/28/14 4:21 PM, Rosen, Brian wrote: >>> Suppose a caller with TN1 is on a call with TN2, and TN2 is served by >>> evil.com. >>> >>> If evil sends TN1 a REFER to TN3@evil.com, it should create, and sign, >>> an INVITE From TN1, To TN3 and forward it to evil. >>> >>> Evil can then call TN3, claim it¹s from TN1 and exploit. >>> >>> As a practical matter, TN1¹s attempt to address a call to TN3@evil.com >>> won¹t actually work. The domain will get rewritten, and the call will >>> be routed by TN rules, and not domains. >> >> I don't know if that is true or not. There are *many* ways of handling >> transfer. >> >> In the cases I'm familiar with, some server in the domain of the party >> initiating the transfer wants to remain in the signaling and media >> paths. There are multiple reasons for this. Taking responsibility for >> the cost of the new call is one. Keeping control for "lawful" intercept >> is another. >> >> In those cases, if the domain in control doesn't have signing authority >> for the number of the remaining party in the call, then it won't be able >> to sign the new call that way. It can probably sign on behalf of the >> departing party (transferrer). In some cases that may be acceptable, or >> even a feature. In other cases it might be a change from current >> behavior, for good or bad. >> >> And are we sure that there aren't any practical cases where REFER would >> work without intervention? >> >>> But strictly speaking, an exploit like this is possible, and we should >>> document it. Devices should not create random extra calls based on a >>> REFER to domains they don¹t trust. >>> >>> Paul Kyzivat pointed this possibility out in a discussion on how to >>> handle a problem in another domain. >> >> Don't sell yourself short. You invented this exploit as a feature. I >> just recognized it as an exploit. >> >> Thanks, >> Paul >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/li >> stinfo/stir&k=lQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=8DMZR2OPVO0EflFSzDaVn8Q%2B >> 31F1WQyjSQmLQXwHuHE%3D%0A&m=dSuvTgTyCXcnEPBvLhXaCRz2UjhIJMH4ckE9L3atntk%3D >> %0A&s=19d2d578965bf7e9937d402cde8b4502528251e7fd46ded654e7dd557fdf43b2 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From nobody Thu May 29 08:27:11 2014 Return-Path: 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 B46E41A09BC for ; Thu, 29 May 2014 08:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 zhtQHfGhlThl for ; Thu, 29 May 2014 08:27:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CE51A09D8 for ; Thu, 29 May 2014 08:27:08 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:56409 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Wq2Ec-000NLY-Fn for stir@ietf.org; Thu, 29 May 2014 11:27:14 -0400 Message-ID: <538751C6.5010602@bbn.com> Date: Thu, 29 May 2014 11:27:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: stir@ietf.org References: <53864DBE.4020301@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/P3tJyJqjWHrfv1jEc1fbetGzzAE Subject: Re: [stir] A possible exploit for stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:27:09 -0000 Jon, You identified the central security issue here. One should always include the intended target of a signed "thing" under the signature, to avoid re-direction attacks. This is a common security design principle and needs to be part of the STIR design, as a matter of good practice. (The source is usually identified anyway, because that's needed to select the right credential to verify the sig.) Sorry I didn't jump in immediately when Brian posted his message. Steve From nobody Thu May 29 09:24:06 2014 Return-Path: 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 5ACAD1A08A5 for ; Thu, 29 May 2014 09:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 uFxWSjUyXhX0 for ; Thu, 29 May 2014 09:23:59 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C801A0177 for ; Thu, 29 May 2014 09:23:59 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id 63so1662662qgz.16 for ; Thu, 29 May 2014 09:23:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Gpr66CoqeGbEPoIsM8M+jCtWXYiO1TNXM8KEbkSqmGo=; b=Pwdzcdjn1/ZDz68hJzkh2VpjJwRROpxAC7eLpI/sghNnCTbDLwHfmCqifXUyH+FMEg flntvGlRJ8/+OlLuVD+1kiygXMoCZoQiUqNYDojuJQGLyBaR3F6mNPrI34iga925YtqD UOOvRqlkW+rZ6sqtxWVe+ns8w/yXVTEVwnC3Jsg8iG9xKjtFo0eQqZoKZ9FaR4blVUI4 bLRDXDJICdIJUfnSZvpVIcYn2qfFj5oLXY5/zYQZYAS9ZRN78mt5T5GBgkK86I9ePKCp cwPKfRv5W7+xYO68v0omgnkzzW/A8cTtI8ge25e4wM1tCjFgeBvaMRy/3izFCuAehAHh 7i1Q== X-Gm-Message-State: ALoCoQnzFrERNtGJan2eMlrgkU5kA1K1tLz/vn7jiRrl+ARcmGiXxIJJSaOuLCJOCpYrTT++DLf0 X-Received: by 10.140.33.181 with SMTP id j50mr11012779qgj.81.1401380635318; Thu, 29 May 2014 09:23:55 -0700 (PDT) Received: from [10.33.192.21] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id b10sm1652274qag.31.2014.05.29.09.23.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 09:23:54 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Rosen In-Reply-To: Date: Thu, 29 May 2014 12:23:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <01DA1036-4F01-4675-8750-A32EFE4BAF82@brianrosen.net> References: <53864DBE.4020301@alum.mit.edu> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/vZK7PcS58j6nR0AH8AIQ6JooRAs Cc: "stir@ietf.org" , Paul Kyzivat , Jon Peterson Subject: Re: [stir] A possible exploit for stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:24:01 -0000 That doesn=92t help. A legitimate transfer has the same signaling, and would work. If TN1 = calls TN2 and TN2 desires to transfer the call to TN3, it sends a REFER = to TN1 to do that. TN1 responds with an INVITE to TN3. Doesn=92t = matter if the phone or some B2BUA handles the transfer, it has the same = effect. If evil negotiates the media in that replacement call to replicate what = is already in place for TN1 to TN2, neither party will be aware of any = change. But then evil can create a new call from anyone to TN3, claim it=92s = from TN1 and have the correct signature. Brian On May 28, 2014, at 9:04 PM, DOLLY, MARTIN C wrote: > Typical use of REFER in managed deployments is between the = UE/Enterprise and the Carrier AS, and it does not transverse the NNI >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Wednesday, May 28, 2014 7:38 PM > To: Paul Kyzivat; stir@ietf.org > Subject: Re: [stir] A possible exploit for stir >=20 >=20 > Yes, there are many ways of implementing and handling transfer, so = many > that it's difficult to get too specific about what the threat here = might > be. The threats document already notes that "using transfer mechanisms > common in telephone systems, a callee can easily be connected to, or > conferenced with, telephone numbers other than the original calling = number > once a call has been established." But evaluating the risks of this = type > of transfer will be highly solution-specific, and for the moment we're > deferring solution-specific threats to the solution documents, rather = than > the threat document. >=20 > Speculating along solution lines for a moment, this specific example = begs > questions about replay protection, URL handling, REFER authorization = and > many other issues. Any intermediary in a SIP call path can try to act = as a > man-in-the-middle, and what this REFER really does is to bait a call = to a > specific number so that an intermediary can man-in-the-middle it. = We've > set the scope of STIR to explicitly not address man-in-the-middle = attacks, > but perhaps the baiting dimension justifies addressing this. >=20 > Evil's ability to cut-and-paste the Identity token in the caller's = INVITE > depends largely on the solution's scope of protection. It is possible = to > create a scope of protection for a signature which is tied to the = actual > source and sinks of media employed by the caller - this is the effect = of > signing the SDP, for example. Of course the modification of those = fields > by SBCs often renders this approach impractical. Maybe though for the = case > where the caller receives a REFER like this, they would want to = trigger > signing the SDP, and if the signature shows up broken, well, the = callee > then would know not to trust the calling party number. Or maybe more > modestly, some other optional indication could be added to the > message/signature just to warn the recipient, "hey, this was a REFER, = so > all bets are off." >=20 > To the URL handling question, if evil.com forwards a call To > sip:xyz@evil.com to gateway.com, what is the behavior we expect from > gateway.com? Is it different if "xyz" is a telephone number? Our > expectations is that requests will be routed differently to TNs, but = this > is highly implementation-specific, despite our best efforts to = standardize > behavior (see RFC3262 vs. RFC3824). But we may have an opportunity in > defining the STIR solution to propose authorization mechanisms for > gateway.com that could allow them to identify abuse more easily. > Ultimately, STIR is creating an Internet service that makes it = possible to > figure out who has authority over telephone numbers: while we are > initially using that to answer the question of who should sign = requests, > maybe it could also be leveraged to figure out that a call to TN3 > shouldn't go to evil.com. That could be part of a REFER authorization > decision at the caller, even. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 5/28/14, 1:57 PM, "Paul Kyzivat" wrote: >=20 >> On 5/28/14 4:21 PM, Rosen, Brian wrote: >>> Suppose a caller with TN1 is on a call with TN2, and TN2 is served = by >>> evil.com. >>>=20 >>> If evil sends TN1 a REFER to TN3@evil.com, it should create, and = sign, >>> an INVITE =46rom TN1, To TN3 and forward it to evil. >>>=20 >>> Evil can then call TN3, claim it=B9s from TN1 and exploit. >>>=20 >>> As a practical matter, TN1=B9s attempt to address a call to = TN3@evil.com >>> won=B9t actually work. The domain will get rewritten, and the call = will >>> be routed by TN rules, and not domains. >>=20 >> I don't know if that is true or not. There are *many* ways of = handling >> transfer. >>=20 >> In the cases I'm familiar with, some server in the domain of the = party >> initiating the transfer wants to remain in the signaling and media >> paths. There are multiple reasons for this. Taking responsibility for >> the cost of the new call is one. Keeping control for "lawful" = intercept >> is another. >>=20 >> In those cases, if the domain in control doesn't have signing = authority >> for the number of the remaining party in the call, then it won't be = able >> to sign the new call that way. It can probably sign on behalf of the >> departing party (transferrer). In some cases that may be acceptable, = or >> even a feature. In other cases it might be a change from current >> behavior, for good or bad. >>=20 >> And are we sure that there aren't any practical cases where REFER = would >> work without intervention? >>=20 >>> But strictly speaking, an exploit like this is possible, and we = should >>> document it. Devices should not create random extra calls based on = a >>> REFER to domains they don=B9t trust. >>>=20 >>> Paul Kyzivat pointed this possibility out in a discussion on how to >>> handle a problem in another domain. >>=20 >> Don't sell yourself short. You invented this exploit as a feature. I >> just recognized it as an exploit. >>=20 >> Thanks, >> Paul >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> = https://urldefense.proofpoint.com/v1/url?u=3Dhttps://www.ietf.org/mailman/= li >> = stinfo/stir&k=3DlQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=3D8DMZR2OPVO0EflFSzDaVn8= Q%2B >> = 31F1WQyjSQmLQXwHuHE%3D%0A&m=3DdSuvTgTyCXcnEPBvLhXaCRz2UjhIJMH4ckE9L3atntk%= 3D >> = %0A&s=3D19d2d578965bf7e9937d402cde8b4502528251e7fd46ded654e7dd557fdf43b2 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu May 29 09:36:37 2014 Return-Path: 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 9D4681A0182 for ; Thu, 29 May 2014 09:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 RadLvWffChZg for ; Thu, 29 May 2014 09:36:33 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80891A0177 for ; Thu, 29 May 2014 09:36:33 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id a108so1752154qge.11 for ; Thu, 29 May 2014 09:36:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=te0/HUI/ZYsjxAhZyUU5KKPE/BDnpvbzeBHNN7ryU7k=; b=i/euAW4QRYJCHL6fbTXQRWscnTvfVB1k9EiMd1YLbWioNOvAxQvVtrpG+yRXvrnd5q dkgugErONWYw31o00+chgAun7r5Grftg3ZKHSdW8Ipcths76Xcs+n0ZLf3Oxizv7Tp6O 5YM6CBf9sDHUmdJEobGP6NXjIc6Uczd8LbohAMpI7fIPL2fVpYebLFORH7ni2gZwW2kd vhUK1LYqX1xTdZZGOj1pn0hYo6pMh5ShTJz8AGsVKLXBPTbT3JdmTb2vvQDXqxbkuzH+ o21qZyVrWSq2740R8kNqQi+V3Dd+PWVmRkwBrmVMcKRfskov1aqtPfFR9g0vtD/i7f9z kkAA== X-Gm-Message-State: ALoCoQmQj4IqBagBmiu128w69MbaJYwgZb/mNazdvgsn/SNHvCqYEX62zxMzB6uvNnw8M9vXNMDW X-Received: by 10.140.49.171 with SMTP id q40mr11558627qga.7.1401381389155; Thu, 29 May 2014 09:36:29 -0700 (PDT) Received: from [10.33.192.21] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id y3sm1688574qaj.49.2014.05.29.09.36.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 09:36:28 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Rosen In-Reply-To: <538751C6.5010602@bbn.com> Date: Thu, 29 May 2014 12:36:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4B953965-0494-4232-B21B-DD3A42B464B2@brianrosen.net> References: <53864DBE.4020301@alum.mit.edu> <538751C6.5010602@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/7LDrPmIQaXXY9RFbDmGlfd95rM4 Cc: stir@ietf.org Subject: Re: [stir] A possible exploit for stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:36:35 -0000 So, this problem is wrapped up in how domains and telephone numbers = interact. As a practical matter, we usually represent telephone numbers = as sip:+12025551212@example.com;user=3Dphone. In some sense, the domain of this SIP URI is usually ignored. When the = origination service provider sees that construction, it treats it as a = phone number. The practical matter for most domains is that if you = managed to get a subscriber, or proxy, in example.com=92s domain, a uri = of sip:+12025551212@evil.com;user=3Dphone, it is almost a certainty that = somewhere in example.com that URI is going to be changed, or just = ignored. example.com will route the call by phone number, using number = based routing decisions and not domain based decisions. If the = =93user=3Dphone=94 part wasn=92t there, at least in theory, the call = would be routed to evil, because the origination domain would assume = it=92s a normal sip URI with domain based routing that just happened to = have a user with that string. As a practical matter, I think that most = service providers would reject such a call, or treat it as a telephone = number and apply number based routing. The way STIR works is that we canonicalize the TN. We expressly ignore = the domain, no matter what it is. So = sip:+12025551212@example.com;user=3Dphone, and = sip:+12025551212@evil.com;user=3Dphone will generate the same digest, = because we extract the telephone number and ignore the rest. That is = essential to deal with how number based routing really works. The problem arises only if the origination domain will route the call = using domain based routing to evil. If it doesn=92t do that, and = instead either rejects the call or ignores/rewrites the domain, then the = exploit will fail. If I were evil, I would try to REFER to sip:2025551212@evil.com. That = has the best chance of making it to evil. If it did, it could rewrite = it to sip:+12025551212@anyone.com;user=3Dphone, and have the signature = work. Brian On May 29, 2014, at 11:27 AM, Stephen Kent wrote: > Jon, >=20 > You identified the central security issue here. >=20 > One should always include the intended target of a signed "thing" > under the signature, to avoid re-direction attacks. This is a common > security design principle and needs to be part of the STIR design, as = a matter > of good practice. (The source is usually identified anyway, because = that's needed > to select the right credential to verify the sig.) >=20 > Sorry I didn't jump in immediately when Brian posted his message. >=20 > Steve >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu May 29 11:25:10 2014 Return-Path: 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 BCD2B1A09F4 for ; Thu, 29 May 2014 11:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_45=0.6, SPF_SOFTFAIL=0.665] autolearn=no 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 Gwdu1a9ZPjff for ; Thu, 29 May 2014 11:25:08 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 18DB91A0537 for ; Thu, 29 May 2014 11:25:08 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta15.westchester.pa.mail.comcast.net with comcast id 7qyq1o00B0cZkys5FuR4en; Thu, 29 May 2014 18:25:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id 7uR31o00f3ZTu2S3WuR3l1; Thu, 29 May 2014 18:25:04 +0000 Message-ID: <53877B7F.4020405@alum.mit.edu> Date: Thu, 29 May 2014 14:25:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: stir@ietf.org References: <53864DBE.4020301@alum.mit.edu> <538751C6.5010602@bbn.com> <4B953965-0494-4232-B21B-DD3A42B464B2@brianrosen.net> In-Reply-To: <4B953965-0494-4232-B21B-DD3A42B464B2@brianrosen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401387904; bh=ZJ+zbXTf8QV4nbaO9AWaIAvpaoyhMBd+fyQi97Mt7bA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SPCs2VQs3spSYkQWWe9QSvFj6MyjpoavwPRlEJnBMJTmz1RxTpLMlT0TSXHtQnhbm 4CW+io1psSVv7vV6qinZZSSj0qQTt08e3q5brZfr5Jkjtb5u+kNglYTuRMOgAGeU1c snD1GuslmezT24WgiRV8+Wzhh6OOAONRJwA3O7yNZ5lojiQduvoAoZXLFQ9zgegLq0 FC7rnyBndYa63WLuM9rr4fYvFj0bpj3ZrNR0EWsmUAY05+D/Gvb4PRcajpvI5mFzlx q6IEWJjOjtDbvaupdJ8pt3sX7DTAq3+ob82/BMCty3uRHy+twV9UHRz3nCFUKNmKLL CDwD94ab87LEg== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/QHUW7Wz_SQYdHQiRiWAagAhi6mw Subject: Re: [stir] A possible exploit for stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:25:09 -0000 On 5/29/14 12:36 PM, Brian Rosen wrote: > So, this problem is wrapped up in how domains and telephone numbers interact. As a practical matter, we usually represent telephone numbers as sip:+12025551212@example.com;user=phone. > > In some sense, the domain of this SIP URI is usually ignored. When the origination service provider sees that construction, it treats it as a phone number. The practical matter for most domains is that if you managed to get a subscriber, or proxy, in example.com’s domain, a uri of sip:+12025551212@evil.com;user=phone, it is almost a certainty that somewhere in example.com that URI is going to be changed, or just ignored. example.com will route the call by phone number, using number based routing decisions and not domain based decisions. If the “user=phone” part wasn’t there, at least in theory, the call would be routed to evil, because the origination domain would assume it’s a normal sip URI with domain based routing that just happened to have a user with that string. As a practical matter, I think that most service providers would reject such a call, or treat it as a telephone number and apply number based routing. This describes the perversion of SIP that has taken place. According to 3261 a request URI of sip:+12025551212@evil.com;user=phone is to be routed to evil.com. The interpretation of the user part as a phone number may *then* be done, and user=phone may be taken into account when doing that. Ignoring the domain is an abuse of sip. Unfortunately it is one that is so pervasive that it seems impossible to "fix". This means that we are left to decide what must be supported, and what need not be supported, without any written rules for what is correct and what is not. Thanks, Paul > The way STIR works is that we canonicalize the TN. We expressly ignore the domain, no matter what it is. So sip:+12025551212@example.com;user=phone, and sip:+12025551212@evil.com;user=phone will generate the same digest, because we extract the telephone number and ignore the rest. That is essential to deal with how number based routing really works. > > The problem arises only if the origination domain will route the call using domain based routing to evil. If it doesn’t do that, and instead either rejects the call or ignores/rewrites the domain, then the exploit will fail. > > If I were evil, I would try to REFER to sip:2025551212@evil.com. That has the best chance of making it to evil. If it did, it could rewrite it to sip:+12025551212@anyone.com;user=phone, and have the signature work. > > Brian > > On May 29, 2014, at 11:27 AM, Stephen Kent wrote: > >> Jon, >> >> You identified the central security issue here. >> >> One should always include the intended target of a signed "thing" >> under the signature, to avoid re-direction attacks. This is a common >> security design principle and needs to be part of the STIR design, as a matter >> of good practice. (The source is usually identified anyway, because that's needed >> to select the right credential to verify the sig.) >> >> Sorry I didn't jump in immediately when Brian posted his message. >> >> Steve >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From nobody Sat May 31 07:38:39 2014 Return-Path: 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 7AE7E1A08DA for ; Sat, 31 May 2014 07:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 d7H0J-Xn6YXu for ; Sat, 31 May 2014 07:38:08 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9D11A08C9 for ; Sat, 31 May 2014 07:38:08 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id c49e9835.2b5ef8a73940.6502094.00-2467.17962928.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 31 May 2014 14:38:04 +0000 (UTC) X-MXL-Hash: 5389e94c2ef97e11-6d6a3bad5e3caa17c2a13ed87e31c676c5e66468 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id a49e9835.0.6502053.00-2050.17962845.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 31 May 2014 14:38:03 +0000 (UTC) X-MXL-Hash: 5389e94b6f958a83-56c5b2932d205e8331130ef65cb47f8b719d09a7 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s4VEc1Bd020848; Sat, 31 May 2014 10:38:01 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s4VEbudC020830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 10:37:57 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sat, 31 May 2014 14:37:41 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0174.001; Sat, 31 May 2014 10:37:40 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat , "Peterson, Jon" , "stir@ietf.org" Thread-Topic: [stir] A possible exploit for stir Thread-Index: AQHPerJ5w+uzXeFVlEazJOjgEY/ylJtWvI4A//+3VACAAEpGQIABJQQAgALjAJA= Date: Sat, 31 May 2014 14:37:40 +0000 Message-ID: References: <53864DBE.4020301@alum.mit.edu> <538744E2.3080806@alum.mit.edu> In-Reply-To: <538744E2.3080806@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.87.185] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=DOA4FVxb c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=aenpGsVFPUAA:10 a=ofMgfj31e3cA:10 a=aCVcjY7ioRkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=fLVUkWqjAAAA:8 a=BTbihv6mAAAA:8 ] X-AnalysisOut: [a=RpNjiQI2AAAA:8 a=rkKFn_yPZFkfbxda3l8A:9 a=wPNLvfGTeEIA:1] X-AnalysisOut: [0 a=uLQ8plK-Da0A:10 a=ouR-O3tdJ4wA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [p02eMpbfLYAA:10 a=2LGKKuRwBDSDEKf7:21 a=dYe5HNfJsg_D-a7i:2] X-AnalysisOut: [1] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/stir/9p0vKIlmt9HSkC3IFUnud-Xsx2w Subject: Re: [stir] A possible exploit for stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 14:38:29 -0000 Paul Yes. Sorry I missed it Martin -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, May 29, 2014 10:32 AM To: DOLLY, MARTIN C; Peterson, Jon; stir@ietf.org Subject: Re: [stir] A possible exploit for stir Martin, On 5/28/14 9:04 PM, DOLLY, MARTIN C wrote: > Typical use of REFER in managed deployments is between the UE/Enterprise = and the Carrier AS, and it does not transverse the NNI Can you explain in a little more detail? Are you describing the same approach I mentioned earlier in this thread? (Repeating that:) > In the cases I'm familiar with, some server in the domain of the party > initiating the transfer wants to remain in the signaling and media > paths. There are multiple reasons for this. Taking responsibility for > the cost of the new call is one. Keeping control for "lawful" intercept > is another. > > In those cases, if the domain in control doesn't have signing authority > for the number of the remaining party in the call, then it won't be > able to sign the new call that way. It can probably sign on behalf of > the departing party (transferrer). In some cases that may be > acceptable, or even a feature. In other cases it might be a change from > current behavior, for good or bad. IMO this is a fine approach, if it provides the semantics that the=20 transferring party wants. But it constrains what sort of signing is=20 possible. In particular, is it sufficient that the transferred-to party doesn't=20 see the identity of the party to which he will be speaking? Thanks, Paul > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon > Sent: Wednesday, May 28, 2014 7:38 PM > To: Paul Kyzivat; stir@ietf.org > Subject: Re: [stir] A possible exploit for stir > > > Yes, there are many ways of implementing and handling transfer, so many > that it's difficult to get too specific about what the threat here might > be. The threats document already notes that "using transfer mechanisms > common in telephone systems, a callee can easily be connected to, or > conferenced with, telephone numbers other than the original calling numbe= r > once a call has been established." But evaluating the risks of this type > of transfer will be highly solution-specific, and for the moment we're > deferring solution-specific threats to the solution documents, rather tha= n > the threat document. > > Speculating along solution lines for a moment, this specific example begs > questions about replay protection, URL handling, REFER authorization and > many other issues. Any intermediary in a SIP call path can try to act as = a > man-in-the-middle, and what this REFER really does is to bait a call to a > specific number so that an intermediary can man-in-the-middle it. We've > set the scope of STIR to explicitly not address man-in-the-middle attacks= , > but perhaps the baiting dimension justifies addressing this. > > Evil's ability to cut-and-paste the Identity token in the caller's INVITE > depends largely on the solution's scope of protection. It is possible to > create a scope of protection for a signature which is tied to the actual > source and sinks of media employed by the caller - this is the effect of > signing the SDP, for example. Of course the modification of those fields > by SBCs often renders this approach impractical. Maybe though for the cas= e > where the caller receives a REFER like this, they would want to trigger > signing the SDP, and if the signature shows up broken, well, the callee > then would know not to trust the calling party number. Or maybe more > modestly, some other optional indication could be added to the > message/signature just to warn the recipient, "hey, this was a REFER, so > all bets are off." > > To the URL handling question, if evil.com forwards a call To > sip:xyz@evil.com to gateway.com, what is the behavior we expect from > gateway.com? Is it different if "xyz" is a telephone number? Our > expectations is that requests will be routed differently to TNs, but this > is highly implementation-specific, despite our best efforts to standardiz= e > behavior (see RFC3262 vs. RFC3824). But we may have an opportunity in > defining the STIR solution to propose authorization mechanisms for > gateway.com that could allow them to identify abuse more easily. > Ultimately, STIR is creating an Internet service that makes it possible t= o > figure out who has authority over telephone numbers: while we are > initially using that to answer the question of who should sign requests, > maybe it could also be leveraged to figure out that a call to TN3 > shouldn't go to evil.com. That could be part of a REFER authorization > decision at the caller, even. > > Jon Peterson > Neustar, Inc. > > On 5/28/14, 1:57 PM, "Paul Kyzivat" wrote: > >> On 5/28/14 4:21 PM, Rosen, Brian wrote: >>> Suppose a caller with TN1 is on a call with TN2, and TN2 is served by >>> evil.com. >>> >>> If evil sends TN1 a REFER to TN3@evil.com, it should create, and sign, >>> an INVITE From TN1, To TN3 and forward it to evil. >>> >>> Evil can then call TN3, claim it=B9s from TN1 and exploit. >>> >>> As a practical matter, TN1=B9s attempt to address a call to TN3@evil.co= m >>> won=B9t actually work. The domain will get rewritten, and the call wil= l >>> be routed by TN rules, and not domains. >> >> I don't know if that is true or not. There are *many* ways of handling >> transfer. >> >> In the cases I'm familiar with, some server in the domain of the party >> initiating the transfer wants to remain in the signaling and media >> paths. There are multiple reasons for this. Taking responsibility for >> the cost of the new call is one. Keeping control for "lawful" intercept >> is another. >> >> In those cases, if the domain in control doesn't have signing authority >> for the number of the remaining party in the call, then it won't be able >> to sign the new call that way. It can probably sign on behalf of the >> departing party (transferrer). In some cases that may be acceptable, or >> even a feature. In other cases it might be a change from current >> behavior, for good or bad. >> >> And are we sure that there aren't any practical cases where REFER would >> work without intervention? >> >>> But strictly speaking, an exploit like this is possible, and we should >>> document it. Devices should not create random extra calls based on a >>> REFER to domains they don=B9t trust. >>> >>> Paul Kyzivat pointed this possibility out in a discussion on how to >>> handle a problem in another domain. >> >> Don't sell yourself short. You invented this exploit as a feature. I >> just recognized it as an exploit. >> >> Thanks, >> Paul >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://urldefense.proofpoint.com/v1/url?u=3Dhttps://www.ietf.org/mailma= n/li >> stinfo/stir&k=3DlQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=3D8DMZR2OPVO0EflFSzDaV= n8Q%2B >> 31F1WQyjSQmLQXwHuHE%3D%0A&m=3DdSuvTgTyCXcnEPBvLhXaCRz2UjhIJMH4ckE9L3atnt= k%3D >> %0A&s=3D19d2d578965bf7e9937d402cde8b4502528251e7fd46ded654e7dd557fdf43b2 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir