From jon.peterson@neustar.biz Fri Nov 1 09:27:27 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC8511E810E for ; Fri, 1 Nov 2013 09:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.211 X-Spam-Level: X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfiPooo0AwlD for ; Fri, 1 Nov 2013 09:27:23 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9212F21E805D for ; Fri, 1 Nov 2013 09:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383323305; x=1698672028; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=F9F5dadAc9 ILAP2ZspK3dj2iPDYafymazJsFPFjptcM=; b=fimd5DqmDhNlJB1aMC78Kneglw qdFTevVFO/mBujXDoYc2+pgV8yTjvZkjG/FGer6yx08cRLCMXv4jrFs20Ysg== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.33114469; Fri, 01 Nov 2013 12:28:24 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 1 Nov 2013 12:25:37 -0400 From: "Peterson, Jon" To: Richard Shockey , 'Stephen Kent' , "stir@ietf.org" Thread-Topic: [stir] comment on draft-jennings-stir-rfc4474bis-00 Thread-Index: AQHO1YA+rzAZsOMgK0iWox7fcLd6G5oNQEOAgACG74D//5XoAIABzWEA//+egACAAJK3gP//k2kAABKkhIAABJkLAAAW9LgA Date: Fri, 1 Nov 2013 16:25:36 +0000 Message-ID: In-Reply-To: <024a01ced688$7e3a9d70$7aafd850$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.128.141] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 7SkPA5FuOpWTyX+XKrC5uQ== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:27:27 -0000 I suspect Rich is right that we are in a position to make credible recommendations about credential distribution and management, but that if we are serious about tying these credential structures to the national authorities, then it will be those authorities and their various industry bodies that make the ultimate decisions here. Consequently the situation is fluid, and difficult to anticipate. Which is a good reason for a modular design. Jon Peterson Neustar, Inc. On 10/31/13 3:28 PM, "Richard Shockey" wrote: >I would strongly caution that issues surrounding the E.164 numbering plan >and the databases that enable them are in fact national specific issues >enabled in law.=20 > >We only may be able to make Recommendations on implementation of STIR key >management structures we may not be able to impose them. > >This is a fluid situation at this point. To be blunt I'm not sure what is >the best recommendation or course of action we can make to the NRA's. As >you point out the record on PKI is mixed. That said number assignment >authorities and those that receive the resource are a more limited and >restricted subset and that may actually work to our advantage. > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Stephen Kent >Sent: Thursday, October 31, 2013 4:17 PM >To: Peterson, Jon; stir@ietf.org >Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00 > >Jon, > >> I think we're mostly on the same page here, though the question of >> whether something like web PKI is still relevant largely depends on >> how real we think DANE is. No question that it would be better, and >> that the warts of web PKI grow increasingly ugly. But I haven't heard >> a lot of enthusiasm from browser vendors, say, about DANE (I haven't >> taken this temperature super recently, though, so that may just be >> stale information). I also think that despite its warts, the world is >> still better off with web PKI today than it would be if it all went away >with nothing to replace it. >> >> I'm not sure I could predict with total certainty where the market is >> going to go with all this. When I'm in that position, I tend to favor >> a certain amount of flexibility rather than gambling it all on one >> number on the roulette wheel. >> >How about a compromise; we strong recommend DANE, and characterize the >WebPKI as a fallback, with caveats. > >Steve >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir > From york@isoc.org Fri Nov 1 15:07:45 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6697521E8063 for ; Fri, 1 Nov 2013 15:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DDNPh5E40JZ for ; Fri, 1 Nov 2013 15:07:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0151.outbound.protection.outlook.com [207.46.163.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0EC11E813A for ; Fri, 1 Nov 2013 15:07:37 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB066.namprd06.prod.outlook.com (10.242.187.145) with Microsoft SMTP Server (TLS) id 15.0.800.7; Fri, 1 Nov 2013 22:07:35 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.179]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.186]) with mapi id 15.00.0800.005; Fri, 1 Nov 2013 22:07:35 +0000 From: Dan York To: Brian Rosen , Richard Shockey Thread-Topic: [stir] Application servers - Re: Call Center Implications Thread-Index: AQHO1aMJRsqTAG1U4EKj0umVPsbE/JoNnxKAgAMBeQA= Date: Fri, 1 Nov 2013 22:07:34 +0000 Message-ID: In-Reply-To: <91B44B86-A2B6-48A4-8B8B-3C17571028BF@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.5] x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(377454003)(479174003)(24454002)(81342001)(81816001)(4396001)(19580395003)(47976001)(65816001)(59766001)(49866001)(74662001)(51856001)(31966008)(47446002)(69226001)(74502001)(2656002)(80022001)(19580405001)(46102001)(80976001)(50986001)(83322001)(63696002)(79102001)(81686001)(47736001)(74706001)(74876001)(77096001)(85306002)(36756003)(76482001)(54356001)(56776001)(53806001)(56816003)(83072001)(76786001)(77982001)(76176001)(76796001)(81542001)(54316002)(74366001)(87266001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB066; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.5; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <01A269AC13C3F241872E10384931D478@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org List" Subject: Re: [stir] Application servers - Re: Call Center Implications X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 22:07:45 -0000 Brian, On 10/30/13 3:21 PM, "Brian Rosen" wrote: >We have a separate list for caller name (cnit). Ah, cool! I missed the notice back in late August that this list was created. >I don=B9t see any difference between these authorized users of a TN and a >BPO. The customer can get a credential authorized by the service >provider who delegated the TN to him. The customer can then =B3delegate= =B2 >the BPO or the mass calling service provider to use that number on its >behalf. There is no difference from our point of view why the authorized >entity is placing the call, what kind of service it offers, or how many >calls it places. If it=B9s authorized by the subscriber to use the TN, >then the contractor can use the TN and sign for it. Agreed. At the highest level, it's fundamentally the same problem we're trying to solve. My main point in raising it was that some of these services may be very automated - even to the point of being entirely self-service. Again, it's not really any different from a huge call center at a conceptual level. Dan From br@brianrosen.net Fri Nov 1 15:22:38 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A0511E8143 for ; Fri, 1 Nov 2013 15:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-Mk13UYZq0w for ; Fri, 1 Nov 2013 15:22:33 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 92AAF11E8153 for ; Fri, 1 Nov 2013 15:22:28 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id hu16so30457qab.11 for ; Fri, 01 Nov 2013 15:22:28 -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=UL3bb9OagAzIUCPDeHz+6UAFgo4qxXyX18ktbPIOu8A=; b=BFW9YAImWs+3KOesWuyyBPGaCrB7kKMEQq07IFKGMshb+kaMIKdWKRK84xzOEbiwrV nUXtQcY/Lk2Y4x83+Uq4oSzUQhSD9An5lAoiS4Flliwo2D27REpLaLBZdkn18g2d0oxn ieBhCH+9IsCbBGmxfq599K2oCaGDTaQNsjN5BW4vbpFjRMMJGsLHQqO4StaX+IeHhkBE buyU1XIEhD/xhnFW37WU6yOmLcdPVQgOftZWYXTGByoG7d24+3Qghqwu9/o2B65m+3f9 3ZqJG1m+r/B0qqkW/FQOypetSVij8omNPkJcAkTmaT3LxZAQrRqYVSN03ZKCihc01Js5 F1fg== X-Gm-Message-State: ALoCoQnbtSWUsm5Js3gg6k65hlIGZ/m08FGOhPz1gPl9xrBTOaLsVEw4iisITL94HybGCG7+LwYc X-Received: by 10.224.40.138 with SMTP id k10mr6994748qae.67.1383344548094; Fri, 01 Nov 2013 15:22:28 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id l5sm25721172qac.12.2013.11.01.15.22.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 15:22:27 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: Date: Fri, 1 Nov 2013 18:22:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dan York X-Mailer: Apple Mail (2.1816) Cc: "stir@ietf.org List" , Richard Shockey Subject: Re: [stir] Application servers - Re: Call Center Implications X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 22:22:39 -0000 Look at this case from two points of view. The one we=92re concerned about here in stir right now is the call = chain. I think the only thing that matters is that there can be multiple = credentials per number, including in this case, the service provider who = provides the actual TN service (who would handle a return call to the = TN), its subscriber (the enterprise), and the automated special service = provider you are concerned about. They all have different credentials, = any of which can be used to sign for an outgoing call. If the mass call = out processor has the credential, it can make calls, even if they don=92t = come from the same service provider that serves the subscriber. That=92s = good. =20 Verifying has to be able to deal with this multiple credential per = number dealie. I=92ll note that if the TN came through a reseller path, = there might be 6 or 7, or even more, authorized entities who can sign. = That leads us towards some way to select the right credential that = appears in the signaling. A query by TN to a database (regardless of = protocol) would have to return each of the credentials and the verifier = would have to try them sequentially unless it knew by something in the = signaling which was the right one. The notion of sending a URI to the = credential fixes this, but there are other ways. Now, this also means we need a highly automated way for these = delegations to be instantiated, so your automated self-service entity = can get the credential it needs without a human in the path. I think = that means that the upwind delegator has to have an automated interface = to create the delegation, and the delegate has to have an automated = interface to create or retrieve the credential. I have a bunch of thoughts on that, but I think we need to get the call = chain stuff completely worked out before we start worrying about the = provisioning aspects. Brian On Nov 1, 2013, at 6:07 PM, Dan York wrote: > Brian, >=20 >=20 > On 10/30/13 3:21 PM, "Brian Rosen" wrote: >=20 >> We have a separate list for caller name (cnit). >=20 > Ah, cool! I missed the notice back in late August that this list was > created. >=20 >> I don=B9t see any difference between these authorized users of a TN = and a >> BPO. The customer can get a credential authorized by the service >> provider who delegated the TN to him. The customer can then = =B3delegate=B2 >> the BPO or the mass calling service provider to use that number on = its >> behalf. There is no difference from our point of view why the = authorized >> entity is placing the call, what kind of service it offers, or how = many >> calls it places. If it=B9s authorized by the subscriber to use the = TN, >> then the contractor can use the TN and sign for it. >=20 > Agreed. At the highest level, it's fundamentally the same problem = we're > trying to solve. My main point in raising it was that some of these > services may be very automated - even to the point of being entirely > self-service. Again, it's not really any different from a huge call > center at a conceptual level. >=20 > Dan >=20 >=20 From pkyzivat@alum.mit.edu Fri Nov 1 15:33:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4498811E8137 for ; Fri, 1 Nov 2013 15:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.254 X-Spam-Level: X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT+Gtw9MmbqI for ; Fri, 1 Nov 2013 15:33:36 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 9083E11E817D for ; Fri, 1 Nov 2013 15:33:32 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id kLAR1m0010QuhwU5DNZVz0; Fri, 01 Nov 2013 22:33:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id kNZU1m00i3ZTu2S3NNZUuf; Fri, 01 Nov 2013 22:33:29 +0000 Message-ID: <52742C38.2000402@alum.mit.edu> Date: Fri, 01 Nov 2013 15:33:28 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.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=q20121106; t=1383345209; bh=u4zEPSWcnO25A37Sm2XTY7l9GhOa/0j5qIbPAKLNiSw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kjmJ4lfNfTL0FQOanGSX4qTuhc7Wilgt/57bjbDWBSP38litKnqCDKaLWydl5PUZa Ua0BG8ZbEW/xBWHklfD41bHzzsbleCj3iVeBrdnkxQdhyPX7D99r2ts/EZLHrCH+zb q5HusYjhbkW3ebbgOdcV8zXSTIcAxW84G2Y/J7TtBHvFzMoe8OaNXRFTzylvZBmxEo kfCrTIX1omN4LUMLmzKYpz4m+cMvkGzG23sxO1r1XqKQFPbWZh3UFOIUtnvVCLwOS2 Db56BUz0lnu6tUw+NEw+BXEvFYt8y5iXyXZxALuYO7ODXkraAgZ9Nto4u51hbTnwNm FT2yfmUNcqAlQ== Subject: Re: [stir] Application servers - Re: Call Center Implications X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 22:33:41 -0000 On 11/1/13 3:22 PM, Brian Rosen wrote: > Look at this case from two points of view. > > The one we’re concerned about here in stir right now is the call chain. > > I think the only thing that matters is that there can be multiple credentials per number, including in this case, the service provider who provides the actual TN service (who would handle a return call to the TN), its subscriber (the enterprise), and the automated special service provider you are concerned about. They all have different credentials, any of which can be used to sign for an outgoing call. If the mass call out processor has the credential, it can make calls, even if they don’t come from the same service provider that serves the subscriber. That’s good. > > Verifying has to be able to deal with this multiple credential per number dealie. I’ll note that if the TN came through a reseller path, there might be 6 or 7, or even more, authorized entities who can sign. That leads us towards some way to select the right credential that appears in the signaling. A query by TN to a database (regardless of protocol) would have to return each of the credentials and the verifier would have to try them sequentially unless it knew by something in the signaling which was the right one. The notion of sending a URI to the credential fixes this, but there are other ways. > > Now, this also means we need a highly automated way for these delegations to be instantiated, so your automated self-service entity can get the credential it needs without a human in the path. I think that means that the upwind delegator has to have an automated interface to create the delegation, and the delegate has to have an automated interface to create or retrieve the credential. > > I have a bunch of thoughts on that, but I think we need to get the call chain stuff completely worked out before we start worrying about the provisioning aspects. It occurs to me that this delegation may present different issues for cnit than it does for stir. When somebody acquires a number, there might be multiple names that they should be allowed to use with it. And when delegating, they might not want to delegate the right to use all of those names. I mention it here because it might mean that stir and cnit have different delegation needs. But if cnit wants to ride on stir's delegation coat tails, it will have to be considered from the start. Thanks, Paul > Brian > > On Nov 1, 2013, at 6:07 PM, Dan York wrote: > >> Brian, >> >> >> On 10/30/13 3:21 PM, "Brian Rosen" wrote: >> >>> We have a separate list for caller name (cnit). >> >> Ah, cool! I missed the notice back in late August that this list was >> created. >> >>> I donąt see any difference between these authorized users of a TN and a >>> BPO. The customer can get a credential authorized by the service >>> provider who delegated the TN to him. The customer can then łdelegate˛ >>> the BPO or the mass calling service provider to use that number on its >>> behalf. There is no difference from our point of view why the authorized >>> entity is placing the call, what kind of service it offers, or how many >>> calls it places. If itąs authorized by the subscriber to use the TN, >>> then the contractor can use the TN and sign for it. >> >> Agreed. At the highest level, it's fundamentally the same problem we're >> trying to solve. My main point in raising it was that some of these >> services may be very automated - even to the point of being entirely >> self-service. Again, it's not really any different from a huge call >> center at a conceptual level. >> >> Dan >> >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From br@brianrosen.net Fri Nov 1 17:19:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7834E11E80E9 for ; Fri, 1 Nov 2013 17:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.482 X-Spam-Level: X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFCdPL0OInor for ; Fri, 1 Nov 2013 17:19:52 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id C5AE611E8156 for ; Fri, 1 Nov 2013 17:19:46 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id i7so2811356qcq.16 for ; Fri, 01 Nov 2013 17:19:46 -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:message-id:references:to; bh=w89No/imumNVE6KZu4w1T1BK9/iXlIV6o09xJCW7jmk=; b=hBwuFSzWT6yZTiqngOtEZuUvPQYmFVbHnbEVVR5Ak7rqjjwbT+8UJJTJAPOScBc6sq AmNDN7q1Ae7A7IF1LpmsqVp2i97iJ3SD5rKd84FbsHonWs221wr527nk5aKj80cf1HaB U7Z9Vn2NPKQy0qWZvtZA2zEcmyxb5zuQjYEqpSxrCJ0vj6uyT2cS5YLiVfN8hYZPj+qR g2CHcWvNqERazLARq1VU0axyUE/DME8IAKSgb92Nd2DvR9QxJeyBPTXDpxuz15Kwglek q1lh7thfFVzw8brmf+Uga8z44rmVOjBr46Zob5kecWh3tzQ69MS9HpHysZO1ZT0NPy/+ EhPQ== X-Gm-Message-State: ALoCoQnkEAAYRiZKys5YxxPGZ5+zVhIxxo4UkK1trfzWiZ+ZEn4E9IVlbWXyRz0X+nrfDcfcQIdQ X-Received: by 10.49.0.208 with SMTP id 16mr7517551qeg.25.1383351586235; Fri, 01 Nov 2013 17:19:46 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id u3sm22681178qej.8.2013.11.01.17.19.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 17:19:45 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_73290C87-0C35-4538-BDC9-519712B5330B" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: <52742C38.2000402@alum.mit.edu> Date: Fri, 1 Nov 2013 20:19:43 -0400 Message-Id: References: <52742C38.2000402@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1816) Cc: "stir@ietf.org List" Subject: Re: [stir] Application servers - Re: Call Center Implications X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 00:19:57 -0000 --Apple-Mail=_73290C87-0C35-4538-BDC9-519712B5330B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yeah, could be. We ought to at least be thinking about it. Maybe a delegation can limit what name can be used. Brian On Nov 1, 2013, at 6:33 PM, Paul Kyzivat wrote: > On 11/1/13 3:22 PM, Brian Rosen wrote: >> Look at this case from two points of view. >>=20 >> The one we=92re concerned about here in stir right now is the call = chain. >>=20 >> I think the only thing that matters is that there can be multiple = credentials per number, including in this case, the service provider who = provides the actual TN service (who would handle a return call to the = TN), its subscriber (the enterprise), and the automated special service = provider you are concerned about. They all have different credentials, = any of which can be used to sign for an outgoing call. If the mass call = out processor has the credential, it can make calls, even if they don=92t = come from the same service provider that serves the subscriber. That=92s = good. >>=20 >> Verifying has to be able to deal with this multiple credential per = number dealie. I=92ll note that if the TN came through a reseller path, = there might be 6 or 7, or even more, authorized entities who can sign. = That leads us towards some way to select the right credential that = appears in the signaling. A query by TN to a database (regardless of = protocol) would have to return each of the credentials and the verifier = would have to try them sequentially unless it knew by something in the = signaling which was the right one. The notion of sending a URI to the = credential fixes this, but there are other ways. >>=20 >> Now, this also means we need a highly automated way for these = delegations to be instantiated, so your automated self-service entity = can get the credential it needs without a human in the path. I think = that means that the upwind delegator has to have an automated interface = to create the delegation, and the delegate has to have an automated = interface to create or retrieve the credential. >>=20 >> I have a bunch of thoughts on that, but I think we need to get the = call chain stuff completely worked out before we start worrying about = the provisioning aspects. >=20 > It occurs to me that this delegation may present different issues for = cnit than it does for stir. When somebody acquires a number, there might = be multiple names that they should be allowed to use with it. And when = delegating, they might not want to delegate the right to use all of = those names. >=20 > I mention it here because it might mean that stir and cnit have = different delegation needs. But if cnit wants to ride on stir's = delegation coat tails, it will have to be considered from the start. >=20 > Thanks, > Paul >=20 >> Brian >>=20 >> On Nov 1, 2013, at 6:07 PM, Dan York wrote: >>=20 >>> Brian, >>>=20 >>>=20 >>> On 10/30/13 3:21 PM, "Brian Rosen" wrote: >>>=20 >>>> We have a separate list for caller name (cnit). >>>=20 >>> Ah, cool! I missed the notice back in late August that this list was >>> created. >>>=20 >>>> I don=B9t see any difference between these authorized users of a TN = and a >>>> BPO. The customer can get a credential authorized by the service >>>> provider who delegated the TN to him. The customer can then = =B3delegate=B2 >>>> the BPO or the mass calling service provider to use that number on = its >>>> behalf. There is no difference from our point of view why the = authorized >>>> entity is placing the call, what kind of service it offers, or how = many >>>> calls it places. If it=B9s authorized by the subscriber to use the = TN, >>>> then the contractor can use the TN and sign for it. >>>=20 >>> Agreed. At the highest level, it's fundamentally the same problem = we're >>> trying to solve. My main point in raising it was that some of these >>> services may be very automated - even to the point of being entirely >>> self-service. Again, it's not really any different from a huge call >>> center at a conceptual level. >>>=20 >>> Dan >>>=20 >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_73290C87-0C35-4538-BDC9-519712B5330B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yeah, = could be.  We ought to at least be thinking about = it.

Maybe a delegation can limit what name can be = used.

Brian

On Nov 1, = 2013, at 6:33 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

On 11/1/13 3:22 PM, Brian Rosen = wrote:
Look at this case from two points of = view.

The one we=92re concerned about here in stir right now is = the call chain.

I think the only thing that matters is that there = can be multiple credentials per number, including in this case, the = service provider who provides the actual TN service (who would handle a = return call to the TN), its subscriber (the enterprise), and the = automated special service provider you are concerned about.  They = all have different credentials, any of which can be used to sign for an = outgoing call.  If the mass call out processor has the credential, = it can make calls, even if they don=92t come from the same service = provider that serves the subscriber. That=92s good.

Verifying has = to be able to deal with this multiple credential per number dealie. =  I=92ll note that if the TN came through a reseller path, there = might be 6 or 7, or even more, authorized entities who can sign. =  That leads us towards some way to select the right credential that = appears in the signaling.  A query by TN to a database (regardless = of protocol) would have to return each of the credentials and the = verifier would have to try them sequentially unless it knew by something = in the signaling which was the right one.  The notion of sending a = URI to the credential fixes this, but there are other ways.

Now, = this also means we need a highly automated way for these delegations to = be instantiated, so your automated self-service entity can get the = credential it needs without a human in the path.  I think that = means that the upwind delegator has to have an automated interface to = create the delegation, and the delegate has to have an automated = interface to create or retrieve the credential.

I have a bunch of = thoughts on that, but I think we need to get the call chain stuff = completely worked out before we start worrying about the provisioning = aspects.

It occurs to me that this delegation may = present different issues for cnit than it does for stir. When somebody = acquires a number, there might be multiple names that they should be = allowed to use with it. And when delegating, they might not want to = delegate the right to use all of those names.

I mention it here = because it might mean that stir and cnit have different delegation = needs. But if cnit wants to ride on stir's delegation coat tails, it = will have to be considered from the start.

= Thanks,
Paul

Brian

On Nov = 1, 2013, at 6:07 PM, Dan York <york@isoc.org> = wrote:

Brian,


On 10/30/13 = 3:21 PM, "Brian Rosen" <br@brianrosen.net> = wrote:

We have a separate list for = caller name (cnit).

Ah, cool! I missed the notice = back in late August that this list was
created.

I don=B9t see any difference between these authorized = users of a TN and a
BPO.  The customer can get a credential = authorized by the service
provider who delegated the TN to him. =  The customer can then =B3delegate=B2
the BPO or the mass = calling service provider to use that number on its
behalf. =  There is no difference from our point of view why the = authorized
entity is placing the call, what kind of service it = offers, or how many
calls it places.  If it=B9s authorized by = the subscriber to use the TN,
then the contractor can use the TN and = sign for it.

Agreed.  At the highest level, = it's fundamentally the same problem we're
trying to solve. My main = point in raising it was that some of these
services may be very = automated - even to the point of being entirely
self-service. =  Again, it's not really any different from a huge call
center at = a conceptual = level.

Dan



____________________________= ___________________
stir mailing list
stir@ietf.org
https://www.ietf.org/m= ailman/listinfo/stir


_________________________= ______________________
stir mailing list
stir@ietf.org
https://www.ietf.org/m= ailman/listinfo/stir

= --Apple-Mail=_73290C87-0C35-4538-BDC9-519712B5330B-- From richard@shockey.us Sat Nov 2 14:46:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3480921E80E8 for ; Sat, 2 Nov 2013 14:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.086 X-Spam-Level: X-Spam-Status: No, score=-101.086 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WFZ9EB2gnNR for ; Sat, 2 Nov 2013 14:46:33 -0700 (PDT) Received: from outbound-ss-1429.hostmonster.com (outbound-ss-1429.hostmonster.com [74.220.221.129]) by ietfa.amsl.com (Postfix) with SMTP id D8C5421E80E6 for ; Sat, 2 Nov 2013 14:46:23 -0700 (PDT) Received: (qmail 5628 invoked by uid 0); 2 Nov 2013 21:46:18 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy19-pub.mail.unifiedlayer.com with SMTP; 2 Nov 2013 21:46:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=4EmYlQ2AubMosQqJM1/t9Yrl71zwZ1xkp651pFooy8M=; b=JVcZcMIM3FubgTW1nZNh2wDr3LAV7uIndA1jln5xNZea7QrY9f9GNeiK1gjsk0zOH4Kpc0cwz1XRpx/acmX8RZ+4fpbk3nZjiYVg6FMMh4l6R58H0jOyygzgoO+Ldg4n; Received: from [173.79.179.104] (port=59618 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vcj1O-00070f-8T; Sat, 02 Nov 2013 15:46:18 -0600 From: "Richard Shockey" To: "'Brian Rosen'" , "'Paul Kyzivat'" References: <52742C38.2000402@alum.mit.edu> In-Reply-To: Date: Sat, 2 Nov 2013 17:46:16 -0400 Message-ID: <018401ced814$f63b73c0$e2b25b40$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0185_01CED7F3.6F2B5A60" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJdikwN8Jr5vD77bgIKtwNGTFzpuAEu++hsANQWoYECUhxDNJjSaMeg X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: stir@ietf.org, cnit@ietf.org Subject: Re: [stir] Application servers - Re: Call Center Implications X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 21:46:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0185_01CED7F3.6F2B5A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have to admit all of this discussion increasingly makes me = uncomfortable. =20 Complexity is the enemy of deployability and security.=20 =20 That is BTW the core problem some of us see in the PREPASS discussion.=20 =20 =93We have met the enemy and it is us.=94 =20 Validation of the Caller ID number and maybe possibly the Verbose = Calling Party data [CNAM+] better be pretty simple. The chain of authority IMHO = is still derived at the first order from the Carrier of Record. We can = debate the rest. =20 =20 I make no pretentions to being a Security expert. One of our Co-Chairs = is. What I have not been able to see over some serious searching is the real story about PKI. What are its successes and failures? DANE vs DKIM vs = WEB PKI whatever. What do we say to NRA=92s? Well this might work this = might not . =20 =20 Now we start playing the game of Economics. President Truman was = quoted. =20 =20 =93GIVE me a one-handed economist,=94 demanded a frustrated American = president. =93All my economists say, =91on the one hand...on the other'=94.=20 =20 From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, November 01, 2013 8:20 PM To: Paul Kyzivat Cc: stir@ietf.org List Subject: Re: [stir] Application servers - Re: Call Center Implications =20 Yeah, could be. We ought to at least be thinking about it. =20 Maybe a delegation can limit what name can be used. =20 Brian =20 On Nov 1, 2013, at 6:33 PM, Paul Kyzivat > wrote: On 11/1/13 3:22 PM, Brian Rosen wrote: Look at this case from two points of view. The one we=92re concerned about here in stir right now is the call = chain. I think the only thing that matters is that there can be multiple credentials per number, including in this case, the service provider who provides the actual TN service (who would handle a return call to the = TN), its subscriber (the enterprise), and the automated special service = provider you are concerned about. They all have different credentials, any of = which can be used to sign for an outgoing call. If the mass call out = processor has the credential, it can make calls, even if they don=92t come from = the same service provider that serves the subscriber. That=92s good. Verifying has to be able to deal with this multiple credential per = number dealie. I=92ll note that if the TN came through a reseller path, there = might be 6 or 7, or even more, authorized entities who can sign. That leads = us towards some way to select the right credential that appears in the signaling. A query by TN to a database (regardless of protocol) would = have to return each of the credentials and the verifier would have to try = them sequentially unless it knew by something in the signaling which was the right one. The notion of sending a URI to the credential fixes this, = but there are other ways. Now, this also means we need a highly automated way for these = delegations to be instantiated, so your automated self-service entity can get the credential it needs without a human in the path. I think that means = that the upwind delegator has to have an automated interface to create the delegation, and the delegate has to have an automated interface to = create or retrieve the credential. I have a bunch of thoughts on that, but I think we need to get the call chain stuff completely worked out before we start worrying about the provisioning aspects. It occurs to me that this delegation may present different issues for = cnit than it does for stir. When somebody acquires a number, there might be multiple names that they should be allowed to use with it. And when delegating, they might not want to delegate the right to use all of = those names. I mention it here because it might mean that stir and cnit have = different delegation needs. But if cnit wants to ride on stir's delegation coat = tails, it will have to be considered from the start. Thanks, Paul Brian On Nov 1, 2013, at 6:07 PM, Dan York > wrote: Brian, On 10/30/13 3:21 PM, "Brian Rosen" > wrote: We have a separate list for caller name (cnit). Ah, cool! I missed the notice back in late August that this list was created. I don=B9t see any difference between these authorized users of a TN and = a BPO. The customer can get a credential authorized by the service provider who delegated the TN to him. The customer can then = =B3delegate=B2 the BPO or the mass calling service provider to use that number on its behalf. There is no difference from our point of view why the = authorized entity is placing the call, what kind of service it offers, or how many calls it places. If it=B9s authorized by the subscriber to use the TN, then the contractor can use the TN and sign for it. Agreed. At the highest level, it's fundamentally the same problem we're trying to solve. My main point in raising it was that some of these services may be very automated - even to the point of being entirely self-service. Again, it's not really any different from a huge call center at a conceptual level. Dan _______________________________________________ stir mailing list stir@ietf.org =20 https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org =20 https://www.ietf.org/mailman/listinfo/stir =20 ------=_NextPart_000_0185_01CED7F3.6F2B5A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have to admit all of this discussion increasingly makes me = uncomfortable.

 

Complexity is the enemy of deployability and security. =

 

That is BTW the core problem some of us see in the PREPASS = discussion.

 

“We have met the enemy and it is = us.”

 

Validation of the Caller ID number and maybe possibly the Verbose = Calling Party data [CNAM+] better be pretty simple.=A0 The chain of = authority IMHO is still derived at the first order from the Carrier of = Record.=A0 We can debate the rest. =A0

 

I make no pretentions to being a Security expert. =A0One of our = Co-Chairs is.=A0 What I have not been able to see over some serious = searching is the real story about PKI. What are its successes and = failures?=A0 DANE vs DKIM vs WEB PKI whatever. What do we say to = NRA’s?=A0 Well this might work this might not .=A0 =

 

Now we start playing the game of Economics.=A0 President Truman was = quoted.=A0

 

“GIVE me a one-handed economist,” demanded a frustrated = American president. “All my economists say, ‘on the one = hand...on the other'”.

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Brian Rosen
Sent: Friday, November 01, 2013 8:20 = PM
To: Paul Kyzivat
Cc: stir@ietf.org = List
Subject: Re: [stir] Application servers - Re: Call Center = Implications

 

Yeah, could = be.  We ought to at least be thinking about = it.

 

Maybe a delegation can limit what name can be = used.

 

Brian

 

On = Nov 1, 2013, at 6:33 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:



On 11/1/13 3:22 PM, = Brian Rosen wrote:

Look at this case from = two points of view.

The one we’re concerned about here in = stir right now is the call chain.

I think the only thing that = matters is that there can be multiple credentials per number, including = in this case, the service provider who provides the actual TN service = (who would handle a return call to the TN), its subscriber (the = enterprise), and the automated special service provider you are = concerned about.  They all have different credentials, any of which = can be used to sign for an outgoing call.  If the mass call out = processor has the credential, it can make calls, even if they = don’t come from the same service provider that serves the = subscriber. That’s good.

Verifying has to be able to deal = with this multiple credential per number dealie.  I’ll note = that if the TN came through a reseller path, there might be 6 or 7, or = even more, authorized entities who can sign.  That leads us towards = some way to select the right credential that appears in the signaling. =  A query by TN to a database (regardless of protocol) would have to = return each of the credentials and the verifier would have to try them = sequentially unless it knew by something in the signaling which was the = right one.  The notion of sending a URI to the credential fixes = this, but there are other ways.

Now, this also means we need a = highly automated way for these delegations to be instantiated, so your = automated self-service entity can get the credential it needs without a = human in the path.  I think that means that the upwind delegator = has to have an automated interface to create the delegation, and the = delegate has to have an automated interface to create or retrieve the = credential.

I have a bunch of thoughts on that, but I think we = need to get the call chain stuff completely worked out before we start = worrying about the provisioning = aspects.


It occurs to me that this delegation may = present different issues for cnit than it does for stir. When somebody = acquires a number, there might be multiple names that they should be = allowed to use with it. And when delegating, they might not want to = delegate the right to use all of those names.

I mention it here = because it might mean that stir and cnit have different delegation = needs. But if cnit wants to ride on stir's delegation coat tails, it = will have to be considered from the start.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Thanks,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Paul


Brian

On Nov 1, = 2013, at 6:07 PM, Dan York <york@isoc.org> = wrote:


Brian,


On = 10/30/13 3:21 PM, "Brian Rosen" <br@brianrosen.net> = wrote:


We have a separate = list for caller name (cnit).


Ah, cool! I missed = the notice back in late August that this list = was
created.


I don=B9t see any = difference between these authorized users of a TN and a
BPO. =  The customer can get a credential authorized by the = service
provider who delegated the TN to him.  The customer can = then =B3delegate=B2
the BPO or the mass calling service provider to = use that number on its
behalf.  There is no difference from our = point of view why the authorized
entity is placing the call, what = kind of service it offers, or how many
calls it places.  If = it=B9s authorized by the subscriber to use the TN,
then the = contractor can use the TN and sign for = it.


Agreed.  At the highest level, it's = fundamentally the same problem we're
trying to solve. My main point = in raising it was that some of these
services may be very automated - = even to the point of being entirely
self-service.  Again, it's = not really any different from a huge call
center at a conceptual = level.

Dan


___________________________________________= ____
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

<= p class=3DMsoNormal> 

------=_NextPart_000_0185_01CED7F3.6F2B5A60-- From michael@voip.co.uk Sun Nov 3 17:31:42 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689D321E80B0 for ; Sun, 3 Nov 2013 17:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT-98liQPj7y for ; Sun, 3 Nov 2013 17:31:36 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with SMTP id E818D11E820E for ; Sun, 3 Nov 2013 17:31:34 -0800 (PST) Received: from mail-we0-f174.google.com ([74.125.82.174]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKUnb49k0Sl3OB5zcpAwOiDuTK5wAcKkjY@postini.com; Sun, 03 Nov 2013 17:31:35 PST Received: by mail-we0-f174.google.com with SMTP id u56so1495109wes.19 for ; Sun, 03 Nov 2013 17:31:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6w1+ffQ3waAR5J+/rts2rV9Svn2JO0s5wSi8YBFjxj4=; b=SUgIaUPfEvhWJk7nq7gi8qFlhponLAa26skEGL86FnwINfLZE8JbAkIYrZekPfTYl2 8u5GNeFYKif5vQKgl+emG/Y4EGk4ovOp8ioq5QNhNNPMTLIc6xnlbNPa8jiRU5Jbo9Ih XP+e9MvBjdnAHMDgHQ0BiL6RzPzu8IWxDhWRGvN24qEy4ytZGeCGHuu1/JBbfh4qDOjY 6rw4G1LqdTOOFcePPeXDrhHEyNUyv+9UO96DMXqWlIeeNN0dMSmjJYjbpuieZfJMnG11 cJhbMWzPTmn76hMS8DiHf6NOMJyoxg0nnNhmXSg1219tmyTD7atrv/I3jniOdCuFmAY8 tB+w== X-Received: by 10.180.95.202 with SMTP id dm10mr10116621wib.62.1383528693487; Sun, 03 Nov 2013 17:31:33 -0800 (PST) X-Gm-Message-State: ALoCoQkVkTEVksT7i88CJwNzIKODHcy5id3X/dMhvfJKi4ydBMfEiktQ/c7emCIPn+7JVllVrxqxRyv/QFUYj2Nlv51IqRx1xg93+e4TIRgdDydmiG/gi3reo7GXk5cfXCUWJI5GFXe+tTF8lmu7c4Jw4kFa0/rxew== MIME-Version: 1.0 X-Received: by 10.180.95.202 with SMTP id dm10mr10116617wib.62.1383528693403; Sun, 03 Nov 2013 17:31:33 -0800 (PST) Received: by 10.194.93.34 with HTTP; Sun, 3 Nov 2013 17:31:33 -0800 (PST) Date: Sun, 3 Nov 2013 17:31:33 -0800 Message-ID: From: Michael Procter To: "stir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 01:31:42 -0000 In section 7, there is a privacy requirement to prevent 3rd parties from learning what numbers have been called by a specific caller. Should there be a similar requirement to prevent 3rd parties learning what numbers have called a specific callee? The reason I mention it is that there was an issue with an aspect of vipr where a proposed mechanism could protect either the caller's privacy or the callee's privacy but not both. I'd like to avoid a similar situation here. Regards, Michael From jon.peterson@neustar.biz Mon Nov 4 07:20:55 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA1321E81C9 for ; Mon, 4 Nov 2013 07:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT9FPAMZ05Ho for ; Mon, 4 Nov 2013 07:20:51 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 62F9F21E81CD for ; Mon, 4 Nov 2013 07:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383579043; x=1698936145; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=Zb0O0/yCca PvIovgCtmkV7y5ZElxNI3hSvewVucSiZs=; b=aoBJsKNiUFxUS8tLLYr1N7JMoJ EIzdlUzEo4p5KpUtsa9dxELXCIBH74YxxYK2qRTH7z53hDuscv0RwulyNyWg== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.34891560; Mon, 04 Nov 2013 10:30:42 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 4 Nov 2013 10:20:35 -0500 From: "Peterson, Jon" To: Michael Procter , "stir@ietf.org" Thread-Topic: [stir] draft-ietf-stir-problem-statement: Privacy requirements Thread-Index: AQHO2P2hp4T+BWgdmkKNlkLkLQsoMZoU/oiA Date: Mon, 4 Nov 2013 15:20:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.128.72] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 7SzieGFJDWUM7N849eIxsg== Content-Type: text/plain; charset="us-ascii" Content-ID: <37B35BA9DFE51C459411ED2C203AFDA1@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 15:20:55 -0000 I agree. Jon Peterson Neustar, Inc. On 11/3/13 5:31 PM, "Michael Procter" wrote: >In section 7, there is a privacy requirement to prevent 3rd parties >from learning what numbers have been called by a specific caller. >Should there be a similar requirement to prevent 3rd parties learning >what numbers have called a specific callee? > >The reason I mention it is that there was an issue with an aspect of >vipr where a proposed mechanism could protect either the caller's >privacy or the callee's privacy but not both. I'd like to avoid a >similar situation here. > >Regards, > >Michael >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Mon Nov 4 08:04:26 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883FE11E827E for ; Mon, 4 Nov 2013 08:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.881 X-Spam-Level: X-Spam-Status: No, score=-101.881 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY+M71LaZjwS for ; Mon, 4 Nov 2013 08:04:21 -0800 (PST) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id ACDFC21F9F99 for ; Mon, 4 Nov 2013 08:04:21 -0800 (PST) Received: (qmail 12372 invoked by uid 0); 4 Nov 2013 16:04:00 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.mail.unifiedlayer.com with SMTP; 4 Nov 2013 16:04:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=PLTDHi5U5UzvrWB2knx5Rdc30Wn/8cbhJA+28I0yp2E=; b=MVIb/rBAqqtF8w+HemA0OQHsfn0gTcp5WPXTr1ckLgBc+KtBgkTZvqfCryiezl+3MZKTFOPTfqRmJtZJtWwZYmWRoVRGSQLVi9fCuAMQD/gvaPKOlJleymebGV3yJVqB; Received: from [173.79.179.104] (port=53494 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VdMdD-0002Xi-By; Mon, 04 Nov 2013 09:03:59 -0700 From: "Richard Shockey" To: "'Peterson, Jon'" , "'Michael Procter'" , References: In-Reply-To: Date: Mon, 4 Nov 2013 11:03:58 -0500 Message-ID: <010501ced977$79754ff0$6c5fefd0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMZKMMauwZB5xv3gUqqvo3xkqZK65eAnTNQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 16:04:26 -0000 What third party? The carrier? -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Monday, November 04, 2013 10:21 AM To: Michael Procter; stir@ietf.org Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements I agree. Jon Peterson Neustar, Inc. On 11/3/13 5:31 PM, "Michael Procter" wrote: >In section 7, there is a privacy requirement to prevent 3rd parties >from learning what numbers have been called by a specific caller. >Should there be a similar requirement to prevent 3rd parties learning >what numbers have called a specific callee? > >The reason I mention it is that there was an issue with an aspect of >vipr where a proposed mechanism could protect either the caller's >privacy or the callee's privacy but not both. I'd like to avoid a >similar situation here. > >Regards, > >Michael >_______________________________________________ >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 jon.peterson@neustar.biz Mon Nov 4 09:00:22 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294BD11E8278 for ; Mon, 4 Nov 2013 09:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.793 X-Spam-Level: X-Spam-Status: No, score=-105.793 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, SARE_PRODUCT=0.333, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EsczG8Fds2L for ; Mon, 4 Nov 2013 09:00:15 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8995D11E81E9 for ; Mon, 4 Nov 2013 08:59:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383584400; x=1698935541; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=DiSoW74Tjp6qyKTsERiLXPfkcYBjdHizfOt4/tLBnUo=; b=SUXhL9cvlixnbeBGUnqF5Si11op+R0S/UizMEd73w1NpTNPVDbJWv0gjPpyW+5 Q+J5uu0zfdMOraOuwHpf3bHA== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.28162252; Mon, 04 Nov 2013 11:59:59 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc10.cis.neustar.com ([169.254.4.132]) with mapi id 14.02.0342.003; Mon, 4 Nov 2013 11:59:24 -0500 From: "Peterson, Jon" To: Andrew Allen , "stir@ietf.org" Thread-Topic: [stir] comments on draft-ietf-stir-problem-statement-00 Thread-Index: Ac7QUSi+XuSwVM/UQPSEhXox+oZw/gJFOdUA Date: Mon, 4 Nov 2013 16:59:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.128.72] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: RXJZqd0H3ZAO4dOs5Fbz9Q== Content-Type: multipart/alternative; boundary="_000_CE9D0EF5AF02Ajonpetersonneustarbiz_" MIME-Version: 1.0 Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:00:22 -0000 --_000_CE9D0EF5AF02Ajonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andrew, Catching up on this mail; thanks for these comments, you have some good cat= ches here. I think we're mostly cool but a couple points we might discuss f= urther: Section 6.1 I think this text should be generalized to talk about mobile instant messag= ing services in the abstract and not describe a single vendors product offe= ring. Potentially a plurality of instant messaging services from multiple v= endors could form a basis for a general solution if instant messaging ends = up being part of the solution. This text isn't trying to shill for any particular vendor, really it is jus= t trying to provide an existence proof. I certainly wouldn't object to ment= ioning other similar services here that corroborate that existence proof. Section 6.5 Due to roaming and countless other factors, calls on the PSTN may emerge fr= om administrative domains that have no relationship with the number assigne= e I am not convinced that roaming (at least in the traditional sense of cellu= lar roaming - and this will continue to be the case with IMS roaming) means= that calls will emerge from administrative domains that have no relationsh= ip with the number assignee. In cellular roaming there is a very close rela= tionship between the roamed to network and there are trust domains between= them and authentication of the mobile involving cooperation between the ho= me network that is the number assignee and the roamed to network. If roamin= g here means something else then please clarify. The administrative domain has no relationship with the number assignee in t= he sense that the number assignee is not a customer of that administrative = domain and doesn't pay money to it directly. Totally agreed that there are = trust relationships between carriers that make roaming possible, but the re= levant bit here for STIR is about who assigns the number and who serves the= call. When I come here to Vancouver, my cell phone roams from AT&T to Rodg= ers. Rogers is not the carrier to whom my cell phone number is assigned for= STIR purposes, but they serve my calls and texts while I'Mhere . Still, if= this is confusing from the text we need to make it clearer. Minimal payload overhead: Must lead to minimal expansion of SIP header= s fields to avoid fragmentation in deployments that use UDP. Is this really a MUST strength requirement? Whatever solution we come up wi= th that requires enhancement to SIP requires some enhancement. TCP is alway= s available to use if message sizes become too large and since the deployed= systems will need to be enhanced they can be (even should be) enhanced to = support TCP. I think in many cases SIP and SDP has already grown to such an= extent (ICE candidates, preconditions, SDP cap neg attributes, increasing = number of codecs and media lines etc=85) that we are already at the point w= here we are perilously close to or already over the 1300 byte recommendatio= n in many scenarios. Any size increase at all may break the camel=92s back= on the UDP fragmentation issue. I think at best this is guidance that mess= age size is a factor to consider in evaluating a solution not an overriding= requirement. Well, the "musts" here aren't normative, but I hear you. I don't have that = strong an intuition about this. Jon Peterson Neustar, Inc. --_000_CE9D0EF5AF02Ajonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Andrew,

Catching up on this mail; thanks for these comments, you have some good cat= ches here. I think we're mostly cool but a couple points we might discuss f= urther:

 

<AA>Section 6.1

<snip>

 

I think this text should be generalized to talk abou= t mobile instant messaging services in the abstract and not describe a sing= le vendors product offering. Potentially a plurality of instant messaging s= ervices from multiple vendors could form a basis for a general solution if instant messaging ends up being par= t of the solution.</AA>

This text isn't trying to shill for any particular vendor, really it is jus= t trying to provide an existence proof. I certainly wouldn't object to ment= ioning other similar services here that corroborate that existence proof.


<AA>Section 6.5

 

Due = to roaming and countless other factors, calls on the PSTN may emerge from a= dministrative domains that have no relationship with = the number assignee

 

I am not convinced that roaming (at least in the tradi= tional sense of cellular roaming - and this will continue to be the case wi= th IMS roaming) means that calls will emerge from administrative domains that have no relationship with the numb= er assignee. In cellular roaming there is a very close relationship between= the roamed  to network and there are trust domains between them and a= uthentication of the mobile involving cooperation between the home network that is the number assignee and the r= oamed to network. If roaming here means something else then please clarify.= </AA>

The administrative domain has no re= lationship with the number assignee in the sense that the number assignee i= s not a customer of that administrative domain and doesn't pay money to it = directly. Totally agreed that there are trust relationships between carriers that make roaming possible, = but the relevant bit here for STIR is about who assigns the number and who = serves the call. When I come here to Vancouver, my cell phone roa= ms from AT&T to Rodgers. Rogers is not the carrier to whom my cell phone number is assigned for STIR purposes, but they serve= my calls and texts while I'Mhere . Still, if this is confusing f= rom the text we need to make it clearer.

 
<AA>Minimal payload overhead:  Must lead to mini=
mal expansion of SIP headers fields to avoid fragmentation in deployments t=
hat use UDP.
 

Is this reall= y a MUST strength requirement? Whatever solution we come up with that requi= res enhancement to SIP requires some enhancement. TCP is always available t= o use if message sizes become too large and since the deployed systems will need to be enhanced they can be = (even should be) enhanced to support TCP. I think in many cases SIP and SDP= has already grown to such an extent (ICE candidates, preconditions, SDP ca= p neg attributes, increasing number of codecs and media lines etc=85) that we are already at the point where w= e are perilously close to or already over the 1300 byte recommendation in m= any scenarios.  Any size increase at all may break the camel=92s back = on the UDP fragmentation issue. I think at best this is guidance that message size is a factor to consider in evaluat= ing a solution not an overriding requirement.</AA>

Well, the "musts" here are= n't normative, but I hear you. I don't have that strong= an intuition about this. 

Jon Peterson
Neustar, Inc.
--_000_CE9D0EF5AF02Ajonpetersonneustarbiz_-- From alex@bobotek.net Mon Nov 4 11:36:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E96521E805F for ; Mon, 4 Nov 2013 11:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxvy8YOlfAjw for ; Mon, 4 Nov 2013 11:36:05 -0800 (PST) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id B48E921F9E37 for ; Mon, 4 Nov 2013 11:35:20 -0800 (PST) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta13.emeryville.ca.mail.comcast.net with comcast id lTla1m00C1bwxycADXbLdE; Mon, 04 Nov 2013 19:35:20 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by omta18.emeryville.ca.mail.comcast.net with comcast id lXbJ1m00S4EJ4tY8eXbKG8; Mon, 04 Nov 2013 19:35:19 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Mon, 4 Nov 2013 11:23:11 -0800 From: Alex Bobotek To: Richard Shockey , "'Peterson, Jon'" , 'Michael Procter' , "stir@ietf.org" Date: Mon, 4 Nov 2013 11:23:10 -0800 Thread-Topic: [stir] draft-ietf-stir-problem-statement: Privacy requirements Thread-Index: AQMZKMMauwZB5xv3gUqqvo3xkqZK65eAnTNQgAABxbA= Message-ID: <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> References: <010501ced977$79754ff0$6c5fefd0$@shockey.us> In-Reply-To: <010501ced977$79754ff0$6c5fefd0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383593720; bh=Yjb9rWH6MXARspKZ4VGVBGiEIejxRjEOTJ7u11zxpF4=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=bA+5/KmJoEHsjY8Zu0zeMTnVBF34VB9zyJhdW5mKUjop/jFpO6pFCBKts+SrI4IOw rkAx1cfYITwPm+I3eUNcwSTiUmuACWL1AW0rcROMeSZqIcx4zu4bshNODFR51jH5SX qvY6bkM9fREJ566YgYJU47dYXg92bpyNjGv5PHXOaa7VI36B+XhYbTYGJYXmBAc8tF 4jPHXgLUHmVJsq5Nt0JcjavkZCU9ZPiW8J0Yk4EVGORqGxhQva0OeFP/3vk9hWw1FE 6qdRNXHqZaOY1qFeNPpp62S3IPeT5l3/7s8mWbPuoxaFuhnLovGKcRyG64Dr3RHlI2 4fxyIr1SVH/zw== Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:36:11 -0000 What precisely is a 3rd party in the context of out-of-band validation? A = strict interpretation is that this is any party other than the caller and c= allee (or perhaps their carriers). Other interpretations might be a party = in the middle (e.g., able to access pcaps) who has no role other than perha= ps packet transport. =20 Such a strict interpretation pretty much rules out the use of public DNS or= similar infrastructure as a store for any individual caller/callee PKI or = policy; 3rd parties may be in the middle of requests. A similar requiremen= t would break some DKIM implementations. =20 IMO,=20 1. 3rd party needs to be more precisely defined and/or 2. The degree of privacy compromise should be, at this stage, subject to d= esign trades. A "3rd-party" offering reputation/validation services simi= lar to a DNS service may have legitimate reasons to know one or more of cal= ler/callee. Perhaps the 'requirement' should be recast as a goal or requir= ement to minimize. =20 Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Richard Shockey > Sent: Monday, November 04, 2013 8:04 AM > To: 'Peterson, Jon'; 'Michael Procter'; stir@ietf.org > Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requiremen= ts >=20 >=20 > What third party? The carrier? >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Peterson, Jon > Sent: Monday, November 04, 2013 10:21 AM > To: Michael Procter; stir@ietf.org > Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requiremen= ts >=20 >=20 > I agree. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 11/3/13 5:31 PM, "Michael Procter" wrote: >=20 > >In section 7, there is a privacy requirement to prevent 3rd parties > >from learning what numbers have been called by a specific caller. > >Should there be a similar requirement to prevent 3rd parties learning > >what numbers have called a specific callee? > > > >The reason I mention it is that there was an issue with an aspect of > >vipr where a proposed mechanism could protect either the caller's > >privacy or the callee's privacy but not both. I'd like to avoid a > >similar situation here. > > > >Regards, > > > >Michael > >_______________________________________________ > >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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From michael@voip.co.uk Mon Nov 4 11:49:33 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CD021E821C for ; Mon, 4 Nov 2013 11:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB+r8Pbo7qTA for ; Mon, 4 Nov 2013 11:49:28 -0800 (PST) Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with SMTP id 0D4A921E80CA for ; Mon, 4 Nov 2013 11:49:28 -0800 (PST) Received: from mail-we0-f173.google.com ([74.125.82.173]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUnf6PUUlN4qEfMXKPwXS+Qr+ZSkW7oXH@postini.com; Mon, 04 Nov 2013 11:49:28 PST Received: by mail-we0-f173.google.com with SMTP id u57so2582982wes.32 for ; Mon, 04 Nov 2013 11:49:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ouDgbhUxmllmJ1SG5TMja/GaQ+7ZsFWWIUfkayZZLc0=; b=P8ZcSNmvVxTYF/1vcYYKP09VnrH/mzoJgrnmS5DG5Y21MlasMX4iyzbnFAFFw7tC9w Yf0C88jkrwroT5jP9CWcO0HVl1+w6dsBIRtgEIXoISXhkkUwL0rXyOYUybU+TDEuslaz tkERBI9LIKniC+//zOAreiPviiYYD7Es1ZSC5H1sPy5i+qdEW3+mvWwfPQPZzvOVnLDl h7+aEsfPCCAdQyFSuq7b9b3jTkzG6btEuDRIVAfrIz14o1b9WWvD2sHnJAJ36J8JZFgQ PrzPq74t/oOkkxIhvofzYuvn7WdRkTfHcIJ1UxUeW3y6BMQ3pdlBeWIFCpmKA5MiAAvK 5WRg== X-Gm-Message-State: ALoCoQmEOKCxOyHdrFOKYL9PUz71iR0aI/L9REiJnAOA6KK5VYXmLhjxYLueiHboS48lqO4Jb2gAPEs2qQu827WJFN/1Ru8Ir4XsqPe04tyWa6pXi/q6PCPqJu3OrE9Spdwk7pCrUCkyDFG6BI1xaTtBonNSZ4GfGw== X-Received: by 10.180.160.240 with SMTP id xn16mr13687606wib.62.1383594544520; Mon, 04 Nov 2013 11:49:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.160.240 with SMTP id xn16mr13687601wib.62.1383594544447; Mon, 04 Nov 2013 11:49:04 -0800 (PST) Received: by 10.194.93.34 with HTTP; Mon, 4 Nov 2013 11:49:04 -0800 (PST) In-Reply-To: <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> References: <010501ced977$79754ff0$6c5fefd0$@shockey.us> <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> Date: Mon, 4 Nov 2013 11:49:04 -0800 Message-ID: From: Michael Procter To: Alex Bobotek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "stir@ietf.org" , "Peterson, Jon" , Richard Shockey Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:49:33 -0000 At this stage, I am less concerned with the precise definition of what constitutes a third party, and to what degree privacy is leaked. I am more concerned with ensuring that we seek to protect the called party too, and not consider the calling party to be the only potential subject of privacy leaks. Michael On 4 November 2013 11:23, Alex Bobotek wrote: > What precisely is a 3rd party in the context of out-of-band validation? = A strict interpretation is that this is any party other than the caller and= callee (or perhaps their carriers). Other interpretations might be a part= y in the middle (e.g., able to access pcaps) who has no role other than per= haps packet transport. > > Such a strict interpretation pretty much rules out the use of public DNS = or similar infrastructure as a store for any individual caller/callee PKI o= r policy; 3rd parties may be in the middle of requests. A similar requirem= ent would break some DKIM implementations. > > IMO, > 1. 3rd party needs to be more precisely defined and/or > 2. The degree of privacy compromise should be, at this stage, subject to= design trades. A "3rd-party" offering reputation/validation services si= milar to a DNS service may have legitimate reasons to know one or more of c= aller/callee. Perhaps the 'requirement' should be recast as a goal or requ= irement to minimize. > > Regards, > > Alex > >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Richard Shockey >> Sent: Monday, November 04, 2013 8:04 AM >> To: 'Peterson, Jon'; 'Michael Procter'; stir@ietf.org >> Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requireme= nts >> >> >> What third party? The carrier? >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Peterson, Jon >> Sent: Monday, November 04, 2013 10:21 AM >> To: Michael Procter; stir@ietf.org >> Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requireme= nts >> >> >> I agree. >> >> Jon Peterson >> Neustar, Inc. >> >> On 11/3/13 5:31 PM, "Michael Procter" wrote: >> >> >In section 7, there is a privacy requirement to prevent 3rd parties >> >from learning what numbers have been called by a specific caller. >> >Should there be a similar requirement to prevent 3rd parties learning >> >what numbers have called a specific callee? >> > >> >The reason I mention it is that there was an issue with an aspect of >> >vipr where a proposed mechanism could protect either the caller's >> >privacy or the callee's privacy but not both. I'd like to avoid a >> >similar situation here. >> > >> >Regards, >> > >> >Michael >> >_______________________________________________ >> >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 >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir From alex@bobotek.net Mon Nov 4 11:56:55 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0DA21E80D9 for ; Mon, 4 Nov 2013 11:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2T2jcwPNi-n for ; Mon, 4 Nov 2013 11:56:50 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4B711E8175 for ; Mon, 4 Nov 2013 11:56:50 -0800 (PST) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta03.emeryville.ca.mail.comcast.net with comcast id lUJn1m0061u4NiLA3Xwq14; Mon, 04 Nov 2013 19:56:50 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by omta21.emeryville.ca.mail.comcast.net with comcast id lXwp1m0064EJ4tY8hXwpSA; Mon, 04 Nov 2013 19:56:50 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Mon, 4 Nov 2013 11:44:42 -0800 From: Alex Bobotek To: Michael Procter Date: Mon, 4 Nov 2013 11:44:41 -0800 Thread-Topic: [stir] draft-ietf-stir-problem-statement: Privacy requirements Thread-Index: Ac7ZlUXqrxQyKBrNQVKnmJhRp/d7wwAAdzEg Message-ID: <4B1956260CD29F4A9622F00322FE0531D0FDE6C378@BOBO1A.bobotek.net> References: <010501ced977$79754ff0$6c5fefd0$@shockey.us> <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383595010; bh=hUk0lYuNiQMuD/53JgU1VszRRoJ0Fx3bb2isYZ/Z+ss=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=kiKqkWZLgsn7hsQO1oY+R73I0sPEIVg5juhPd9xANsNa7p0JNi9Nl2Xg79qRMMoA5 WNFKlNHRcfDHOLbe2WFnrj+AMYAzLl5f+l7TFjNVWTCx1oNeyvOVSxmxqI0PIVqIIj B3qNbe+jIFzUUcpXg/5a3Ql2EIvCniX5dzSfGGG3NIjW92n3iG9BHlo1+wgO69rdyN VX3c6t2UDMUqPI1ymMHNoFHoFbUNH6H1EYojU3/Vq/QQ52NIyw8yVmC+hkdPYfFVL6 Ryh+/lc3wqyAdTbvHnhcf9Egwl1SXDsZtWtg6AvdBhDbnLdnPxZMIlwy9+Tj7Qy25D nOJyyH1uu3DwA== Cc: "stir@ietf.org" , "Peterson, Jon" , Richard Shockey Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:56:55 -0000 I believe we agree with the need for calling and called party privacy prote= ction. It's a good thing that this issue was raised. But we have another issue; a requirement restricting 3rd party visibility t= hat is ambiguous and/or overly strict. Regards, Alex > -----Original Message----- > From: Michael Procter [mailto:michael@voip.co.uk] > Sent: Monday, November 04, 2013 11:49 AM > To: Alex Bobotek > Cc: Richard Shockey; Peterson, Jon; stir@ietf.org > Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requiremen= ts >=20 > At this stage, I am less concerned with the precise definition of what > constitutes a third party, and to what degree privacy is leaked. I am mo= re > concerned with ensuring that we seek to protect the called party too, and > not consider the calling party to be the only potential subject of privac= y leaks. >=20 > Michael >=20 > On 4 November 2013 11:23, Alex Bobotek wrote: > > What precisely is a 3rd party in the context of out-of-band validation?= A > strict interpretation is that this is any party other than the caller and= callee (or > perhaps their carriers). Other interpretations might be a party in the m= iddle > (e.g., able to access pcaps) who has no role other than perhaps packet > transport. > > > > Such a strict interpretation pretty much rules out the use of public DN= S or > similar infrastructure as a store for any individual caller/callee PKI or= policy; > 3rd parties may be in the middle of requests. A similar requirement woul= d > break some DKIM implementations. > > > > IMO, > > 1. 3rd party needs to be more precisely defined and/or > > 2. The degree of privacy compromise should be, at this stage, subject = to > design trades. A "3rd-party" offering reputation/validation services s= imilar > to a DNS service may have legitimate reasons to know one or more of > caller/callee. Perhaps the 'requirement' should be recast as a goal or > requirement to minimize. > > > > Regards, > > > > Alex > > > >> -----Original Message----- > >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > >> Of Richard Shockey > >> Sent: Monday, November 04, 2013 8:04 AM > >> To: 'Peterson, Jon'; 'Michael Procter'; stir@ietf.org > >> Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy > >> requirements > >> > >> > >> What third party? The carrier? > >> > >> -----Original Message----- > >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > >> Of Peterson, Jon > >> Sent: Monday, November 04, 2013 10:21 AM > >> To: Michael Procter; stir@ietf.org > >> Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy > >> requirements > >> > >> > >> I agree. > >> > >> Jon Peterson > >> Neustar, Inc. > >> > >> On 11/3/13 5:31 PM, "Michael Procter" wrote: > >> > >> >In section 7, there is a privacy requirement to prevent 3rd parties > >> >from learning what numbers have been called by a specific caller. > >> >Should there be a similar requirement to prevent 3rd parties > >> >learning what numbers have called a specific callee? > >> > > >> >The reason I mention it is that there was an issue with an aspect of > >> >vipr where a proposed mechanism could protect either the caller's > >> >privacy or the callee's privacy but not both. I'd like to avoid a > >> >similar situation here. > >> > > >> >Regards, > >> > > >> >Michael > >> >_______________________________________________ > >> >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 > >> > >> _______________________________________________ > >> stir mailing list > >> stir@ietf.org > >> https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Mon Nov 4 12:20:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EF721E808D for ; Mon, 4 Nov 2013 12:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.084 X-Spam-Level: X-Spam-Status: No, score=-102.084 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHRCLl7LrIBi for ; Mon, 4 Nov 2013 12:20:42 -0800 (PST) Received: from outbound-ss-2175.bluehost.com (outbound-ss-2175.bluehost.com [74.220.218.8]) by ietfa.amsl.com (Postfix) with SMTP id 18C4611E822D for ; Mon, 4 Nov 2013 12:20:42 -0800 (PST) Received: (qmail 16359 invoked by uid 0); 4 Nov 2013 20:20:37 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy16-pub.mail.unifiedlayer.com with SMTP; 4 Nov 2013 20:20:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=XPC9OD+hpQbQZh+neOfwjXVO54T9JIEuLpvN6aDU9lI=; b=fn/VPXspxFyCu9H9F3nVggbsSQnUgLu7eKaSxLKIJlGY0wzQ+NPSIsb96kE8b7qXS/Z4cEtL6WH+ipbMIjfhcoyYZfwdKb4c7nmojjnQ6SSKSOjZeEB6L62O2aymJEU4; Received: from [173.79.179.104] (port=58641 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VdQdY-0002o9-GY; Mon, 04 Nov 2013 13:20:36 -0700 From: "Richard Shockey" To: "'Alex Bobotek'" , "'Michael Procter'" References: <010501ced977$79754ff0$6c5fefd0$@shockey.us> <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531D0FDE6C378@BOBO1A.bobotek.net> In-Reply-To: <4B1956260CD29F4A9622F00322FE0531D0FDE6C378@BOBO1A.bobotek.net> Date: Mon, 4 Nov 2013 15:20:34 -0500 Message-ID: <003301ced99b$52c9fad0$f85df070$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDDWDW6IE6KEFhJRBuah8sjx8siOwMZKMMaAVwEOkICWLvxUADlY7oNAiEgV1yb3eB6IA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: stir@ietf.org, "'Peterson, Jon'" Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:20:47 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Alex Bobotek Sent: Monday, November 04, 2013 2:45 PM To: Michael Procter Cc: stir@ietf.org; Peterson, Jon; Richard Shockey Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements I believe we agree with the need for calling and called party privacy protection. It's a good thing that this issue was raised. [RS> ] [RS> ] Well I don't believe in Calling Party Privacy at all if, under the proper cirmctances there is violation of national laws such as fraud, abuse and the violation of the called party's privacy and warrants are issued under the appropriate review process. But we have another issue; a requirement restricting 3rd party visibility that is ambiguous and/or overly strict. [RS> ] [RS> ] Exactly.. And a touch too politically correct for the current environment. So who is the third party? Under what circumstances could there actually be voluntary release of verbose metadata to third parties in the interest of law enforcement. This is all very very slippery slope folks. Michael given the nature of the problem statement whose privacy are you trying to protect here. Regards, Alex > -----Original Message----- > From: Michael Procter [mailto:michael@voip.co.uk] > Sent: Monday, November 04, 2013 11:49 AM > To: Alex Bobotek > Cc: Richard Shockey; Peterson, Jon; stir@ietf.org > Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy > requirements > > At this stage, I am less concerned with the precise definition of what > constitutes a third party, and to what degree privacy is leaked. I am > more concerned with ensuring that we seek to protect the called party > too, and not consider the calling party to be the only potential subject of privacy leaks. > > Michael > > On 4 November 2013 11:23, Alex Bobotek wrote: > > What precisely is a 3rd party in the context of out-of-band > > validation? A > strict interpretation is that this is any party other than the caller > and callee (or perhaps their carriers). Other interpretations might > be a party in the middle (e.g., able to access pcaps) who has no role > other than perhaps packet transport. > > > > Such a strict interpretation pretty much rules out the use of public > > DNS or > similar infrastructure as a store for any individual caller/callee PKI > or policy; 3rd parties may be in the middle of requests. A similar > requirement would break some DKIM implementations. > > > > IMO, > > 1. 3rd party needs to be more precisely defined and/or 2. The > > degree of privacy compromise should be, at this stage, subject to > design trades. A "3rd-party" offering reputation/validation services similar > to a DNS service may have legitimate reasons to know one or more of > caller/callee. Perhaps the 'requirement' should be recast as a goal > or requirement to minimize. > > > > Regards, > > > > Alex > > > >> -----Original Message----- > >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On > >> Behalf Of Richard Shockey > >> Sent: Monday, November 04, 2013 8:04 AM > >> To: 'Peterson, Jon'; 'Michael Procter'; stir@ietf.org > >> Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy > >> requirements > >> > >> > >> What third party? The carrier? > >> > >> -----Original Message----- > >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On > >> Behalf Of Peterson, Jon > >> Sent: Monday, November 04, 2013 10:21 AM > >> To: Michael Procter; stir@ietf.org > >> Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy > >> requirements > >> > >> > >> I agree. > >> > >> Jon Peterson > >> Neustar, Inc. > >> > >> On 11/3/13 5:31 PM, "Michael Procter" wrote: > >> > >> >In section 7, there is a privacy requirement to prevent 3rd > >> >parties from learning what numbers have been called by a specific caller. > >> >Should there be a similar requirement to prevent 3rd parties > >> >learning what numbers have called a specific callee? > >> > > >> >The reason I mention it is that there was an issue with an aspect > >> >of vipr where a proposed mechanism could protect either the > >> >caller's privacy or the callee's privacy but not both. I'd like > >> >to avoid a similar situation here. > >> > > >> >Regards, > >> > > >> >Michael > >> >_______________________________________________ > >> >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 > >> > >> _______________________________________________ > >> 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 michael@voip.co.uk Mon Nov 4 12:41:34 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B8821E8064 for ; Mon, 4 Nov 2013 12:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTE2jBkSvpn1 for ; Mon, 4 Nov 2013 12:41:28 -0800 (PST) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with SMTP id 34CE311E8125 for ; Mon, 4 Nov 2013 12:41:27 -0800 (PST) Received: from mail-wg0-f45.google.com ([74.125.82.45]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKUngGd0uJZp/E4MN1mv1lEIdl5ExkgfCJ@postini.com; Mon, 04 Nov 2013 12:41:28 PST Received: by mail-wg0-f45.google.com with SMTP id z12so2627482wgg.0 for ; Mon, 04 Nov 2013 12:41:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i9Hg/OhcHcA8dAlzOn3qp9iD1x4ZfiMxItYO2gyxyaM=; b=E/gyKZmXgXXACjEslsuJrATXNepESQIMMmo3cc97gErm+cudG5TjGAY4Yk1Otd2GUW BuLJxHZzt71+2NUwkJFJnSM0Qarueie2B7e1BoNjGXWjlz6uzyNut1VPx8iA1nUI28kd tXEmPewC5sVgAoEgUZekRcuwcN0yLN9TuWR0n5AvXYo/wuVbUPLGN1phbNZeyC8Xv+j2 U5BlFzAZjVLJ1GqdhVTT0PLQJplxLLePsxaqm8Stmfqt1o7cVhF0O94nl+/+RiVlJMRD fuDXNpGTsD2fynXy/bBfrv9QQhle5n8SwurqwriGKnbO2BHoC9HMvSVa9W6Bs+FGzWGC sIVg== X-Gm-Message-State: ALoCoQmDDRwVDQVXIZymbaNe8Hdnm+vt7JIjBOWRNysFSgrM8zRq68SZXWyZGkGMS6SuBSXYMM75ABUrFNlXpvEt6I1HQcUIk9Th990PGWJiLOcHiHNwPlnFxqnmNhw9BM3FdA7NebVc7EoDgjZ4EOQ4PO5OKWe63g== X-Received: by 10.180.160.240 with SMTP id xn16mr13854743wib.62.1383597686344; Mon, 04 Nov 2013 12:41:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.160.240 with SMTP id xn16mr13854738wib.62.1383597686275; Mon, 04 Nov 2013 12:41:26 -0800 (PST) Received: by 10.194.93.34 with HTTP; Mon, 4 Nov 2013 12:41:26 -0800 (PST) In-Reply-To: <003301ced99b$52c9fad0$f85df070$@shockey.us> References: <010501ced977$79754ff0$6c5fefd0$@shockey.us> <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531D0FDE6C378@BOBO1A.bobotek.net> <003301ced99b$52c9fad0$f85df070$@shockey.us> Date: Mon, 4 Nov 2013 12:41:26 -0800 Message-ID: From: Michael Procter To: Richard Shockey Content-Type: text/plain; charset=ISO-8859-1 Cc: "stir@ietf.org" , Alex Bobotek , "Peterson, Jon" Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:41:34 -0000 On 4 November 2013 12:20, Richard Shockey wrote: > Michael given the nature of the problem statement whose privacy are you > trying to protect here. I'm trying to protect the privacy of the called party. Given the privacy problems discovered in vipr and given the number of references to vipr and vipr-like technology in stir, I'd prefer to avoid the situation where we end up with a design that involves spraying messages like "I've just been called by a (debt collector|STD clinic|divorce lawyer), how do I check it is really them?" to anyone who happens to be participating in whatever distributed hashtable/database/lookup function we end up picking. Since the problem statement already offers a requirement for protecting the calling party, I'd like to see a similar protection for the called party. Arguably, the called party should have a higher level of privacy: they didn't choose to be called in the first place. The alternative (having the called party essentially advertise their incoming calls in order to be able to verify the identity) is hardly likely to encourage widespread deployment of verification. Michael From aallen@blackberry.com Mon Nov 4 13:53:43 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37C311E81A7 for ; Mon, 4 Nov 2013 13:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SARE_PRODUCT=0.333] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU3-edqt3zbT for ; Mon, 4 Nov 2013 13:53:37 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7646911E80D9 for ; Mon, 4 Nov 2013 13:53:37 -0800 (PST) Received: from xct104ads.rim.net ([10.67.111.45]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 04 Nov 2013 16:53:32 -0500 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 15:53:31 -0600 From: Andrew Allen To: "Peterson, Jon" , "stir@ietf.org" Thread-Topic: [stir] comments on draft-ietf-stir-problem-statement-00 Thread-Index: Ac7QUSi+XuSwVM/UQPSEhXox+oZw/gJFOdUAABAW9IA= Date: Mon, 4 Nov 2013 21:53:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E472B9XMB104ADSrimnet_" MIME-Version: 1.0 Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:53:43 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E472B9XMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Jon My responses inline Andrew From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Monday, November 04, 2013 11:59 AM To: Andrew Allen; stir@ietf.org Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 Hi Andrew, Catching up on this mail; thanks for these comments, you have some good cat= ches here. I think we're mostly cool but a couple points we might discuss f= urther: Section 6.1 I think this text should be generalized to talk about mobile instant messag= ing services in the abstract and not describe a single vendors product offe= ring. Potentially a plurality of instant messaging services from multiple v= endors could form a basis for a general solution if instant messaging ends = up being part of the solution. This text isn't trying to shill for any particular vendor, really it is jus= t trying to provide an existence proof. I certainly wouldn't object to ment= ioning other similar services here that corroborate that existence proof. [AA] Is there anything special about iMessage of potential relevance in STI= R problem space that isn't reflected by many of the other mobile messaging = services out there that make it worthy of being a good example over others = or over mobile IM applications in general? I don't think just the fact that= some people happen to be familiar with iMessage is sufficient justificatio= n to make it a good example to use in the draft - particularly since it has= short comings such as being currently restricted to a single platform. I b= elieve Whatsapp has the most user's and also has multi vendor support. I su= ppose a list of e.g's is OK but I don't see why we need to describe in any = detail a specific service - since most of them have similar characteristics. Section 6.5 Due to roaming and countless other factors, calls on the PSTN may emerge fr= om administrative domains that have no relationship with the number assignee I am not convinced that roaming (at least in the traditional sense of cellu= lar roaming - and this will continue to be the case with IMS roaming) means= that calls will emerge from administrative domains that have no relationsh= ip with the number assignee. In cellular roaming there is a very close rela= tionship between the roamed to network and there are trust domains between= them and authentication of the mobile involving cooperation between the ho= me network that is the number assignee and the roamed to network. If roamin= g here means something else then please clarify. The administrative domain has no relationship with the number assignee in t= he sense that the number assignee is not a customer of that administrative = domain and doesn't pay money to it directly. Totally agreed that there are = trust relationships between carriers that make roaming possible, but the re= levant bit here for STIR is about who assigns the number and who serves the= call. When I come here to Vancouver, my cell phone roams from AT&T to Rodg= ers. Rogers is not the carrier to whom my cell phone number is assigned for= STIR purposes, but they serve my calls and texts while I'Mhere . Still, if= this is confusing from the text we need to make it clearer. [AA] My problem is with the statement "domains that have no relationship wi= th the number assignee" Certainly they have a relationship - in fact a clos= e and trusted one and the home domain provides the number to assert to the = roamed to domain. So I think it needs to be made clearer. Minimal payload overhead: Must lead to minimal expansion of SIP header= s fields to avoid fragmentation in deployments that use UDP. Is this really a MUST strength requirement? Whatever solution we come up wi= th that requires enhancement to SIP requires some enhancement. TCP is alway= s available to use if message sizes become too large and since the deployed= systems will need to be enhanced they can be (even should be) enhanced to = support TCP. I think in many cases SIP and SDP has already grown to such an= extent (ICE candidates, preconditions, SDP cap neg attributes, increasing = number of codecs and media lines etc...) that we are already at the point w= here we are perilously close to or already over the 1300 byte recommendatio= n in many scenarios. Any size increase at all may break the camel's back o= n the UDP fragmentation issue. I think at best this is guidance that messag= e size is a factor to consider in evaluating a solution not an overriding r= equirement. Well, the "musts" here aren't normative, but I hear you. I don't have that = strong an intuition about this. [AA] OK. It's an advantage to be smaller but it's not overiding Jon Peterson Neustar, Inc. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338E472B9XMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Jon<= /p>

 

My responses inline

 

Andrew

 

From: Peterson= , Jon [mailto:jon.peterson@neustar.biz]
Sent: Monday, November 04, 2013 11:59 AM
To: Andrew Allen; stir@ietf.org
Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00=

 

&n= bsp;

Hi Andr= ew,

&n= bsp;

Catchin= g up on this mail; thanks for these comments, you have some good catches he= re. I think we're mostly cool but a couple points we might discuss further:=

 

<AA>Section 6.1

<snip>

 

I think this text should be generalize= d to talk about mobile instant messaging services in the abstract and not d= escribe a single vendors product offering. Potentially a plurality of instant messaging services from multiple vendor= s could form a basis for a general solution if instant messaging ends up be= ing part of the solution.</AA>

&n= bsp;

This te= xt isn't trying to shill for any particular vendor, really it is just tryin= g to provide an existence proof. I certainly wouldn't object to mentioning = other similar services here that corroborate that existence proof.

[AA] Is there anything special about= iMessage of potential relevance in STIR problem space that isn’t reflected by many of the other mobile messaging services out t= here that make it worthy of being a good example over others or over mobile= IM applications in general? I don’t think just the fact that some pe= ople happen to be familiar with iMessage is sufficient justification to make it a good example to use in the draft = 211; particularly since it has short comings such as being currently restri= cted to a single platform. I believe Whatsapp has the most user’s and= also has multi vendor support. I suppose a list of e.g’s is OK but I don’t see why we need to describe in= any detail a specific service – since most of them have similar char= acteristics.

<AA>Section 6.5

 

Due to roaming and countless other factors, calls on the PSTN may emerge f= rom administrative domains that have no relationship with the number assignee

 

I am not convinced that roaming (at le= ast in the traditional sense of cellular roaming - and this will continue t= o be the case with IMS roaming) means that calls will emerge from administrative domains that have no relationsh= ip with the number assignee. In cellular roaming there is a very close rela= tionship between the roamed  to network and there are trust domains be= tween them and authentication of the mobile involving cooperation between the home network that is the number a= ssignee and the roamed to network. If roaming here means something else the= n please clarify.</AA>

&n= bsp;

The administrative domain has no relationship with the number assi= gnee in the sense that the number assignee is not a customer of that admini= strative domain and doesn't pay money to it directly. Totally agreed that there are trust relationships bet= ween carriers that make roaming possible, but the relevant bit here for STI= R is about who assigns the number and who serves the call. When I = ;come here to Vancouver, my cell phone roams from AT&T to Rodgers. Rogers is not the carrier to whom my cell phone numbe= r is assigned for STIR purposes, but they serve my calls and texts while&nb= sp;I'Mhere . Still, if this is confusing from the text we need to make= it clearer.

 

[AA] My problem is with the statemen= t “domains that have no relatio= nship with the number assignee” Certainly they have a relationship= – in fact a close and trusted one and the home domain provides the n= umber to assert to the roamed to domain.  So I think it needs to be ma= de clearer.

 
<AA>Minimal payload overhead:  =
Must lead to minimal expansion of SIP headers fields to avoid fragmentation=
 in deployments that use UDP.
 

Is this really a MUST strength requirement? Whatever solutio= n we come up with that requires enhancement to SIP requires some enhancement. TCP is always available to use if message sizes= become too large and since the deployed systems will need to be enhanced t= hey can be (even should be) enhanced to support TCP. I think in many cases = SIP and SDP has already grown to such an extent (ICE candidates, preconditions, SDP cap neg attributes, inc= reasing number of codecs and media lines etc…) that we are already at= the point where we are perilously close to or already over the 1300 byte r= ecommendation in many scenarios.  Any size increase at all may break the camel’s back on the UDP fragmenta= tion issue. I think at best this is guidance that message size is a factor = to consider in evaluating a solution not an overriding requirement.</AA&= gt;

 

Well, the "musts" here aren't normative, b= ut I hear you. I don't have that strong an intuition ab= out this. 

 

[AA] OK.  It̵= 7;s an advantage to be smaller but it’s not overiding

 

Jon Peterson

Neustar, Inc.

---------------------------------------------------------------------
Th= is transmission (including any attachments) may contain confidential inform= ation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immed= iately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by uni= ntended recipients is not authorized and may be unlawful.
--_000_BBF5DDFE515C3946BC18D733B20DAD2338E472B9XMB104ADSrimnet_-- From kent@bbn.com Mon Nov 4 13:56:05 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FA011E81AF for ; Mon, 4 Nov 2013 13:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkvK6-1jFdU8 for ; Mon, 4 Nov 2013 13:55:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6D26F21E8082 for ; Mon, 4 Nov 2013 13:55:00 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:46700 helo=dhcp-a369.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VdS6t-000Guf-7d for stir@ietf.org; Mon, 04 Nov 2013 16:54:59 -0500 Message-ID: <527817B3.3020400@bbn.com> Date: Mon, 04 Nov 2013 16:54:59 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: stir@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:56:05 -0000 Jon, > I suspect Rich is right that we are in a position to make credible > recommendations about credential distribution and management, but that if > we are serious about tying these credential structures to the national > authorities, then it will be those authorities and their various industry > bodies that make the ultimate decisions here. Consequently the situation > is fluid, and difficult to anticipate. Which is a good reason for a > modular design. Modular is good. Vague is not. I found the descriptions of the actors to be so vague that it was very hard for me to figure out what instantiations of modules were valid, invalid, preferred, etc. Steve From richard@shockey.us Mon Nov 4 14:41:19 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F6721E8056 for ; Mon, 4 Nov 2013 14:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.803 X-Spam-Level: X-Spam-Status: No, score=-101.803 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUK7AVXZdH9n for ; Mon, 4 Nov 2013 14:41:14 -0800 (PST) Received: from oproxy19-pub.mail.unifiedlayer.com (oproxy19-pub.mail.unifiedlayer.com [70.40.200.33]) by ietfa.amsl.com (Postfix) with SMTP id EF9AB21E80E8 for ; Mon, 4 Nov 2013 14:41:10 -0800 (PST) Received: (qmail 5220 invoked by uid 0); 4 Nov 2013 22:41:10 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy19-pub.mail.unifiedlayer.com with SMTP; 4 Nov 2013 22:41:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=HYq+xTIOakJ4yDtW1VWUfbftAPL0DnFLS2MQsU5qCb4=; b=GOU4miJJcpSSLuIcX1cRBDDPHM4nWEY6ecLZB5FT/CnVn69xTHgORBE2TYc1nIm9cujHERnH26Cj4TZzhPmb0OeFHfpx1D99TeMzM1Ybj9eGjtcSqcH1Aby4xq70JNpk; Received: from [173.79.179.104] (port=60670 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VdSpa-0005bz-3e; Mon, 04 Nov 2013 15:41:10 -0700 From: "Richard Shockey" To: "'Michael Procter'" References: <010501ced977$79754ff0$6c5fefd0$@shockey.us> <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531D0FDE6C378@BOBO1A.bobotek.net> <003301ced99b$52c9fad0$f85df070$@shockey.us> In-Reply-To: Date: Mon, 4 Nov 2013 17:41:09 -0500 Message-ID: <011001ced9ae$f59395b0$e0bac110$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDDWDW6IE6KEFhJRBuah8sjx8siOwMZKMMaAVwEOkICWLvxUADlY7oNAiEgV1wBrzNXMwGGiYXKm8RYDqA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: stir@ietf.org, 'Alex Bobotek' , "'Peterson, Jon'" Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:41:19 -0000 Yes thank you very much. That is my point exactly. It would be my preference that any reference to VIPR or iMessage or these extraneous and specious existence proofs be completely removed from the documents. They say nothing they offer nothing and VIPR as I have pointed out several times was a total and complete failure as an IETF protocol. I completely agree with you the emphasis here is on the privacy of the called party. That is the whole point of the exercise. It's the call party that need some for lack of a better word ..Reassurance. Which is why I wanted to start a thread on verbose CNAM as well. The methods of Track and Trace for the example you cite is out of our scope but it has some relevance. I'm aware of several T-DOS attacks against UK based services. We should be careful about what we try and require. From time to time we may want certain records exposed for perfectly ligimate reasons. Nothing we do will protect us from the political class. I live in Virginia here the US and we have a Governor's race that is simply ... -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Procter Sent: Monday, November 04, 2013 3:41 PM To: Richard Shockey Cc: stir@ietf.org; Alex Bobotek; Peterson, Jon Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements On 4 November 2013 12:20, Richard Shockey wrote: > Michael given the nature of the problem statement whose privacy are > you trying to protect here. I'm trying to protect the privacy of the called party. Given the privacy problems discovered in vipr and given the number of references to vipr and vipr-like technology in stir, I'd prefer to avoid the situation where we end up with a design that involves spraying messages like "I've just been called by a (debt collector|STD clinic|divorce lawyer), how do I check it is really them?" to anyone who happens to be participating in whatever distributed hashtable/database/lookup function we end up picking. Since the problem statement already offers a requirement for protecting the calling party, I'd like to see a similar protection for the called party. Arguably, the called party should have a higher level of privacy: they didn't choose to be called in the first place. The alternative (having the called party essentially advertise their incoming calls in order to be able to verify the identity) is hardly likely to encourage widespread deployment of verification. Michael _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Mon Nov 4 15:26:44 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4891421E80B5 for ; Mon, 4 Nov 2013 15:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.252 X-Spam-Level: X-Spam-Status: No, score=-106.252 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeTcs2jZaWsg for ; Mon, 4 Nov 2013 15:26:39 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C5AB411E8216 for ; Mon, 4 Nov 2013 15:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383607753; x=1698960011; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=G4GEXGxIjno1t2ulNGpcdiS1R4yVe9383X1gPmR1E3w=; b=i74GvxCeOAtHCNyQmQ1A9EaGt1h6eY3SbzndUip0sF9XUjB/b+M+xTZeOcLoaY 3HXLXHyJQllgOneZIywdOHJA== Received: from ([10.31.58.71]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.33277777; Mon, 04 Nov 2013 18:29:12 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 4 Nov 2013 18:26:23 -0500 From: "Peterson, Jon" To: Andrew Allen , "stir@ietf.org" Thread-Topic: [stir] comments on draft-ietf-stir-problem-statement-00 Thread-Index: Ac7QUSi+XuSwVM/UQPSEhXox+oZw/gJFOdUAABAW9ID//+tngA== Date: Mon, 4 Nov 2013 23:26:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.128.72] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: o3VEgixhbV4JgkxfTUA3Ig== Content-Type: multipart/alternative; boundary="_000_CE9D6AEFAF113jonpetersonneustarbiz_" MIME-Version: 1.0 Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:26:44 -0000 --_000_CE9D6AEFAF113jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don=92t think just the fact that some people happen to be familiar wi= th iMessage is sufficient justification to make it a good example to use in= the draft =96 particularly since it has short comings such as being curren= tly restricted to a single platform. I believe Whatsapp has the most user= =92s and also has multi vendor support. I suppose a list of e.g=92s is OK b= ut I don=92t see why we need to describe in any detail a specific service = =96 since most of them have similar characteristics. I think the fact that people are familiar with iMessage is a very good reas= on to list it as one example. I'm happy to include other examples, includin= g Whatsapp. I would also be happy to make the descriptive text there less s= pecific to any particular vendor, but I do have a hard time seeing how list= ing iMessage here would make people misunderstand the problem statement. [AA] My problem is with the statement =93domains that have no relationship = with the number assignee=94 Certainly they have a relationship =96 in fact = a close and trusted one and the home domain provides the number to assert t= o the roamed to domain. So I think it needs to be made clearer. Okay, per the text I sent in my last mail, we can make this clearer. Again,= what this means for STIR is that the the roaming carrier won't have the au= thority over the number. Jon Peterson Neustar, Inc. --_000_CE9D6AEFAF113jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
<AA>I don= =92t think just the fact that some people happen to be familiar with iMessage is sufficient justification to make it a good= example to use in the draft =96 particularly since it has short comings su= ch as being currently restricted to a single platform. I believe Whatsapp h= as the most user=92s and also has multi vendor support. I suppose a list of e.g=92s is OK but I don=92t see why we= need to describe in any detail a specific service =96 since most of them h= ave similar characteristics.</AA>

I think the fact that people are familiar with iMessage is a very = good reason to list it as one example. I'm happy to include other examples,= including Whatsapp. I would also be happy to make the descriptive text there less specific to any particular v= endor, but I do have a hard time seeing how listing iMessage here would mak= e people misunderstand the problem statement.

 

[AA] My problem is with the statemen= t =93domains that have no relationshi= p with the number assignee=94 Certainly they have a relationship= =96 in fact a close and trusted one and the home domain provides the numbe= r to assert to the roamed to domain.  So I think it needs to be made c= learer.

 
Okay, per the text I sent in my last mail, we can make this clearer. A= gain, what this means for STIR is that the the roaming carrier won't have t= he authority over the number. 

Jon Peterson

Neustar, Inc.


 --_000_CE9D6AEFAF113jonpetersonneustarbiz_-- From richard@shockey.us Mon Nov 4 17:27:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE13C21E80FE for ; Mon, 4 Nov 2013 17:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fcmhb6tByGN for ; Mon, 4 Nov 2013 17:27:26 -0800 (PST) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 47EE021E80C2 for ; Mon, 4 Nov 2013 17:27:26 -0800 (PST) Received: (qmail 11872 invoked by uid 0); 5 Nov 2013 01:27:03 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.mail.unifiedlayer.com with SMTP; 5 Nov 2013 01:27:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=cGG6vt2XNnF4cQX0bHOUDYCcJ5scY3IumwsZ5lE6gYY=; b=Hp+3N4a4spq1Um8vyNtKVmffpnd+maNn6RTthhA7dY9Wt0zdJ8G/O12Jq5yI5u3wNOnP+b56/r2UxTidtIIm2H8kKrBshENRytPPWugRb80PzhtdnJKLJad2yXyhIwJF; Received: from [173.79.179.104] (port=61887 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VdVQ7-0003L5-BD; Mon, 04 Nov 2013 18:27:03 -0700 From: "Richard Shockey" To: "'Peterson, Jon'" , "'Andrew Allen'" , References: In-Reply-To: Date: Mon, 4 Nov 2013 20:27:02 -0500 Message-ID: <018401ced9c6$22242830$666c7890$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0185_01CED99C.394FA6D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHF7qBBDWfLpjEX0Z5JrqUyO/VCtJonrsRQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 01:27:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0185_01CED99C.394FA6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jon .. what about NO don't you understand. We object to the references. Remove them now. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Monday, November 04, 2013 6:26 PM To: Andrew Allen; stir@ietf.org Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 I don't think just the fact that some people happen to be familiar with iMessage is sufficient justification to make it a good example to use in the draft - particularly since it has short comings such as being currently restricted to a single platform. I believe Whatsapp has the most user's and also has multi vendor support. I suppose a list of e.g's is OK but I don't see why we need to describe in any detail a specific service - since most of them have similar characteristics. I think the fact that people are familiar with iMessage is a very good reason to list it as one example. I'm happy to include other examples, including Whatsapp. I would also be happy to make the descriptive text there less specific to any particular vendor, but I do have a hard time seeing how listing iMessage here would make people misunderstand the problem statement. [AA] My problem is with the statement "domains that have no relationship with the number assignee" Certainly they have a relationship - in fact a close and trusted one and the home domain provides the number to assert to the roamed to domain. So I think it needs to be made clearer. Okay, per the text I sent in my last mail, we can make this clearer. Again, what this means for STIR is that the the roaming carrier won't have the authority over the number. Jon Peterson Neustar, Inc. ------=_NextPart_000_0185_01CED99C.394FA6D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jon .. what about NO don’t you = understand. 

 

We object to the = references. Remove them now.

 

From: stir-bounces@ietf.org = [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, = Jon
Sent: Monday, November 04, 2013 6:26 PM
To: = Andrew Allen; stir@ietf.org
Subject: Re: [stir] comments on = draft-ietf-stir-problem-statement-00

 

<AA>I don’t think just the fact that = some people happen to be familiar with iMessage is sufficient = justification to make it a good example to use in the draft – = particularly since it has short comings such as being currently = restricted to a single platform. I believe Whatsapp has the most = user’s and also has multi vendor support. I suppose a list of = e.g’s is OK but I don’t see why we need to describe in any = detail a specific service – since most of them have similar = characteristics.</AA>

 

I think the fact that people are familiar with = iMessage is a very good reason to list it as one example. I'm happy to = include other examples, including Whatsapp. I would also be happy to = make the descriptive text there less specific to any particular vendor, = but I do have a hard time seeing how listing iMessage here would make = people misunderstand the problem = statement.

 

[AA] My problem is with the statement = “domains that have no = relationship with the number assignee” Certainly they have a relationship – in = fact a close and trusted one and the home domain provides the number to = assert to the roamed to domain.  So I think it needs to be made = clearer.

 

Okay, per the text I sent in my last = mail, we can make this clearer. Again, what this means for STIR is that = the the roaming carrier won't have the authority over the = number. 

 

Jon Peterson

Neustar, Inc.

 

=
------=_NextPart_000_0185_01CED99C.394FA6D0-- From fluffy@cisco.com Mon Nov 4 18:20:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFF821E836A for ; Mon, 4 Nov 2013 18:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.564 X-Spam-Level: X-Spam-Status: No, score=-110.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TAPeLyAtLmj for ; Mon, 4 Nov 2013 18:20:43 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C679421E818C for ; Mon, 4 Nov 2013 18:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=822; q=dns/txt; s=iport; t=1383618037; x=1384827637; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6+oXdRkfhiPop8IrjmLDbApbWC7tKyvN9uD84t1OCik=; b=EbGwxFp7s6We9ZQqDccZIgxyvPRZV7jzT0Y7XkA/uiZQTGxsmqF9fWGI HzlEyhcuwY4rYEGRCz/hkthkgCfLpU41c94CJI73v+5o8BjtCVyKnwfAT 99jagNWmzVCZ3CGUe7EmzoT9EfHpdZWT6WkmjpjdQky9RBK525a4HNzOb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAKZUeFKtJXG+/2dsb2JhbABZgweBC787gSgWdIIlAQEBAwE6PwULAgEINhAyJQIEDgWHewa+PY8YMweDIIEOA5NphCGSCYMmgio X-IronPort-AV: E=Sophos;i="4.93,637,1378857600"; d="scan'208";a="280676839" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 05 Nov 2013 02:20:37 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA52Kb1m032192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 02:20:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 20:20:36 -0600 From: "Cullen Jennings (fluffy)" To: Richard Shockey Thread-Topic: [stir] draft-ietf-stir-problem-statement: Privacy requirements Thread-Index: AQHO2P2fB4cu8GPskk2gP2GFZeAL75oVlWoAgAAMIACAADeoAIAABzwA///+x4CAAAoGAIAABdUAgAAhcoCAAD4PAA== Date: Tue, 5 Nov 2013 02:20:36 +0000 Message-ID: <5A55ABD0-A909-4061-AB5C-CE74EDD2B90F@cisco.com> References: <010501ced977$79754ff0$6c5fefd0$@shockey.us> <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531D0FDE6C378@BOBO1A.bobotek.net> <003301ced99b$52c9fad0$f85df070$@shockey.us> <011001ced9ae$f59395b0$e0bac110$@shockey.us> In-Reply-To: <011001ced9ae$f59395b0$e0bac110$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.74.79] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Alex Bobotek , Michael Procter , "Peterson, Jon" Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:20:49 -0000 On Nov 4, 2013, at 2:41 PM, Richard Shockey wrote: > They say nothing they offer nothing and VIPR as I have pointed > out several times was a total and complete failure as an IETF protocol.=20 Richard, respectfully, I don't think you have any clue or basis of informat= ion to say that. A fairly significant percentage of enterprise phones are V= iPR enabled. I'd be willing to guess that I have a long list of IETF protoc= ols that get less use and a short list of protocols that get more. iMessage= which is very similar technology has even far broader deployment and impac= t.=20 That said, I agree with Michael's comment that it is important to learn fro= m the privacy issues in ViPR and make sure we get down requirements that tu= rned out to be a late surprise in ViPR.=20 From jon.peterson@neustar.biz Mon Nov 4 18:20:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EB021E818C for ; Mon, 4 Nov 2013 18:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.271 X-Spam-Level: X-Spam-Status: No, score=-106.271 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsMs0mkU0JJV for ; Mon, 4 Nov 2013 18:20:45 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9006F21E8356 for ; Mon, 4 Nov 2013 18:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383618064; x=1698961950; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=oKRDAcxqR9r7vRz64m9Zs2w4nRiHTE1fur4A2ZepuSY=; b=dBljASZKYjBvCBDL60oFljmGT0icm92qU21ynHUe9vnfwaDsJA9tTgyF3cfj5K PPRWD9s7q9YOWy0uDz6hdnnQ== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.28195616; Mon, 04 Nov 2013 21:21:03 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 4 Nov 2013 21:20:28 -0500 From: "Peterson, Jon" To: 'Richard Shockey' , 'Andrew Allen' , "'stir@ietf.org'" Thread-Topic: [stir] comments on draft-ietf-stir-problem-statement-00 Thread-Index: Ac7QUSi+XuSwVM/UQPSEhXox+oZw/gJFOdUAABAW9ID//+tngIAAp9QAgABE4kc= Date: Tue, 5 Nov 2013 02:20:28 +0000 Message-ID: <596979554D802045BBD45C051A4399E40D40A87A@STNTEXMB10.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.15.96] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: HSgJhGKGleO4fHps/cWYcQ== Content-Type: multipart/alternative; boundary="_000_596979554D802045BBD45C051A4399E40D40A87ASTNTEXMB10cisne_" MIME-Version: 1.0 Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:20:49 -0000 --_000_596979554D802045BBD45C051A4399E40D40A87ASTNTEXMB10cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbC4gTWF5YmUgSSB1bmRlcnN0b29kIEFuZHJldydzIG1lc3NhZ2UgYSBiaXQgZGlmZmVyZW50 bHkgdGhhbiB5b3UgZGlkLiBXaGF0IGhlIG9yaWdpbmFsbHkgYXNrZWQgd2FzIHRoYXQgc2Vydmlj ZXMgbGlrZSBCbGFja2JlcnJ5IE1lc3NlbmdlciAoYWxzbyBhbiBvdXQtb2YtYmFuZCBzZXJ2aWNl IGxpa2UgaU1lc3NhZ2UpIGJlIGluY2x1ZGVkIHNvIHdlIGRvbid0IGFwcGVhciB0byBiZSBmYXZv cmluZyB0aGUgd29yayBvZiBhIHNpbmdsZSBtb25vbGl0aGljIHZlbmRvci4gSGUgdGhlbiBhc2tl ZCB0aGF0IHdlIHJlZmVyZW5jZSBzb21ldGhpbmcgbGlrZSBXaGF0c2FwcCwgYSBwbGF0Zm9ybS1u ZXV0cmFsIHNlcnZpY2UgYWxvbmcgdGhlc2UgbGluZXMuIEkgaGF2ZW4ndCBvYmplY3RlZCB0byBl aXRoZXIgb2YgdGhvc2UgcmVxdWVzdHMuIEJ1dCB0aGUgc3VnZ2VzdGlvbiB0aGF0IHdlIHJlc3Ry aWN0IHRoaXMgc2VjdGlvbiB0byBzb21lIG90aGVyIHZlbmRvcidzIHNvbHV0aW9uIHdoaWxlIHJl bW92aW5nIHRoZSBvbmUgd2l0aCB3aGljaCBwZW9wbGUgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhl IHByb2JsZW0gYXJlIG1vc3QgZmFtaWxpYXIgd291bGQsIEkgdGhpbmssIGJlIGEgZGlmZmVyZW50 IG1hdHRlci4NCg0KVGhlIG9iamVjdGl2ZSBvZiB0aGlzIGRvY3VtZW50IGlzIG5vdCB0byBwcm9t b3RlIGFueSBzb2x1dGlvbiwgaXQncyBhIHByb2JsZW0gc3RhdGVtZW50IGRvY3VtZW50LiBXaGF0 ZXZlciB3ZSByZWZlcmVuY2UgaGVyZSBpcyBlbnRpcmVseSBleGVtcGxhcnkgYW5kIGV4cGxpY2l0 bHkgbm90IGEgY29tcG9uZW50IG9mIHRoZSBTVElSIHNvbHV0aW9uLiBXaGlsZSB3ZSBjYW4gYWxs IHNlZSB0aGUgdmVoZW1lbmNlIG9mIHlvdXIgcGVyc29uYWwgb2JqZWN0aW9uLCBJIGFtIG5vdCBz ZWVpbmcgYW55IHJhdGlvbmFsIHJlYXNvbiBoZXJlIHRvIHN0cmlrZSBpbmZvcm1hdGlvbiBmcm9t IHRoZSBkb2N1bWVudCB0aGF0IGFjdHVhbGx5IGhlbHBzIHBlb3BsZSB0byB1bmRlcnN0YW5kIHdo YXQgdGhpcyB3b3JrIGlzIGFib3V0LiBOb3IgZG8gSSB0aGluayB5b3VyIGN1cmlvdXMgY29uc3Ry dWFsIG9mIEFuZHJldydzIChhY3R1YWxseSBxdWl0ZSByZWFzb25hYmxlKSByZXF1ZXN0LCB3aGVu IGNvbWJpbmVkIHdpdGggeW91ciBvd24gbW9yZSBvYnNjdXJlIGNvbXBsYWludCwganVzdGlmaWVz IGlzc3VpbmcgYmxhbmtldCBjb21tYW5kcyBhcyB5b3UgZG8gYmVsb3cuIFdoeSBkb24ndCB3ZSBs ZWF2ZSBpdCB0byB0aGUgY2hhaXJzIHRvIGFzc2VzcyBjb25zZW5zdXMuDQoNCkpvbiBQZXRlcnNv bg0KTmV1c3RhciwgSW5jLg0KDQoNCg0KU2VudCB3aXRoIEdvb2QgKHd3dy5nb29kLmNvbSkNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmljaGFyZCBTaG9ja2V5IFtyaWNo YXJkQHNob2NrZXkudXM8bWFpbHRvOnJpY2hhcmRAc2hvY2tleS51cz5dDQpTZW50OiBNb25kYXks IE5vdmVtYmVyIDA0LCAyMDEzIDA4OjI3IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IFBl dGVyc29uLCBKb247ICdBbmRyZXcgQWxsZW4nOyBzdGlyQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W3N0aXJdIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc3Rpci1wcm9ibGVtLXN0YXRlbWVudC0wMA0K DQpKb24gLi4gd2hhdCBhYm91dCBOTyBkb27igJl0IHlvdSB1bmRlcnN0YW5kLg0KDQpXZSBvYmpl Y3QgdG8gdGhlIHJlZmVyZW5jZXMuIFJlbW92ZSB0aGVtIG5vdy4NCg0KRnJvbTogc3Rpci1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg UGV0ZXJzb24sIEpvbg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwNCwgMjAxMyA2OjI2IFBNDQpU bzogQW5kcmV3IEFsbGVuOyBzdGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3N0aXJdIGNvbW1l bnRzIG9uIGRyYWZ0LWlldGYtc3Rpci1wcm9ibGVtLXN0YXRlbWVudC0wMA0KDQo8QUE+SSBkb27i gJl0IHRoaW5rIGp1c3QgdGhlIGZhY3QgdGhhdCBzb21lIHBlb3BsZSBoYXBwZW4gdG8gYmUgZmFt aWxpYXIgd2l0aCBpTWVzc2FnZSBpcyBzdWZmaWNpZW50IGp1c3RpZmljYXRpb24gdG8gbWFrZSBp dCBhIGdvb2QgZXhhbXBsZSB0byB1c2UgaW4gdGhlIGRyYWZ0IOKAkyBwYXJ0aWN1bGFybHkgc2lu Y2UgaXQgaGFzIHNob3J0IGNvbWluZ3Mgc3VjaCBhcyBiZWluZyBjdXJyZW50bHkgcmVzdHJpY3Rl ZCB0byBhIHNpbmdsZSBwbGF0Zm9ybS4gSSBiZWxpZXZlIFdoYXRzYXBwIGhhcyB0aGUgbW9zdCB1 c2Vy4oCZcyBhbmQgYWxzbyBoYXMgbXVsdGkgdmVuZG9yIHN1cHBvcnQuIEkgc3VwcG9zZSBhIGxp c3Qgb2YgZS5n4oCZcyBpcyBPSyBidXQgSSBkb27igJl0IHNlZSB3aHkgd2UgbmVlZCB0byBkZXNj cmliZSBpbiBhbnkgZGV0YWlsIGEgc3BlY2lmaWMgc2VydmljZSDigJMgc2luY2UgbW9zdCBvZiB0 aGVtIGhhdmUgc2ltaWxhciBjaGFyYWN0ZXJpc3RpY3MuPC9BQT4NCg0KSSB0aGluayB0aGUgZmFj dCB0aGF0IHBlb3BsZSBhcmUgZmFtaWxpYXIgd2l0aCBpTWVzc2FnZSBpcyBhIHZlcnkgZ29vZCBy ZWFzb24gdG8gbGlzdCBpdCBhcyBvbmUgZXhhbXBsZS4gSSdtIGhhcHB5IHRvIGluY2x1ZGUgb3Ro ZXIgZXhhbXBsZXMsIGluY2x1ZGluZyBXaGF0c2FwcC4gSSB3b3VsZCBhbHNvIGJlIGhhcHB5IHRv IG1ha2UgdGhlIGRlc2NyaXB0aXZlIHRleHQgdGhlcmUgbGVzcyBzcGVjaWZpYyB0byBhbnkgcGFy dGljdWxhciB2ZW5kb3IsIGJ1dCBJIGRvIGhhdmUgYSBoYXJkIHRpbWUgc2VlaW5nIGhvdyBsaXN0 aW5nIGlNZXNzYWdlIGhlcmUgd291bGQgbWFrZSBwZW9wbGUgbWlzdW5kZXJzdGFuZCB0aGUgcHJv YmxlbSBzdGF0ZW1lbnQuDQoNCltBQV0gTXkgcHJvYmxlbSBpcyB3aXRoIHRoZSBzdGF0ZW1lbnQg 4oCcZG9tYWlucyB0aGF0IGhhdmUgbm8gcmVsYXRpb25zaGlwIHdpdGggdGhlIG51bWJlciBhc3Np Z25lZeKAnSBDZXJ0YWlubHkgdGhleSBoYXZlIGEgcmVsYXRpb25zaGlwIOKAkyBpbiBmYWN0IGEg Y2xvc2UgYW5kIHRydXN0ZWQgb25lIGFuZCB0aGUgaG9tZSBkb21haW4gcHJvdmlkZXMgdGhlIG51 bWJlciB0byBhc3NlcnQgdG8gdGhlIHJvYW1lZCB0byBkb21haW4uICBTbyBJIHRoaW5rIGl0IG5l ZWRzIHRvIGJlIG1hZGUgY2xlYXJlci4NCg0KDQoNCg0KT2theSwgcGVyIHRoZSB0ZXh0IEkgc2Vu dCBpbiBteSBsYXN0IG1haWwsIHdlIGNhbiBtYWtlIHRoaXMgY2xlYXJlci4gQWdhaW4sIHdoYXQg dGhpcyBtZWFucyBmb3IgU1RJUiBpcyB0aGF0IHRoZSB0aGUgcm9hbWluZyBjYXJyaWVyIHdvbid0 IGhhdmUgdGhlIGF1dGhvcml0eSBvdmVyIHRoZSBudW1iZXIuDQoNCkpvbiBQZXRlcnNvbg0KTmV1 c3RhciwgSW5jLg0KDQo= --_000_596979554D802045BBD45C051A4399E40D40A87ASTNTEXMB10cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQo8aHRtbD4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iZ2VuZXJhdG9y IiBjb250ZW50PSJIVE1MIFRpZHkgZm9yIFdpbmRvd3MgKHZlcnMgMjUgTWFyY2ggMjAwOSksIHNl ZSB3d3cudzMub3JnIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0 IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwh LS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCiAgICAgICAge2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KICAgICAgICBwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCiAgICAgICAge2ZvbnQtZmFtaWx5OkNhbGlicmk7DQogICAgICAgIHBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQogICAgICAgIHttYXJnaW46 MGluOw0KICAgICAgICBtYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQogICAgICAgIGZvbnQtc2l6ZTox MS4wcHQ7DQogICAgICAgIGZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KICAgICAgICB7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K ICAgICAgICBjb2xvcjpibHVlOw0KICAgICAgICB0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KICAgICAgICB7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KICAgICAgICBjb2xvcjpwdXJwbGU7DQogICAgICAgIHRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQogICAgICAgIHttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQog ICAgICAgIG1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCiAgICAgICAg bWFyZ2luOjBpbjsNCiAgICAgICAgbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KICAgICAgICBmb250 LXNpemU6MTAuMHB0Ow0KICAgICAgICBmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCiAgICAgICAge21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCiAgICAgICAgbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KICAgICAgICBt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KICAgICAgICBmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQogICAgICAgIHttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCiAgICAgICAgZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN CiAgICAgICAgY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KICAgICAgICB7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQogICAgICAgIGZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQogICAgICAgIGNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN CiAgICAgICAge21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KICAgICAgICBmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KICAgICAgICBjb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQogICAgICAgIHttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCiAgICAg ICAgZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCiAgICAgICAge3NpemU6 OC41aW4gMTEuMGluOw0KICAgICAgICBtYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KICAgICAgICB7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+DQo8L3N0 eWxlPg0KPHRpdGxlPjwvdGl0bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCldlbGwuIE1heWJlIEkgdW5k ZXJzdG9vZCBBbmRyZXcncyBtZXNzYWdlIGEgYml0IGRpZmZlcmVudGx5IHRoYW4geW91IGRpZC4g V2hhdCBoZSBvcmlnaW5hbGx5IGFza2VkIHdhcyB0aGF0IHNlcnZpY2VzIGxpa2UgQmxhY2tiZXJy eSBNZXNzZW5nZXIgKGFsc28gYW4gb3V0LW9mLWJhbmQgc2VydmljZSBsaWtlIGlNZXNzYWdlKSBi ZSBpbmNsdWRlZCBzbyB3ZSBkb24ndCBhcHBlYXIgdG8gYmUgZmF2b3JpbmcgdGhlIHdvcmsgb2Yg YSBzaW5nbGUgbW9ub2xpdGhpYw0KIHZlbmRvci4gSGUgdGhlbiBhc2tlZCB0aGF0IHdlIHJlZmVy ZW5jZSBzb21ldGhpbmcgbGlrZSBXaGF0c2FwcCwgYSBwbGF0Zm9ybS1uZXV0cmFsIHNlcnZpY2Ug YWxvbmcgdGhlc2UgbGluZXMuIEkgaGF2ZW4ndCBvYmplY3RlZCB0byBlaXRoZXIgb2YgdGhvc2Ug cmVxdWVzdHMuIEJ1dCB0aGUgc3VnZ2VzdGlvbiB0aGF0IHdlIHJlc3RyaWN0IHRoaXMgc2VjdGlv biB0byBzb21lIG90aGVyIHZlbmRvcidzIHNvbHV0aW9uIHdoaWxlIHJlbW92aW5nIHRoZQ0KIG9u ZSB3aXRoIHdoaWNoIHBlb3BsZSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSBhcmUg bW9zdCBmYW1pbGlhciB3b3VsZCwgSSB0aGluaywgYmUgYSBkaWZmZXJlbnQgbWF0dGVyLjxicj4N Cjxicj4NClRoZSBvYmplY3RpdmUgb2YgdGhpcyBkb2N1bWVudCBpcyBub3QgdG8gcHJvbW90ZSBh bnkgc29sdXRpb24sIGl0J3MgYSBwcm9ibGVtIHN0YXRlbWVudCBkb2N1bWVudC4gV2hhdGV2ZXIg d2UgcmVmZXJlbmNlIGhlcmUgaXMgZW50aXJlbHkgZXhlbXBsYXJ5IGFuZCBleHBsaWNpdGx5IG5v dCBhIGNvbXBvbmVudCBvZiB0aGUgU1RJUiBzb2x1dGlvbi4gV2hpbGUgd2UgY2FuIGFsbCBzZWUg dGhlIHZlaGVtZW5jZSBvZiB5b3VyIHBlcnNvbmFsIG9iamVjdGlvbiwNCiBJIGFtIG5vdCBzZWVp bmcgYW55IHJhdGlvbmFsIHJlYXNvbiBoZXJlIHRvIHN0cmlrZSBpbmZvcm1hdGlvbiBmcm9tIHRo ZSBkb2N1bWVudCB0aGF0IGFjdHVhbGx5IGhlbHBzIHBlb3BsZSB0byB1bmRlcnN0YW5kIHdoYXQg dGhpcyB3b3JrIGlzIGFib3V0LiBOb3IgZG8gSSB0aGluayB5b3VyIGN1cmlvdXMgY29uc3RydWFs IG9mIEFuZHJldydzIChhY3R1YWxseSBxdWl0ZSByZWFzb25hYmxlKSByZXF1ZXN0LCB3aGVuIGNv bWJpbmVkIHdpdGggeW91cg0KIG93biBtb3JlIG9ic2N1cmUgY29tcGxhaW50LCBqdXN0aWZpZXMg aXNzdWluZyBibGFua2V0IGNvbW1hbmRzIGFzIHlvdSBkbyBiZWxvdy4gV2h5IGRvbid0IHdlIGxl YXZlIGl0IHRvIHRoZSBjaGFpcnMgdG8gYXNzZXNzIGNvbnNlbnN1cy48YnI+DQo8YnI+DQpKb24g UGV0ZXJzb248YnI+DQpOZXVzdGFyLCBJbmMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KU2VudCB3 aXRoIEdvb2QgKHd3dy5nb29kLmNvbSk8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCjxiPkZyb206Jm5ic3A7PC9iPlJpY2hhcmQgU2hvY2tleSBbPGEgaHJl Zj0ibWFpbHRvOnJpY2hhcmRAc2hvY2tleS51cyI+cmljaGFyZEBzaG9ja2V5LnVzPC9hPl08YnI+ DQo8Yj5TZW50OiZuYnNwOzwvYj5Nb25kYXksIE5vdmVtYmVyIDA0LCAyMDEzIDA4OjI3IFBNIEVh c3Rlcm4gU3RhbmRhcmQgVGltZTxicj4NCjxiPlRvOiZuYnNwOzwvYj5QZXRlcnNvbiwgSm9uOyAn QW5kcmV3IEFsbGVuJzsgc3RpckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6Jm5ic3A7PC9iPlJF OiBbc3Rpcl0gY29tbWVudHMgb24gZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50LTAw PGJyPg0KPGJyPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Sm9uIC4uIHdoYXQgYWJvdXQgTk8gZG9u4oCZdCB5b3Ug dW5kZXJzdGFuZC4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2Ugb2JqZWN0IHRvIHRoZSByZWZlcmVu Y2VzLiBSZW1vdmUgdGhlbSBub3cuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBz dGlyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2Y8L2I+IFBldGVyc29uLCBKb248YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBO b3ZlbWJlciAwNCwgMjAxMyA2OjI2IFBNPGJyPg0KPGI+VG86PC9iPiBBbmRyZXcgQWxsZW47IHN0 aXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzdGlyXSBjb21tZW50cyBvbiBk cmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDA8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7QUEmZ3Q7SSBkb27igJl0IHRoaW5r IGp1c3QgdGhlIGZhY3QgdGhhdCBzb21lIHBlb3BsZSBoYXBwZW4gdG8gYmUgZmFtaWxpYXIgd2l0 aCBpTWVzc2FnZSBpcyBzdWZmaWNpZW50IGp1c3RpZmljYXRpb24gdG8gbWFrZSBpdCBhIGdvb2Qg ZXhhbXBsZSB0byB1c2UgaW4gdGhlIGRyYWZ0IOKAkyBwYXJ0aWN1bGFybHkgc2luY2UgaXQgaGFz IHNob3J0IGNvbWluZ3Mgc3VjaCBhcw0KIGJlaW5nIGN1cnJlbnRseSByZXN0cmljdGVkIHRvIGEg c2luZ2xlIHBsYXRmb3JtLiBJIGJlbGlldmUgV2hhdHNhcHAgaGFzIHRoZSBtb3N0IHVzZXLigJlz IGFuZCBhbHNvIGhhcyBtdWx0aSB2ZW5kb3Igc3VwcG9ydC4gSSBzdXBwb3NlIGEgbGlzdCBvZiBl LmfigJlzIGlzIE9LIGJ1dCBJIGRvbuKAmXQgc2VlIHdoeSB3ZSBuZWVkIHRvIGRlc2NyaWJlIGlu IGFueSBkZXRhaWwgYSBzcGVjaWZpYyBzZXJ2aWNlIOKAkyBzaW5jZSBtb3N0IG9mIHRoZW0gaGF2 ZSBzaW1pbGFyDQogY2hhcmFjdGVyaXN0aWNzLiZsdDsvQUEmZ3Q7PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5JIHRoaW5rIHRoZSBmYWN0IHRoYXQgcGVvcGxlIGFyZSBmYW1pbGlhciB3 aXRoIGlNZXNzYWdlIGlzIGEgdmVyeSBnb29kIHJlYXNvbiB0byBsaXN0IGl0IGFzIG9uZSBleGFt cGxlLiBJJ20gaGFwcHkgdG8gaW5jbHVkZSBvdGhlciBleGFtcGxlcywgaW5jbHVkaW5nDQogV2hh dHNhcHAuIEkgd291bGQgYWxzbyBiZSBoYXBweSB0byBtYWtlIHRoZSBkZXNjcmlwdGl2ZSB0ZXh0 IHRoZXJlIGxlc3Mgc3BlY2lmaWMgdG8gYW55IHBhcnRpY3VsYXIgdmVuZG9yLCBidXQgSSBkbyBo YXZlIGEgaGFyZCB0aW1lIHNlZWluZyBob3cgbGlzdGluZyBpTWVzc2FnZSBoZXJlIHdvdWxkIG1h a2UgcGVvcGxlIG1pc3VuZGVyc3RhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50Ljwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bQUFdIE15IHByb2JsZW0gaXMg d2l0aCB0aGUgc3RhdGVtZW50IOKAnDwvc3Bhbj48aT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PmRvbWFpbnMgdGhhdCBoYXZlIG5vIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBudW1iZXIgYXNzaWdu ZWXigJ08L3NwYW4+PC9pPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNlcnRhaW5seSB0 aGV5IGhhdmUgYSByZWxhdGlvbnNoaXAg4oCTIGluIGZhY3QgYSBjbG9zZSBhbmQgdHJ1c3RlZCBv bmUgYW5kIHRoZSBob21lIGRvbWFpbiBwcm92aWRlcyB0aGUgbnVtYmVyIHRvIGFzc2VydCB0byB0 aGUgcm9hbWVkIHRvIGRvbWFpbi4gJm5ic3A7U28gSSB0aGluayBpdCBuZWVkcyB0byBiZSBtYWRl IGNsZWFyZXIuPC9zcGFuPjwvcD4NCjxwcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiA8L3NwYW4+DQo8L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Pa2F5LCBw ZXIgdGhlIHRleHQgSSBzZW50IGluIG15IGxhc3QgbWFpbCwgd2UgY2FuIG1ha2UgdGhpcyBjbGVh cmVyLiBBZ2Fpbiwgd2hhdCB0aGlzIG1lYW5zIGZvciBTVElSIGlzIHRoYXQgdGhlIHRoZSByb2Ft aW5nIGNhcnJpZXIgd29uJ3QgaGF2ZSB0aGUgYXV0aG9yaXR5IG92ZXIgdGhlIG51bWJlci4mbmJz cDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Sm9uIFBldGVyc29uPC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5OZXVzdGFyLCBJbmMuPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_596979554D802045BBD45C051A4399E40D40A87ASTNTEXMB10cisne_-- From md3135@att.com Mon Nov 4 18:26:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12AF21E836B for ; Mon, 4 Nov 2013 18:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9k5Jd0Wu00V for ; Mon, 4 Nov 2013 18:26:52 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 13D0E21E8118 for ; Mon, 4 Nov 2013 18:26:50 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b6758725.7972e940.195671.00-549.551912.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 05 Nov 2013 02:26:51 +0000 (UTC) X-MXL-Hash: 5278576b5fbc0d00-db2882919c73a6b58a8fb2482329f1a6382b1a00 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 63758725.0.195431.00-331.551255.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 05 Nov 2013 02:26:50 +0000 (UTC) X-MXL-Hash: 5278576a48f99797-8a4750f93323adc4c286bca70b2e92ab96c52857 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 rA52PwxX018972; Mon, 4 Nov 2013 21:25:58 -0500 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 rA52PjhR018909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 21:25:46 -0500 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 5 Nov 2013 02:25:31 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.0158.001; Mon, 4 Nov 2013 21:25:31 -0500 From: "DOLLY, MARTIN C" To: "Cullen Jennings (fluffy)" , Richard Shockey Thread-Topic: [stir] draft-ietf-stir-problem-statement: Privacy requirements Thread-Index: AQHO2P2fB4cu8GPskk2gP2GFZeAL75oVlWoAgAAMIACAADeoAIAABzwA///+x4CAAAoGAIAABdUAgAAhcoCAAD4PAP//m6PQ Date: Tue, 5 Nov 2013 02:25:30 +0000 Message-ID: References: <010501ced977$79754ff0$6c5fefd0$@shockey.us> <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531D0FDE6C378@BOBO1A.bobotek.net> <003301ced99b$52c9fad0$f85df070$@shockey.us> <011001ced9ae$f59395b0$e0bac110$@shockey.us> <5A55ABD0-A909-4061-AB5C-CE74EDD2B90F@cisco.com> In-Reply-To: <5A55ABD0-A909-4061-AB5C-CE74EDD2B90F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.87.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=FZmAMuC6 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=gXvi-65-3EUA:10 a=G1TQVBhzE9UA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=HnAMTTd2fvAA:10 a=48vgC7mUAAAA:8 a=aoH9WVoggqawBK] X-AnalysisOut: [Ij9qsA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=vRAbILRZcFs] X-AnalysisOut: [A:10] Cc: "" , Michael Procter , Alex Bobotek , "Peterson, Jon" Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:26:58 -0000 Cullen, Enabled or capable?=20 And percentage of deployments are we talking about? How about Cisco only? Regards, Martin -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Cul= len Jennings (fluffy) Sent: Monday, November 04, 2013 9:21 PM To: Richard Shockey Cc: ; Alex Bobotek; Michael Procter; Peterson, Jon Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements On Nov 4, 2013, at 2:41 PM, Richard Shockey wrote: > They say nothing they offer nothing and VIPR as I have pointed > out several times was a total and complete failure as an IETF protocol.=20 Richard, respectfully, I don't think you have any clue or basis of informat= ion to say that. A fairly significant percentage of enterprise phones are V= iPR enabled. I'd be willing to guess that I have a long list of IETF protoc= ols that get less use and a short list of protocols that get more. iMessage= which is very similar technology has even far broader deployment and impac= t.=20 That said, I agree with Michael's comment that it is important to learn fro= m the privacy issues in ViPR and make sure we get down requirements that tu= rned out to be a late surprise in ViPR.=20 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From fluffy@cisco.com Mon Nov 4 18:31:20 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B9F11E8350 for ; Mon, 4 Nov 2013 18:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqkPwsNmmXuf for ; Mon, 4 Nov 2013 18:31:15 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC6511E8269 for ; Mon, 4 Nov 2013 18:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1694; q=dns/txt; s=iport; t=1383618672; x=1384828272; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BI6cQXvy3MFdS8z1NspDrnMbMncW6/OWqVTqpXyjzjI=; b=HP9MLKjcnsqMr/jJ2ahwPoqmsWCp6ka3t1Zq92boFIor/xNi8U9qlTN0 wgr/vcctSLvuf+urK1yD5SQemkEyeRz6hjx/CZpmB3HYlVaB99WyapXF+ MolmggMJdJ5083PmyErw8GGRgaXoL5FFkyphLL7RuKj9mA3H2UijYUgeK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFABNXeFKtJV2c/2dsb2JhbABZgwc4U787gSgWdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBAR4JBycLFAkIAgQOBYd7Bg2+LgSPGDMHBoMagQ4Dk2mEIZIJgyaCKg X-IronPort-AV: E=Sophos;i="4.93,637,1378857600"; d="scan'208";a="280670398" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 05 Nov 2013 02:31:12 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA52VBGW008515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 02:31:12 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 20:31:11 -0600 From: "Cullen Jennings (fluffy)" To: "DOLLY, MARTIN C" Thread-Topic: [stir] draft-ietf-stir-problem-statement: Privacy requirements Thread-Index: AQHO2P2fB4cu8GPskk2gP2GFZeAL75oVlWoAgAAMIACAADeoAIAABzwA///+x4CAAAoGAIAABdUAgAAhcoCAAD4PAP//m6PQgABnUoA= Date: Tue, 5 Nov 2013 02:31:11 +0000 Message-ID: <9BF6D01E-F614-40BA-AC2A-4671978DEFA5@cisco.com> References: <010501ced977$79754ff0$6c5fefd0$@shockey.us> <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531D0FDE6C378@BOBO1A.bobotek.net> <003301ced99b$52c9fad0$f85df070$@shockey.us> <011001ced9ae$f59395b0$e0bac110$@shockey.us> <5A55ABD0-A909-4061-AB5C-CE74EDD2B90F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.74.79] Content-Type: text/plain; charset="us-ascii" Content-ID: <795E908F0D4DC348B406B43047F094BE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Michael Procter , Alex Bobotek , "Peterson, Jon" , Richard Shockey Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:31:20 -0000 On Nov 4, 2013, at 6:25 PM, "DOLLY, MARTIN C" wrote: > Cullen, >=20 > Enabled or capable?=20 > And percentage of deployments are we talking about? How about Cisco only? I'm only know about Cisco numbers but I realize that other people have buil= d ViPR system too.=20 >=20 > Regards, >=20 > Martin >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of C= ullen Jennings (fluffy) > Sent: Monday, November 04, 2013 9:21 PM > To: Richard Shockey > Cc: ; Alex Bobotek; Michael Procter; Peterson, Jon > Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requiremen= ts >=20 >=20 > On Nov 4, 2013, at 2:41 PM, Richard Shockey wrote: >=20 >> They say nothing they offer nothing and VIPR as I have pointed >> out several times was a total and complete failure as an IETF protocol.= =20 >=20 > Richard, respectfully, I don't think you have any clue or basis of inform= ation to say that. A fairly significant percentage of enterprise phones are= ViPR enabled. I'd be willing to guess that I have a long list of IETF prot= ocols that get less use and a short list of protocols that get more. iMessa= ge which is very similar technology has even far broader deployment and imp= act.=20 >=20 > That said, I agree with Michael's comment that it is important to learn f= rom the privacy issues in ViPR and make sure we get down requirements that = turned out to be a late surprise in ViPR.=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From md3135@att.com Mon Nov 4 18:33:04 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A70D21E835C for ; Mon, 4 Nov 2013 18:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ErUaYXK3CYJ for ; Mon, 4 Nov 2013 18:32:58 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 24DEF21F9FB3 for ; Mon, 4 Nov 2013 18:32:57 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 9d858725.71521940.197438.00-590.556788.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 05 Nov 2013 02:32:57 +0000 (UTC) X-MXL-Hash: 527858d9705efe32-65a17c6c0e871ad544387ff44b10481116de563f Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 7d858725.0.197431.00-331.556761.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 05 Nov 2013 02:32:56 +0000 (UTC) X-MXL-Hash: 527858d86c86a029-90eb9651d76221418567d9d4e5b822a2bdaf28d4 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 rA52WspI025009; Mon, 4 Nov 2013 21:32:54 -0500 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 rA52Wj0e024964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 21:32:45 -0500 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 5 Nov 2013 02:32:30 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0158.001; Mon, 4 Nov 2013 21:32:30 -0500 From: "DOLLY, MARTIN C" To: "Cullen Jennings (fluffy)" Thread-Topic: [stir] draft-ietf-stir-problem-statement: Privacy requirements Thread-Index: AQHO2P2fB4cu8GPskk2gP2GFZeAL75oVlWoAgAAMIACAADeoAIAABzwA///+x4CAAAoGAIAABdUAgAAhcoCAAD4PAP//m6PQgABnUoD//5rxcA== Date: Tue, 5 Nov 2013 02:32:29 +0000 Message-ID: References: <010501ced977$79754ff0$6c5fefd0$@shockey.us> <4B1956260CD29F4A9622F00322FE0531D0FDE6C376@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531D0FDE6C378@BOBO1A.bobotek.net> <003301ced99b$52c9fad0$f85df070$@shockey.us> <011001ced9ae$f59395b0$e0bac110$@shockey.us> <5A55ABD0-A909-4061-AB5C-CE74EDD2B90F@cisco.com> <9BF6D01E-F614-40BA-AC2A-4671978DEFA5@cisco.com> In-Reply-To: <9BF6D01E-F614-40BA-AC2A-4671978DEFA5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.87.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=FZmAMuC6 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=gXvi-65-3EUA:10 a=G1TQVBhzE9UA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=HnAMTTd2fvAA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=kYUm4PWlV_h4b3Zrje0A:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=vRAbILRZcFsA:10] Cc: "" , Michael Procter , Alex Bobotek , "Peterson, Jon" , Richard Shockey Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:33:04 -0000 There is a lot of code that never is used... -----Original Message----- From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 Sent: Monday, November 04, 2013 9:31 PM To: DOLLY, MARTIN C Cc: Richard Shockey; ; Alex Bobotek; Michael Procter; Peters= on, Jon Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements On Nov 4, 2013, at 6:25 PM, "DOLLY, MARTIN C" wrote: > Cullen, >=20 > Enabled or capable?=20 > And percentage of deployments are we talking about? How about Cisco only? I'm only know about Cisco numbers but I realize that other people have buil= d ViPR system too.=20 >=20 > Regards, >=20 > Martin >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of C= ullen Jennings (fluffy) > Sent: Monday, November 04, 2013 9:21 PM > To: Richard Shockey > Cc: ; Alex Bobotek; Michael Procter; Peterson, Jon > Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requiremen= ts >=20 >=20 > On Nov 4, 2013, at 2:41 PM, Richard Shockey wrote: >=20 >> They say nothing they offer nothing and VIPR as I have pointed >> out several times was a total and complete failure as an IETF protocol.= =20 >=20 > Richard, respectfully, I don't think you have any clue or basis of inform= ation to say that. A fairly significant percentage of enterprise phones are= ViPR enabled. I'd be willing to guess that I have a long list of IETF prot= ocols that get less use and a short list of protocols that get more. iMessa= ge which is very similar technology has even far broader deployment and imp= act.=20 >=20 > That said, I agree with Michael's comment that it is important to learn f= rom the privacy issues in ViPR and make sure we get down requirements that = turned out to be a late surprise in ViPR.=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Mon Nov 4 18:42:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A940111E824D for ; Mon, 4 Nov 2013 18:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.288 X-Spam-Level: X-Spam-Status: No, score=-106.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xuGuWWVJP9m for ; Mon, 4 Nov 2013 18:42:20 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id DE94D21E818C for ; Mon, 4 Nov 2013 18:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383619308; x=1698961950; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=Dk/zushXZh36WhUFmV1uAkhAv/OfbUngkDfOO0bwGM0=; b=cxkBjvOLupGR7OUgSKf6eZ/V6KPWEYR4j6wSVz5Zh4aRlowO/iXBsZD1t7mA+I otHeiCndWwr7QBQhTxUjI1qw== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.28196248; Mon, 04 Nov 2013 21:41:47 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc10.cis.neustar.com ([169.254.4.132]) with mapi id 14.02.0342.003; Mon, 4 Nov 2013 21:41:11 -0500 From: "Peterson, Jon" To: "'DOLLY, MARTIN C'" , "'Cullen Jennings (fluffy)'" Thread-Topic: [stir] draft-ietf-stir-problem-statement: Privacy requirements Thread-Index: AQHO2P2hp4T+BWgdmkKNlkLkLQsoMZoU/oiAgACSPgCAADeoAIAABz0A///+xoCAAAoHAIAABdQAgAAhc4CAAD1QAIAAAV8AgAABloCAAABdgP//rpzd Date: Tue, 5 Nov 2013 02:41:10 +0000 Message-ID: <596979554D802045BBD45C051A4399E40D40A8F9@STNTEXMB10.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.15.96] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: wpkH6abM4v+KEIx/zRtKtQ== Content-Type: multipart/alternative; boundary="_000_596979554D802045BBD45C051A4399E40D40A8F9STNTEXMB10cisne_" MIME-Version: 1.0 Cc: "''" , 'Michael Procter' , 'Alex Bobotek' , 'Richard Shockey' Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:42:24 -0000 --_000_596979554D802045BBD45C051A4399E40D40A8F9STNTEXMB10cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIHJlYWxseSBub3Qgc3VyZSB3aGF0IHRoaXMgbGluZSBvZiByZWFzb25pbmcgaXMgaW50ZW5k ZWQgdG8gZXN0YWJsaXNoLiBOb2JvZHkgaXMgcHJvcG9zaW5nIFZJUFIgaXMgdGhlIHNvbHV0aW9u IGhlcmUuIFdlIGFyZSBvbmx5IHNheWluZyB0aGF0IGl0IGV4aXN0cywgYW5kIHRoYXQgaXQgY29u dGFpbnMgc29tZSBnb29kIGlkZWFzIGFuZCBiYWQgaWRlYXMuIEluIGZhY3QsIHRoaXMgdGhyZWFk IHN0YXJ0ZWQgYmVjYXVzZSBzb21lb25lIGFza2VkIHRoYXQgd2UgZXhwbGljaXRseSBsZWFybiBm cm9tIFZJUFJzIG1pc3Rha2VzIGFuZCBhdm9pZCBpdHMgcHJpdmFjeSBmYWlsaW5ncywgd2hpY2gg d2UgY2FuIG9ubHkgZG8gaWYgd2UgaW5jbHVkZSBWSVBSIGluIG91ciBjb25zaWRlcmF0aW9ucy4g VGhlIG1hZ25pdHVkZSBvZiBWSVBSIGRlcGxveW1lbnRzIGlzIG5vdCBzYWxpZW50IHRvIGFueSBw b2ludCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQgaXMgbWFraW5nLg0KDQpKb24gUGV0ZXJz b24NCk5ldXN0YXIsIEluYy4NCg0KDQoNClNlbnQgd2l0aCBHb29kICh3d3cuZ29vZC5jb20pDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERPTExZLCBNQVJUSU4gQyBbbWQz MTM1QGF0dC5jb208bWFpbHRvOm1kMzEzNUBhdHQuY29tPl0NClNlbnQ6IE1vbmRheSwgTm92ZW1i ZXIgMDQsIDIwMTMgMDk6MzMgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzogQ3VsbGVuIEpl bm5pbmdzIChmbHVmZnkpDQpDYzogUmljaGFyZCBTaG9ja2V5OyA7IEFsZXggQm9ib3RlazsgTWlj aGFlbCBQcm9jdGVyOyBQZXRlcnNvbiwgSm9uDQpTdWJqZWN0OiBSRTogW3N0aXJdIGRyYWZ0LWll dGYtc3Rpci1wcm9ibGVtLXN0YXRlbWVudDogUHJpdmFjeSByZXF1aXJlbWVudHMNCg0KDQpUaGVy ZSBpcyBhIGxvdCBvZiBjb2RlIHRoYXQgbmV2ZXIgaXMgdXNlZC4uLg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpIFttYWlsdG86Zmx1 ZmZ5QGNpc2NvLmNvbV0NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDQsIDIwMTMgOTozMSBQTQ0K VG86IERPTExZLCBNQVJUSU4gQw0KQ2M6IFJpY2hhcmQgU2hvY2tleTsgPHN0aXJAaWV0Zi5vcmc+ OyBBbGV4IEJvYm90ZWs7IE1pY2hhZWwgUHJvY3RlcjsgUGV0ZXJzb24sIEpvbg0KU3ViamVjdDog UmU6IFtzdGlyXSBkcmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQ6IFByaXZhY3kgcmVx dWlyZW1lbnRzDQoNCg0KT24gTm92IDQsIDIwMTMsIGF0IDY6MjUgUE0sICJET0xMWSwgTUFSVElO IEMiIDxtZDMxMzVAYXR0LmNvbT4NCiB3cm90ZToNCg0KPiBDdWxsZW4sDQo+DQo+IEVuYWJsZWQg b3IgY2FwYWJsZT8NCj4gQW5kIHBlcmNlbnRhZ2Ugb2YgZGVwbG95bWVudHMgYXJlIHdlIHRhbGtp bmcgYWJvdXQ/IEhvdyBhYm91dCBDaXNjbyBvbmx5Pw0KDQpJJ20gb25seSBrbm93IGFib3V0IENp c2NvIG51bWJlcnMgYnV0IEkgcmVhbGl6ZSB0aGF0IG90aGVyIHBlb3BsZSBoYXZlIGJ1aWxkIFZp UFIgc3lzdGVtIHRvby4NCg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBNYXJ0aW4NCj4NCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc3Rpci1ib3VuY2VzQGlldGYub3JnIFttYWls dG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ3VsbGVuIEplbm5pbmdzIChm bHVmZnkpDQo+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDQsIDIwMTMgOToyMSBQTQ0KPiBUbzog UmljaGFyZCBTaG9ja2V5DQo+IENjOiA8c3RpckBpZXRmLm9yZz47IEFsZXggQm9ib3RlazsgTWlj aGFlbCBQcm9jdGVyOyBQZXRlcnNvbiwgSm9uDQo+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gZHJhZnQt aWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50OiBQcml2YWN5IHJlcXVpcmVtZW50cw0KPg0KPg0K PiBPbiBOb3YgNCwgMjAxMywgYXQgMjo0MSBQTSwgUmljaGFyZCBTaG9ja2V5IDxyaWNoYXJkQHNo b2NrZXkudXM+IHdyb3RlOg0KPg0KPj4gVGhleSBzYXkgbm90aGluZyB0aGV5IG9mZmVyIG5vdGhp bmcgYW5kIFZJUFIgYXMgSSBoYXZlIHBvaW50ZWQNCj4+IG91dCBzZXZlcmFsIHRpbWVzIHdhcyBh IHRvdGFsIGFuZCBjb21wbGV0ZSBmYWlsdXJlIGFzIGFuIElFVEYgcHJvdG9jb2wuDQo+DQo+IFJp Y2hhcmQsIHJlc3BlY3RmdWxseSwgSSBkb24ndCB0aGluayB5b3UgaGF2ZSBhbnkgY2x1ZSBvciBi YXNpcyBvZiBpbmZvcm1hdGlvbiB0byBzYXkgdGhhdC4gQSBmYWlybHkgc2lnbmlmaWNhbnQgcGVy Y2VudGFnZSBvZiBlbnRlcnByaXNlIHBob25lcyBhcmUgVmlQUiBlbmFibGVkLiBJJ2QgYmUgd2ls bGluZyB0byBndWVzcyB0aGF0IEkgaGF2ZSBhIGxvbmcgbGlzdCBvZiBJRVRGIHByb3RvY29scyB0 aGF0IGdldCBsZXNzIHVzZSBhbmQgYSBzaG9ydCBsaXN0IG9mIHByb3RvY29scyB0aGF0IGdldCBt b3JlLiBpTWVzc2FnZSB3aGljaCBpcyB2ZXJ5IHNpbWlsYXIgdGVjaG5vbG9neSBoYXMgZXZlbiBm YXIgYnJvYWRlciBkZXBsb3ltZW50IGFuZCBpbXBhY3QuDQo+DQo+IFRoYXQgc2FpZCwgSSBhZ3Jl ZSB3aXRoIE1pY2hhZWwncyBjb21tZW50IHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIGxlYXJuIGZy b20gdGhlIHByaXZhY3kgaXNzdWVzIGluIFZpUFIgYW5kIG1ha2Ugc3VyZSB3ZSBnZXQgZG93biBy ZXF1aXJlbWVudHMgdGhhdCB0dXJuZWQgb3V0IHRvIGJlIGEgbGF0ZSBzdXJwcmlzZSBpbiBWaVBS Lg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBzdGlyIG1haWxpbmcgbGlzdA0KPiBzdGlyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KDQo= --_000_596979554D802045BBD45C051A4399E40D40A8F9STNTEXMB10cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRN TCBUaWR5IGZvciBXaW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDE0LjAyLjAzNDIuMDAxIj4NCjx0aXRsZT5SRTogW3N0aXJdIGRyYWZ0LWlldGYtc3Rpci1w cm9ibGVtLXN0YXRlbWVudDogUHJpdmFjeSByZXF1aXJlbWVudHM8L3RpdGxlPg0KPC9oZWFkPg0K PGJvZHk+DQpJJ20gcmVhbGx5IG5vdCBzdXJlIHdoYXQgdGhpcyBsaW5lIG9mIHJlYXNvbmluZyBp cyBpbnRlbmRlZCB0byBlc3RhYmxpc2guIE5vYm9keSBpcyBwcm9wb3NpbmcgVklQUiBpcyB0aGUg c29sdXRpb24gaGVyZS4gV2UgYXJlIG9ubHkgc2F5aW5nIHRoYXQgaXQgZXhpc3RzLCBhbmQgdGhh dCBpdCBjb250YWlucyBzb21lIGdvb2QgaWRlYXMgYW5kIGJhZCBpZGVhcy4gSW4gZmFjdCwgdGhp cyB0aHJlYWQgc3RhcnRlZCBiZWNhdXNlIHNvbWVvbmUgYXNrZWQNCiB0aGF0IHdlIGV4cGxpY2l0 bHkgbGVhcm4gZnJvbSBWSVBScyBtaXN0YWtlcyBhbmQgYXZvaWQgaXRzIHByaXZhY3kgZmFpbGlu Z3MsIHdoaWNoIHdlIGNhbiBvbmx5IGRvIGlmIHdlIGluY2x1ZGUgVklQUiBpbiBvdXIgY29uc2lk ZXJhdGlvbnMuIFRoZSBtYWduaXR1ZGUgb2YgVklQUiBkZXBsb3ltZW50cyBpcyBub3Qgc2FsaWVu dCB0byBhbnkgcG9pbnQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0IGlzIG1ha2luZy48YnI+ DQo8YnI+DQpKb24gUGV0ZXJzb248YnI+DQpOZXVzdGFyLCBJbmMuPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KU2VudCB3aXRoIEdvb2QgKHd3dy5nb29kLmNvbSk8YnI+DQo8YnI+DQo8YnI+DQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCjxiPkZyb206Jm5ic3A7PC9iPkRPTExZLCBNQVJU SU4gQyBbPGEgaHJlZj0ibWFpbHRvOm1kMzEzNUBhdHQuY29tIj5tZDMxMzVAYXR0LmNvbTwvYT5d PGJyPg0KPGI+U2VudDombmJzcDs8L2I+TW9uZGF5LCBOb3ZlbWJlciAwNCwgMjAxMyAwOTozMyBQ TSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWU8YnI+DQo8Yj5UbzombmJzcDs8L2I+Q3VsbGVuIEplbm5p bmdzIChmbHVmZnkpPGJyPg0KPGI+Q2M6Jm5ic3A7PC9iPlJpY2hhcmQgU2hvY2tleTsgOyBBbGV4 IEJvYm90ZWs7IE1pY2hhZWwgUHJvY3RlcjsgUGV0ZXJzb24sIEpvbjxicj4NCjxiPlN1YmplY3Q6 Jm5ic3A7PC9iPlJFOiBbc3Rpcl0gZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50OiBQ cml2YWN5IHJlcXVpcmVtZW50czxicj4NCjxicj4NCjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9w bGFpbiBmb3JtYXQgLS0+DQo8cD48Zm9udCBzaXplPSIyIj5UaGVyZSBpcyBhIGxvdCBvZiBjb2Rl IHRoYXQgbmV2ZXIgaXMgdXNlZC4uLjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KRnJvbTogQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpIFs8YSBocmVmPSJtYWlsdG86 Zmx1ZmZ5QGNpc2NvLmNvbSI+bWFpbHRvOmZsdWZmeUBjaXNjby5jb208L2E+XTxicj4NClNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMDQsIDIwMTMgOTozMSBQTTxicj4NClRvOiBET0xMWSwgTUFSVElO IEM8YnI+DQpDYzogUmljaGFyZCBTaG9ja2V5OyAmbHQ7c3RpckBpZXRmLm9yZyZndDs7IEFsZXgg Qm9ib3RlazsgTWljaGFlbCBQcm9jdGVyOyBQZXRlcnNvbiwgSm9uPGJyPg0KU3ViamVjdDogUmU6 IFtzdGlyXSBkcmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQ6IFByaXZhY3kgcmVxdWly ZW1lbnRzPGJyPg0KPGJyPg0KPGJyPg0KT24gTm92IDQsIDIwMTMsIGF0IDY6MjUgUE0sICZxdW90 O0RPTExZLCBNQVJUSU4gQyZxdW90OyAmbHQ7bWQzMTM1QGF0dC5jb20mZ3Q7PGJyPg0KJm5ic3A7 d3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBDdWxsZW4sPGJyPg0KJmd0Ozxicj4NCiZndDsgRW5hYmxl ZCBvciBjYXBhYmxlPzxicj4NCiZndDsgQW5kIHBlcmNlbnRhZ2Ugb2YgZGVwbG95bWVudHMgYXJl IHdlIHRhbGtpbmcgYWJvdXQ/IEhvdyBhYm91dCBDaXNjbyBvbmx5Pzxicj4NCjxicj4NCkknbSBv bmx5IGtub3cgYWJvdXQgQ2lzY28gbnVtYmVycyBidXQgSSByZWFsaXplIHRoYXQgb3RoZXIgcGVv cGxlIGhhdmUgYnVpbGQgVmlQUiBzeXN0ZW0gdG9vLjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7 IFJlZ2FyZHMsPGJyPg0KJmd0Ozxicj4NCiZndDsgTWFydGluPGJyPg0KJmd0Ozxicj4NCiZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IHN0aXItYm91bmNlc0Bp ZXRmLm9yZyBbPGEgaHJlZj0ibWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnN0 aXItYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBDdWxsZW4gSmVubmluZ3MgKGZs dWZmeSk8YnI+DQomZ3Q7IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDQsIDIwMTMgOToyMSBQTTxi cj4NCiZndDsgVG86IFJpY2hhcmQgU2hvY2tleTxicj4NCiZndDsgQ2M6ICZsdDtzdGlyQGlldGYu b3JnJmd0OzsgQWxleCBCb2JvdGVrOyBNaWNoYWVsIFByb2N0ZXI7IFBldGVyc29uLCBKb248YnI+ DQomZ3Q7IFN1YmplY3Q6IFJlOiBbc3Rpcl0gZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVt ZW50OiBQcml2YWN5IHJlcXVpcmVtZW50czxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBP biBOb3YgNCwgMjAxMywgYXQgMjo0MSBQTSwgUmljaGFyZCBTaG9ja2V5ICZsdDtyaWNoYXJkQHNo b2NrZXkudXMmZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBUaGV5IHNheSBub3Ro aW5nIHRoZXkgb2ZmZXIgbm90aGluZyBhbmQgVklQUiBhcyBJIGhhdmUgcG9pbnRlZDxicj4NCiZn dDsmZ3Q7IG91dCBzZXZlcmFsIHRpbWVzIHdhcyBhIHRvdGFsIGFuZCBjb21wbGV0ZSBmYWlsdXJl IGFzIGFuIElFVEYgcHJvdG9jb2wuPGJyPg0KJmd0Ozxicj4NCiZndDsgUmljaGFyZCwgcmVzcGVj dGZ1bGx5LCBJIGRvbid0IHRoaW5rIHlvdSBoYXZlIGFueSBjbHVlIG9yIGJhc2lzIG9mIGluZm9y bWF0aW9uIHRvIHNheSB0aGF0LiBBIGZhaXJseSBzaWduaWZpY2FudCBwZXJjZW50YWdlIG9mIGVu dGVycHJpc2UgcGhvbmVzIGFyZSBWaVBSIGVuYWJsZWQuIEknZCBiZSB3aWxsaW5nIHRvIGd1ZXNz IHRoYXQgSSBoYXZlIGEgbG9uZyBsaXN0IG9mIElFVEYgcHJvdG9jb2xzIHRoYXQgZ2V0IGxlc3Mg dXNlIGFuZCBhIHNob3J0DQogbGlzdCBvZiBwcm90b2NvbHMgdGhhdCBnZXQgbW9yZS4gaU1lc3Nh Z2Ugd2hpY2ggaXMgdmVyeSBzaW1pbGFyIHRlY2hub2xvZ3kgaGFzIGV2ZW4gZmFyIGJyb2FkZXIg ZGVwbG95bWVudCBhbmQgaW1wYWN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYXQgc2FpZCwgSSBh Z3JlZSB3aXRoIE1pY2hhZWwncyBjb21tZW50IHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIGxlYXJu IGZyb20gdGhlIHByaXZhY3kgaXNzdWVzIGluIFZpUFIgYW5kIG1ha2Ugc3VyZSB3ZSBnZXQgZG93 biByZXF1aXJlbWVudHMgdGhhdCB0dXJuZWQgb3V0IHRvIGJlIGEgbGF0ZSBzdXJwcmlzZSBpbiBW aVBSLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc3RpciBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7IHN0aXJAaWV0Zi5vcmc8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3RpciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zdGlyPC9hPjxicj4NCjxicj4NCjwvZm9udD48L3A+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_596979554D802045BBD45C051A4399E40D40A8F9STNTEXMB10cisne_-- From york@isoc.org Mon Nov 4 19:11:17 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C8521E80CF for ; Mon, 4 Nov 2013 19:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.472 X-Spam-Level: X-Spam-Status: No, score=-103.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BMT04BP8n4l for ; Mon, 4 Nov 2013 19:11:13 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0158.outbound.protection.outlook.com [207.46.163.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED2711E8172 for ; Mon, 4 Nov 2013 19:11:11 -0800 (PST) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB065.namprd06.prod.outlook.com (10.242.187.143) with Microsoft SMTP Server (TLS) id 15.0.800.7; Tue, 5 Nov 2013 03:11:09 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.179]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.186]) with mapi id 15.00.0800.005; Tue, 5 Nov 2013 03:11:08 +0000 From: Dan York To: Michael Procter , Richard Shockey Thread-Topic: [stir] draft-ietf-stir-problem-statement: Privacy requirements Thread-Index: AQHO2P2iY1r8C6EBDUO9hjycfMYyxZoVMNQAgAAMIACAADeoAIAABz0A///+xoCAAAoHAIAABdQA///mwwA= Date: Tue, 5 Nov 2013 03:11:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.4] x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(377454003)(479174003)(24454002)(69226001)(59766001)(63696002)(77982001)(80022001)(74876001)(15202345003)(56776001)(80976001)(74706001)(81686001)(46102001)(54356001)(65816001)(76482001)(53806001)(2656002)(81342001)(15975445006)(51856001)(15395725003)(83072001)(54316002)(74366001)(81542001)(76176001)(77096001)(47446002)(74662001)(56816003)(85306002)(4396001)(49866001)(47736001)(50986001)(47976001)(76796001)(19580395003)(36756003)(83322001)(31966008)(81816001)(76786001)(19580405001)(79102001)(74502001)(87266001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB065; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <36F47F11E1605C409C6C33939B07A71B@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" , Alex Bobotek , "Peterson, Jon" Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 03:11:17 -0000 Michael, On 11/4/13 12:41 PM, "Michael Procter" wrote: >Since the problem statement already offers a requirement for >protecting the calling party, I'd like to see a similar protection for >the called party. Arguably, the called party should have a higher >level of privacy: they didn't choose to be called in the first place. >The alternative (having the called party essentially advertise their >incoming calls in order to be able to verify the identity) is hardly >likely to encourage widespread deployment of verification. +1. I agree this is important and thank you for explaining a bit more. I didn't follow the first statements so the additional explanation helped. Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ From michael.hammer@yaanatech.com Tue Nov 5 07:50:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8723E11E81D5 for ; Tue, 5 Nov 2013 07:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ4EMHBBVrlt for ; Tue, 5 Nov 2013 07:50:46 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3D73111E81FD for ; Tue, 5 Nov 2013 07:50:44 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 5 Nov 2013 07:50:43 -0800 From: Michael Hammer To: "jon.peterson@neustar.biz" , "aallen@blackberry.com" , "stir@ietf.org" Thread-Topic: [stir] comments on draft-ietf-stir-problem-statement-00 Thread-Index: Ac7QUSi+XuSwVM/UQPSEhXox+oZw/gJFOdUAABAW9ID//+tngP/+vPxg Date: Tue, 5 Nov 2013 15:50:42 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEF691A@sc9-ex2k10mb1.corp.yaanatech.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.105] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007F_01CEDA14.DED07E90" MIME-Version: 1.0 Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 15:50:51 -0000 ------=_NextPart_000_007F_01CEDA14.DED07E90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01CEDA14.DED07E90" ------=_NextPart_001_0080_01CEDA14.DED07E90 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Jon, It would be possible to describe the salient features of any given service without naming it. I think the principle proposed is to not denigrate nor promote any particular vendor's implementation. One could argue that you will cross the line of misappropriating some vendor's IPR. Not sure if anyone has asked the vendor in question if they want to be named in an ID. Using IETF solutions and naming them is probably OK, since that is public. Concerning roaming service providers (carriers may have regulatory implications), visited system are given the crypto-credentials with which to authenticate a user that can then make outbound calls from that visited system. It is certainly possible that additional credentials could be extended from the home network to the visited one to use to authenticate the calling party to the called party. That however would likely require some liaison with 3GPP to determine what attributes and functions should be supported in mobile network. Has the IETF considered what might be adopted into IMS, VoLTE and such? Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Monday, November 04, 2013 6:26 PM To: Andrew Allen; stir@ietf.org Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 I don't think just the fact that some people happen to be familiar with iMessage is sufficient justification to make it a good example to use in the draft - particularly since it has short comings such as being currently restricted to a single platform. I believe Whatsapp has the most user's and also has multi vendor support. I suppose a list of e.g's is OK but I don't see why we need to describe in any detail a specific service - since most of them have similar characteristics. I think the fact that people are familiar with iMessage is a very good reason to list it as one example. I'm happy to include other examples, including Whatsapp. I would also be happy to make the descriptive text there less specific to any particular vendor, but I do have a hard time seeing how listing iMessage here would make people misunderstand the problem statement. [AA] My problem is with the statement "domains that have no relationship with the number assignee" Certainly they have a relationship - in fact a close and trusted one and the home domain provides the number to assert to the roamed to domain. So I think it needs to be made clearer. Okay, per the text I sent in my last mail, we can make this clearer. Again, what this means for STIR is that the the roaming carrier won't have the authority over the number. Jon Peterson Neustar, Inc. ------=_NextPart_001_0080_01CEDA14.DED07E90 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Jon,

 

It would be possible to = describe the salient features of any given service without naming = it.

I think the principle proposed is to not = denigrate nor promote any particular vendor’s = implementation.

One could argue that you will cross the line of = misappropriating some vendor’s IPR.

Not sure if anyone has = asked the vendor in question if they want to be named in an = ID.

Using IETF solutions and naming them is probably = OK, since that is public.

 

Concerning roaming = service providers (carriers may have regulatory implications), =

visited system are given the crypto-credentials = with which to authenticate a user

that can then make = outbound calls from that visited system. 

 

It is certainly possible = that additional credentials could be extended from the home network =

to the visited one to use to authenticate the = calling party to the called party.  That however =

would likely require some liaison with 3GPP to = determine what attributes and functions

should be supported in = mobile network. 

Has the IETF considered what might be adopted = into IMS, VoLTE and such?

 

Mike

 

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Peterson, Jon
Sent: Monday, November 04, 2013 6:26 = PM
To: Andrew Allen; stir@ietf.org
Subject: Re: = [stir] comments on = draft-ietf-stir-problem-statement-00

 

<AA>I don’t think just the fact that = some people happen to be familiar with iMessage is sufficient = justification to make it a good example to use in the draft – = particularly since it has short comings such as being currently = restricted to a single platform. I believe Whatsapp has the most = user’s and also has multi vendor support. I suppose a list of = e.g’s is OK but I don’t see why we need to describe in any = detail a specific service – since most of them have similar = characteristics.</AA>

 

I think the fact that people are familiar with = iMessage is a very good reason to list it as one example. I'm happy to = include other examples, including Whatsapp. I would also be happy to = make the descriptive text there less specific to any particular vendor, = but I do have a hard time seeing how listing iMessage here would make = people misunderstand the problem = statement.

 

[AA] My problem is with the statement = “domains that have no = relationship with the number assignee” Certainly they have a relationship – in = fact a close and trusted one and the home domain provides the number to = assert to the roamed to domain.  So I think it needs to be made = clearer.

 

Okay, per the text I sent in my last = mail, we can make this clearer. Again, what this means for STIR is that = the the roaming carrier won't have the authority over the = number. 

 

Jon Peterson

Neustar, Inc.

 

=
------=_NextPart_001_0080_01CEDA14.DED07E90-- ------=_NextPart_000_007F_01CEDA14.DED07E90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEw NTE1NTA0MVowIwYJKoZIhvcNAQkEMRYEFNRi2FgOZyBI2QN+ym5Nu4q1YFpdMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAApBiJJMuMjytJbSvlnE390tvQ/dL8+KduuhRbQeJ gHn93gYFmxfwt83d5K0zssUDgdwjQWNc239qSeZW8USXC3qjKHt//vL78xv4rijQQWdeth2mE6rM 6E7UiRFj1pwdUN70oZ9ZBhL+kNzDw/s+IHZX8I6RJ4bKbnB8y2FtG1HaN4UvZAT0m+h3UUkLPpmx rOU9Lus40SgaNTyLzk160+8+6cxqI3tzKg0ygQfsX7RF3zkFAr54mrPYm+LJ4HkIf7SGiKTZ9vAb l8/ebmI7wWkWi7LnAXoVXt3PaN1g2oS/LukHZxU+aurpamq6SCQ8ybdWDYhffr5qBaLCK3jedgAA AAAAAA== ------=_NextPart_000_007F_01CEDA14.DED07E90-- From aallen@blackberry.com Tue Nov 5 08:45:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2074B11E8167 for ; Tue, 5 Nov 2013 08:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3Jrgt6H85FD for ; Tue, 5 Nov 2013 08:45:12 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id A7BA711E82B9 for ; Tue, 5 Nov 2013 08:44:40 -0800 (PST) Received: from xct105ads.rim.net ([10.67.111.46]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 05 Nov 2013 11:44:32 -0500 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 10:44:32 -0600 From: Andrew Allen To: "Peterson, Jon" , 'Richard Shockey' , "'stir@ietf.org'" Thread-Topic: [stir] comments on draft-ietf-stir-problem-statement-00 Thread-Index: Ac7QUSi+XuSwVM/UQPSEhXox+oZw/gJFOdUAABAW9ID//+tngIAAp9QAgABE4kf//50YUA== Date: Tue, 5 Nov 2013 16:44:31 +0000 Message-ID: References: <596979554D802045BBD45C051A4399E40D40A87A@STNTEXMB10.cis.neustar.com> In-Reply-To: <596979554D802045BBD45C051A4399E40D40A87A@STNTEXMB10.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E4827BXMB104ADSrimnet_" MIME-Version: 1.0 Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:45:44 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E4827BXMB104ADSrimnet_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 DQpKb24NCg0KSSBoYXZlIG5vdCB1c2VkIGlNZXNzYWdlIHNvIHVzaW5nIGl0IGFzIGFuIGV4YW1w bGUgZG9lc27igJl0IGhlbHAgbWUgb3IgdGhlIGxhcmdlIGNvbW11bml0eSBvZiBub24gaVBob25l IHVzZXJzIG91dCB0aGVyZSB0byB1bmRlcnN0YW5kLiBJIGhhdmUgaG93ZXZlciB1c2VkIFdoYXRz QXBwLCBCbGFja0JlcnJ5IE1lc3NlbmdlciBhbmQgVmliZXIg4oCTIGFsbCBvZiB3aGljaCBhcmUg dmVyeSBwb3B1bGFyIG1lc3NhZ2luZyBzZXJ2aWNlcy4gV2VDaGF0IGlzIGFub3RoZXIgbWVzc2Fn aW5nIHNlcnZpY2VzIHRoYXQgaXMgYWxzbyBleHRyZW1lbHkgcG9wdWxhciBpbiBDaGluYSBhbmQg bWFueSBvdGhlciBBc2lhbiBjb3VudHJpZXMuDQoNCkkgZG9u4oCZdCBzZWUgYW55dGhpbmcgc3Bl Y2lhbCBhYm91dCBpTWVzc2FnZSDigJMgb3RoZXIgc2VydmljZXMgaGF2ZSBtb3JlIHVzZXJzLCBo YXZlIG11bHRpLXBsYXRmb3JtIHN1cHBvcnQgb3IgaGF2ZSBiZWVuIGFyb3VuZCBsb25nIGJlZm9y ZSBpUGhvbmUgd2FzIGEgZ2xlYW0gaW4gdGhlIFN0ZXZlIEpvYnPigJkgZXllIGFuZCBhbGwgcHJv dmlkZSBhbiBvdXQgb2YgYmFuZCBjb25uZWN0aW9uLg0KDQpNeSBwcm9wb3NhbCBpcyB0byByZXdy aXRlIHRoZSB0ZXh0IGFzIGZvbGxvd3M6DQoNCg0KRm9yIGV4YW1wbGUsIHRoZSBBcHBsZSBpTWVz c2FnZSBzZXJ2aWNlLCB3aGljaCBhbGxvd3MgaVBob25lIHVzZXJzIHRvIHNlbmQgU01TIG1lc3Nh Z2VzIHRvIG9uZSBhbm90aGVyIG92ZXIgdGhlIEludGVybmV0IHJhdGhlciB0aGFuIG92ZXIgdGhl IFBTVE4uICBMaWtlIFZJUFIsIGlNZXNzYWdlIGNyZWF0ZXMgYW4gb3V0LW9mLWJhbmQgY29ubmVj dGlvbiBvdmVyIHRoZSBJbnRlcm5ldCBiZXR3ZWVuIGlQaG9uZXM7IHVubGlrZSBWSVBSLCB0aGUg cmVuZGV6dm91cyBzZXJ2aWNlIGlzIHByb3ZpZGVkIGJ5IGEgdHJ1c3RlZCBjZW50cmFsaXplZCBk YXRhYmFzZSBvZiBpUGhvbmVzIHJhdGhlciB0aGFuIGJ5IGEgREhULiAgV2hpbGUgQXBwbGUncyBz ZXJ2aWNlIGlzIHNwZWNpZmljIHRvIGN1c3RvbWVycyBvZiBpdHMgc21hcnQgcGhvbmVzLCBpdCBz ZWVtcyBjbGVhciB0aGF0IHNpbWlsYXIgZGF0YWJhc2VzIGNvdWxkIGJlIHByb3ZpZGVkIGJ5IG5l dXRyYWwgdGhpcmQgcGFydGllcyBpbiBhIHBvc2l0aW9uIHRvIGNvb3JkaW5hdGUgYmV0d2VlbiBl bmRwb2ludHMuDQoNClJFV1JJVEUgQVM6DQoNCk1vYmlsZSBtZXNzYWdpbmcgc2VydmljZXMsIChl LmcuIFdoYXRzYXBwLCBWaWJlciwgQmxhY2tCZXJyeSBNZXNzZW5nZXIsIEFwcGxl4oCZcyBpTWVz c2FnZSBhbmQgV2VDaGF0KSwgYWxsb3cgc21hcnQgcGhvbmUgdXNlcnMgdG8gc2VuZCB0ZXh0IG1l c3NhZ2VzIHRvIG9uZSBhbm90aGVyIG92ZXIgdGhlIEludGVybmV0IHJhdGhlciB0aGFuIG92ZXIg dGhlIFBTVE4uICBMaWtlIFZJUFIsIHN1Y2ggc2VydmljZXMgY3JlYXRlIGFuIG91dC1vZi1iYW5k IGNvbm5lY3Rpb24gb3ZlciB0aGUgSW50ZXJuZXQgYmV0d2VlbiBzbWFydCBwaG9uZXM7IHVubGlr ZSBWSVBSLCB0aGUgcmVuZGV6dm91cyBzZXJ2aWNlIGlzIHByb3ZpZGVkIGJ5IGEgdHJ1c3RlZCBj ZW50cmFsaXplZCBkYXRhYmFzZSByYXRoZXIgdGhhbiBieSBhIERIVC4gIFdoaWxlIHN1Y2ggbWVz c2FnaW5nIHNlcnZpY2VzIGFyZSBzcGVjaWZpYyB0byB0aGUgdXNlcnMgb2YgdGhlIHNwZWNpZmlj IHNlcnZpY2UsIGl0IHNlZW1zIGNsZWFyIHRoYXQgc2ltaWxhciBkYXRhYmFzZXMgY291bGQgYmUg cHJvdmlkZWQgYnkgbmV1dHJhbCB0aGlyZCBwYXJ0aWVzIGluIGEgcG9zaXRpb24gdG8gY29vcmRp bmF0ZSBiZXR3ZWVuIGVuZHBvaW50cy4NCg0KDQpBbmRyZXcNCg0KRnJvbTogUGV0ZXJzb24sIEpv biBbbWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpel0NClNlbnQ6IE1vbmRheSwgTm92ZW1i ZXIgMDQsIDIwMTMgOToyMCBQTQ0KVG86ICdSaWNoYXJkIFNob2NrZXknOyBBbmRyZXcgQWxsZW47 ICdzdGlyQGlldGYub3JnJw0KU3ViamVjdDogUkU6IFtzdGlyXSBjb21tZW50cyBvbiBkcmFmdC1p ZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDANCg0KV2VsbC4gTWF5YmUgSSB1bmRlcnN0b29k IEFuZHJldydzIG1lc3NhZ2UgYSBiaXQgZGlmZmVyZW50bHkgdGhhbiB5b3UgZGlkLiBXaGF0IGhl IG9yaWdpbmFsbHkgYXNrZWQgd2FzIHRoYXQgc2VydmljZXMgbGlrZSBCbGFja2JlcnJ5IE1lc3Nl bmdlciAoYWxzbyBhbiBvdXQtb2YtYmFuZCBzZXJ2aWNlIGxpa2UgaU1lc3NhZ2UpIGJlIGluY2x1 ZGVkIHNvIHdlIGRvbid0IGFwcGVhciB0byBiZSBmYXZvcmluZyB0aGUgd29yayBvZiBhIHNpbmds ZSBtb25vbGl0aGljIHZlbmRvci4gSGUgdGhlbiBhc2tlZCB0aGF0IHdlIHJlZmVyZW5jZSBzb21l dGhpbmcgbGlrZSBXaGF0c2FwcCwgYSBwbGF0Zm9ybS1uZXV0cmFsIHNlcnZpY2UgYWxvbmcgdGhl c2UgbGluZXMuIEkgaGF2ZW4ndCBvYmplY3RlZCB0byBlaXRoZXIgb2YgdGhvc2UgcmVxdWVzdHMu IEJ1dCB0aGUgc3VnZ2VzdGlvbiB0aGF0IHdlIHJlc3RyaWN0IHRoaXMgc2VjdGlvbiB0byBzb21l IG90aGVyIHZlbmRvcidzIHNvbHV0aW9uIHdoaWxlIHJlbW92aW5nIHRoZSBvbmUgd2l0aCB3aGlj aCBwZW9wbGUgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0gYXJlIG1vc3QgZmFtaWxp YXIgd291bGQsIEkgdGhpbmssIGJlIGEgZGlmZmVyZW50IG1hdHRlci4NCg0KVGhlIG9iamVjdGl2 ZSBvZiB0aGlzIGRvY3VtZW50IGlzIG5vdCB0byBwcm9tb3RlIGFueSBzb2x1dGlvbiwgaXQncyBh IHByb2JsZW0gc3RhdGVtZW50IGRvY3VtZW50LiBXaGF0ZXZlciB3ZSByZWZlcmVuY2UgaGVyZSBp cyBlbnRpcmVseSBleGVtcGxhcnkgYW5kIGV4cGxpY2l0bHkgbm90IGEgY29tcG9uZW50IG9mIHRo ZSBTVElSIHNvbHV0aW9uLiBXaGlsZSB3ZSBjYW4gYWxsIHNlZSB0aGUgdmVoZW1lbmNlIG9mIHlv dXIgcGVyc29uYWwgb2JqZWN0aW9uLCBJIGFtIG5vdCBzZWVpbmcgYW55IHJhdGlvbmFsIHJlYXNv biBoZXJlIHRvIHN0cmlrZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBkb2N1bWVudCB0aGF0IGFjdHVh bGx5IGhlbHBzIHBlb3BsZSB0byB1bmRlcnN0YW5kIHdoYXQgdGhpcyB3b3JrIGlzIGFib3V0LiBO b3IgZG8gSSB0aGluayB5b3VyIGN1cmlvdXMgY29uc3RydWFsIG9mIEFuZHJldydzIChhY3R1YWxs eSBxdWl0ZSByZWFzb25hYmxlKSByZXF1ZXN0LCB3aGVuIGNvbWJpbmVkIHdpdGggeW91ciBvd24g bW9yZSBvYnNjdXJlIGNvbXBsYWludCwganVzdGlmaWVzIGlzc3VpbmcgYmxhbmtldCBjb21tYW5k cyBhcyB5b3UgZG8gYmVsb3cuIFdoeSBkb24ndCB3ZSBsZWF2ZSBpdCB0byB0aGUgY2hhaXJzIHRv IGFzc2VzcyBjb25zZW5zdXMuDQoNCkpvbiBQZXRlcnNvbg0KTmV1c3RhciwgSW5jLg0KDQoNCg0K U2VudCB3aXRoIEdvb2QgKHd3dy5nb29kLmNvbTxodHRwOi8vd3d3Lmdvb2QuY29tPikNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmljaGFyZCBTaG9ja2V5IFtyaWNoYXJk QHNob2NrZXkudXM8bWFpbHRvOnJpY2hhcmRAc2hvY2tleS51cz5dDQpTZW50OiBNb25kYXksIE5v dmVtYmVyIDA0LCAyMDEzIDA4OjI3IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IFBldGVy c29uLCBKb247ICdBbmRyZXcgQWxsZW4nOyBzdGlyQGlldGYub3JnPG1haWx0bzpzdGlyQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IFtzdGlyXSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXN0aXItcHJv YmxlbS1zdGF0ZW1lbnQtMDANCg0KDQpKb24gLi4gd2hhdCBhYm91dCBOTyBkb27igJl0IHlvdSB1 bmRlcnN0YW5kLg0KDQpXZSBvYmplY3QgdG8gdGhlIHJlZmVyZW5jZXMuIFJlbW92ZSB0aGVtIG5v dy4NCg0KRnJvbTogc3Rpci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzdGlyLWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGV0ZXJz b24sIEpvbg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwNCwgMjAxMyA2OjI2IFBNDQpUbzogQW5k cmV3IEFsbGVuOyBzdGlyQGlldGYub3JnPG1haWx0bzpzdGlyQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtzdGlyXSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQt MDANCg0KPEFBPkkgZG9u4oCZdCB0aGluayBqdXN0IHRoZSBmYWN0IHRoYXQgc29tZSBwZW9wbGUg aGFwcGVuIHRvIGJlIGZhbWlsaWFyIHdpdGggaU1lc3NhZ2UgaXMgc3VmZmljaWVudCBqdXN0aWZp Y2F0aW9uIHRvIG1ha2UgaXQgYSBnb29kIGV4YW1wbGUgdG8gdXNlIGluIHRoZSBkcmFmdCDigJMg cGFydGljdWxhcmx5IHNpbmNlIGl0IGhhcyBzaG9ydCBjb21pbmdzIHN1Y2ggYXMgYmVpbmcgY3Vy cmVudGx5IHJlc3RyaWN0ZWQgdG8gYSBzaW5nbGUgcGxhdGZvcm0uIEkgYmVsaWV2ZSBXaGF0c2Fw cCBoYXMgdGhlIG1vc3QgdXNlcuKAmXMgYW5kIGFsc28gaGFzIG11bHRpIHZlbmRvciBzdXBwb3J0 LiBJIHN1cHBvc2UgYSBsaXN0IG9mIGUuZ+KAmXMgaXMgT0sgYnV0IEkgZG9u4oCZdCBzZWUgd2h5 IHdlIG5lZWQgdG8gZGVzY3JpYmUgaW4gYW55IGRldGFpbCBhIHNwZWNpZmljIHNlcnZpY2Ug4oCT IHNpbmNlIG1vc3Qgb2YgdGhlbSBoYXZlIHNpbWlsYXIgY2hhcmFjdGVyaXN0aWNzLjwvQUE+DQoN CkkgdGhpbmsgdGhlIGZhY3QgdGhhdCBwZW9wbGUgYXJlIGZhbWlsaWFyIHdpdGggaU1lc3NhZ2Ug aXMgYSB2ZXJ5IGdvb2QgcmVhc29uIHRvIGxpc3QgaXQgYXMgb25lIGV4YW1wbGUuIEknbSBoYXBw eSB0byBpbmNsdWRlIG90aGVyIGV4YW1wbGVzLCBpbmNsdWRpbmcgV2hhdHNhcHAuIEkgd291bGQg YWxzbyBiZSBoYXBweSB0byBtYWtlIHRoZSBkZXNjcmlwdGl2ZSB0ZXh0IHRoZXJlIGxlc3Mgc3Bl Y2lmaWMgdG8gYW55IHBhcnRpY3VsYXIgdmVuZG9yLCBidXQgSSBkbyBoYXZlIGEgaGFyZCB0aW1l IHNlZWluZyBob3cgbGlzdGluZyBpTWVzc2FnZSBoZXJlIHdvdWxkIG1ha2UgcGVvcGxlIG1pc3Vu ZGVyc3RhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50Lg0KDQpbQUFdIE15IHByb2JsZW0gaXMgd2l0 aCB0aGUgc3RhdGVtZW50IOKAnGRvbWFpbnMgdGhhdCBoYXZlIG5vIHJlbGF0aW9uc2hpcCB3aXRo IHRoZSBudW1iZXIgYXNzaWduZWXigJ0gQ2VydGFpbmx5IHRoZXkgaGF2ZSBhIHJlbGF0aW9uc2hp cCDigJMgaW4gZmFjdCBhIGNsb3NlIGFuZCB0cnVzdGVkIG9uZSBhbmQgdGhlIGhvbWUgZG9tYWlu IHByb3ZpZGVzIHRoZSBudW1iZXIgdG8gYXNzZXJ0IHRvIHRoZSByb2FtZWQgdG8gZG9tYWluLiAg U28gSSB0aGluayBpdCBuZWVkcyB0byBiZSBtYWRlIGNsZWFyZXIuDQoNCg0KDQoNCk9rYXksIHBl ciB0aGUgdGV4dCBJIHNlbnQgaW4gbXkgbGFzdCBtYWlsLCB3ZSBjYW4gbWFrZSB0aGlzIGNsZWFy ZXIuIEFnYWluLCB3aGF0IHRoaXMgbWVhbnMgZm9yIFNUSVIgaXMgdGhhdCB0aGUgdGhlIHJvYW1p bmcgY2FycmllciB3b24ndCBoYXZlIHRoZSBhdXRob3JpdHkgb3ZlciB0aGUgbnVtYmVyLg0KDQpK b24gUGV0ZXJzb24NCk5ldXN0YXIsIEluYy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClRoaXMgdHJhbnNtaXNz aW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg aW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90 ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxl Z2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRo aXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVu dCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBp biBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwg ZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5p bnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu Cg== --_000_BBF5DDFE515C3946BC18D733B20DAD2338E4827BXMB104ADSrimnet_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGhhdmUgbm90IHVz ZWQgaU1lc3NhZ2Ugc28gdXNpbmcgaXQgYXMgYW4gZXhhbXBsZSBkb2VzbuKAmXQgaGVscCBtZSBv ciB0aGUgbGFyZ2UgY29tbXVuaXR5IG9mIG5vbiBpUGhvbmUgdXNlcnMgb3V0IHRoZXJlIHRvIHVu ZGVyc3RhbmQuIEkgaGF2ZSBob3dldmVyIHVzZWQgV2hhdHNBcHAsIEJsYWNrQmVycnkgTWVzc2Vu Z2VyIGFuZCBWaWJlciDigJMgYWxsIG9mIHdoaWNoDQogYXJlIHZlcnkgcG9wdWxhciBtZXNzYWdp bmcgc2VydmljZXMuIFdlQ2hhdCBpcyBhbm90aGVyIG1lc3NhZ2luZyBzZXJ2aWNlcyB0aGF0IGlz IGFsc28gZXh0cmVtZWx5IHBvcHVsYXIgaW4gQ2hpbmEgYW5kIG1hbnkgb3RoZXIgQXNpYW4gY291 bnRyaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHNl ZSBhbnl0aGluZyBzcGVjaWFsIGFib3V0IGlNZXNzYWdlIOKAkyBvdGhlciBzZXJ2aWNlcyBoYXZl IG1vcmUgdXNlcnMsIGhhdmUgbXVsdGktcGxhdGZvcm0gc3VwcG9ydCBvciBoYXZlIGJlZW4gYXJv dW5kIGxvbmcgYmVmb3JlIGlQaG9uZSB3YXMgYSBnbGVhbSBpbiB0aGUgU3RldmUgSm9ic+KAmSBl eWUgYW5kIGFsbCBwcm92aWRlIGFuIG91dCBvZiBiYW5kDQogY29ubmVjdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk15IHByb3Bvc2FsIGlzIHRvIHJld3JpdGUgdGhl IHRleHQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5Gb3IgZXhhbXBsZSwgdGhlIEFwcGxlIGlNZXNzYWdlIHNlcnZpY2UsIHdoaWNoIGFsbG93cyBp UGhvbmUgdXNlcnMgdG8gc2VuZCBTTVMgbWVzc2FnZXMgdG8gb25lIGFub3RoZXIgb3ZlciB0aGUg SW50ZXJuZXQgcmF0aGVyIHRoYW4gb3ZlciB0aGUgUFNUTi4mbmJzcDsgTGlrZSBWSVBSLCBpTWVz c2FnZSBjcmVhdGVzIGFuDQogb3V0LW9mLWJhbmQgY29ubmVjdGlvbiBvdmVyIHRoZSBJbnRlcm5l dCBiZXR3ZWVuIGlQaG9uZXM7IHVubGlrZSBWSVBSLCB0aGUgcmVuZGV6dm91cyBzZXJ2aWNlIGlz IHByb3ZpZGVkIGJ5IGEgdHJ1c3RlZCBjZW50cmFsaXplZCBkYXRhYmFzZSBvZiBpUGhvbmVzIHJh dGhlciB0aGFuIGJ5IGEgREhULiZuYnNwOyBXaGlsZSBBcHBsZSdzIHNlcnZpY2UgaXMgc3BlY2lm aWMgdG8gY3VzdG9tZXJzIG9mIGl0cyBzbWFydCBwaG9uZXMsIGl0IHNlZW1zIGNsZWFyDQogdGhh dCBzaW1pbGFyIGRhdGFiYXNlcyBjb3VsZCBiZSBwcm92aWRlZCBieSBuZXV0cmFsIHRoaXJkIHBh cnRpZXMgaW4gYSBwb3NpdGlvbiB0byBjb29yZGluYXRlIGJldHdlZW4gZW5kcG9pbnRzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UkVXUklURSBBUzo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPk1vYmlsZSBtZXNzYWdpbmcgc2VydmljZXMsIChlLmcuIFdoYXRzYXBwLCBWaWJlciwg QmxhY2tCZXJyeSBNZXNzZW5nZXIsIEFwcGxl4oCZcyBpTWVzc2FnZSBhbmQgV2VDaGF0KSwgYWxs b3cgc21hcnQgcGhvbmUgdXNlcnMgdG8gc2VuZCB0ZXh0IG1lc3NhZ2VzIHRvIG9uZSBhbm90aGVy IG92ZXIgdGhlIEludGVybmV0DQogcmF0aGVyIHRoYW4gb3ZlciB0aGUgUFNUTi4mbmJzcDsgTGlr ZSBWSVBSLCBzdWNoIHNlcnZpY2VzIGNyZWF0ZSBhbiBvdXQtb2YtYmFuZCBjb25uZWN0aW9uIG92 ZXIgdGhlIEludGVybmV0IGJldHdlZW4gc21hcnQgcGhvbmVzOyB1bmxpa2UgVklQUiwgdGhlIHJl bmRlenZvdXMgc2VydmljZSBpcyBwcm92aWRlZCBieSBhIHRydXN0ZWQgY2VudHJhbGl6ZWQgZGF0 YWJhc2UgcmF0aGVyIHRoYW4gYnkgYSBESFQuJm5ic3A7IFdoaWxlIHN1Y2ggbWVzc2FnaW5nIHNl cnZpY2VzDQogYXJlIHNwZWNpZmljIHRvIHRoZSB1c2VycyBvZiB0aGUgc3BlY2lmaWMgc2Vydmlj ZSwgaXQgc2VlbXMgY2xlYXIgdGhhdCBzaW1pbGFyIGRhdGFiYXNlcyBjb3VsZCBiZSBwcm92aWRl ZCBieSBuZXV0cmFsIHRoaXJkIHBhcnRpZXMgaW4gYSBwb3NpdGlvbiB0byBjb29yZGluYXRlIGJl dHdlZW4gZW5kcG9pbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkFuZHJldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBldGVyc29uLCBKb24gW21haWx0bzpqb24u cGV0ZXJzb25AbmV1c3Rhci5iaXpdDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJl ciAwNCwgMjAxMyA5OjIwIFBNPGJyPg0KPGI+VG86PC9iPiAnUmljaGFyZCBTaG9ja2V5JzsgQW5k cmV3IEFsbGVuOyAnc3RpckBpZXRmLm9yZyc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtzdGly XSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPldlbGwuIE1heWJlIEkgdW5kZXJzdG9vZCBBbmRyZXcncyBtZXNzYWdl IGEgYml0IGRpZmZlcmVudGx5IHRoYW4geW91IGRpZC4gV2hhdCBoZSBvcmlnaW5hbGx5IGFza2Vk IHdhcyB0aGF0IHNlcnZpY2VzIGxpa2UgQmxhY2tiZXJyeSBNZXNzZW5nZXIgKGFsc28gYW4gb3V0 LW9mLWJhbmQgc2VydmljZQ0KIGxpa2UgaU1lc3NhZ2UpIGJlIGluY2x1ZGVkIHNvIHdlIGRvbid0 IGFwcGVhciB0byBiZSBmYXZvcmluZyB0aGUgd29yayBvZiBhIHNpbmdsZSBtb25vbGl0aGljIHZl bmRvci4gSGUgdGhlbiBhc2tlZCB0aGF0IHdlIHJlZmVyZW5jZSBzb21ldGhpbmcgbGlrZSBXaGF0 c2FwcCwgYSBwbGF0Zm9ybS1uZXV0cmFsIHNlcnZpY2UgYWxvbmcgdGhlc2UgbGluZXMuIEkgaGF2 ZW4ndCBvYmplY3RlZCB0byBlaXRoZXIgb2YgdGhvc2UgcmVxdWVzdHMuIEJ1dA0KIHRoZSBzdWdn ZXN0aW9uIHRoYXQgd2UgcmVzdHJpY3QgdGhpcyBzZWN0aW9uIHRvIHNvbWUgb3RoZXIgdmVuZG9y J3Mgc29sdXRpb24gd2hpbGUgcmVtb3ZpbmcgdGhlIG9uZSB3aXRoIHdoaWNoIHBlb3BsZSB0cnlp bmcgdG8gdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSBhcmUgbW9zdCBmYW1pbGlhciB3b3VsZCwgSSB0 aGluaywgYmUgYSBkaWZmZXJlbnQgbWF0dGVyLjxicj4NCjxicj4NClRoZSBvYmplY3RpdmUgb2Yg dGhpcyBkb2N1bWVudCBpcyBub3QgdG8gcHJvbW90ZSBhbnkgc29sdXRpb24sIGl0J3MgYSBwcm9i bGVtIHN0YXRlbWVudCBkb2N1bWVudC4gV2hhdGV2ZXIgd2UgcmVmZXJlbmNlIGhlcmUgaXMgZW50 aXJlbHkgZXhlbXBsYXJ5IGFuZCBleHBsaWNpdGx5IG5vdCBhIGNvbXBvbmVudCBvZiB0aGUgU1RJ UiBzb2x1dGlvbi4gV2hpbGUgd2UgY2FuIGFsbCBzZWUgdGhlIHZlaGVtZW5jZSBvZiB5b3VyIHBl cnNvbmFsIG9iamVjdGlvbiwNCiBJIGFtIG5vdCBzZWVpbmcgYW55IHJhdGlvbmFsIHJlYXNvbiBo ZXJlIHRvIHN0cmlrZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBkb2N1bWVudCB0aGF0IGFjdHVhbGx5 IGhlbHBzIHBlb3BsZSB0byB1bmRlcnN0YW5kIHdoYXQgdGhpcyB3b3JrIGlzIGFib3V0LiBOb3Ig ZG8gSSB0aGluayB5b3VyIGN1cmlvdXMgY29uc3RydWFsIG9mIEFuZHJldydzIChhY3R1YWxseSBx dWl0ZSByZWFzb25hYmxlKSByZXF1ZXN0LCB3aGVuIGNvbWJpbmVkIHdpdGggeW91cg0KIG93biBt b3JlIG9ic2N1cmUgY29tcGxhaW50LCBqdXN0aWZpZXMgaXNzdWluZyBibGFua2V0IGNvbW1hbmRz IGFzIHlvdSBkbyBiZWxvdy4gV2h5IGRvbid0IHdlIGxlYXZlIGl0IHRvIHRoZSBjaGFpcnMgdG8g YXNzZXNzIGNvbnNlbnN1cy48YnI+DQo8YnI+DQpKb24gUGV0ZXJzb248YnI+DQpOZXVzdGFyLCBJ bmMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KU2VudCB3aXRoIEdvb2QgKDxhIGhyZWY9Imh0dHA6 Ly93d3cuZ29vZC5jb20iPnd3dy5nb29kLmNvbTwvYT4pPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQo8Yj5Gcm9tOiZuYnNwOzwvYj5SaWNoYXJkIFNob2Nr ZXkgWzxhIGhyZWY9Im1haWx0bzpyaWNoYXJkQHNob2NrZXkudXMiPnJpY2hhcmRAc2hvY2tleS51 czwvYT5dPGJyPg0KPGI+U2VudDombmJzcDs8L2I+TW9uZGF5LCBOb3ZlbWJlciAwNCwgMjAxMyAw ODoyNyBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWU8YnI+DQo8Yj5UbzombmJzcDs8L2I+UGV0ZXJz b24sIEpvbjsgJ0FuZHJldyBBbGxlbic7IDxhIGhyZWY9Im1haWx0bzpzdGlyQGlldGYub3JnIj5z dGlyQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6Jm5ic3A7PC9iPlJFOiBbc3Rpcl0gY29t bWVudHMgb24gZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50LTAwPGJyPg0KPGJyPg0K PGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkpvbiAuLiB3aGF0IGFib3V0IE5PIGRvbuKAmXQgeW91IHVu ZGVyc3RhbmQuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XZSBv YmplY3QgdG8gdGhlIHJlZmVyZW5jZXMuIFJlbW92ZSB0aGVtIG5vdy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiA8YSBocmVmPSJtYWlsdG86 c3Rpci1ib3VuY2VzQGlldGYub3JnIj5zdGlyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVm PSJtYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3Rpci1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZjwvYj4gUGV0ZXJzb24sIEpvbjxicj4NCjxiPlNlbnQ6 PC9iPiBNb25kYXksIE5vdmVtYmVyIDA0LCAyMDEzIDY6MjYgUE08YnI+DQo8Yj5Ubzo8L2I+IEFu ZHJldyBBbGxlbjsgPGEgaHJlZj0ibWFpbHRvOnN0aXJAaWV0Zi5vcmciPnN0aXJAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3Rpcl0gY29tbWVudHMgb24gZHJhZnQtaWV0 Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50LTAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtBQSZndDtJ IGRvbuKAmXQgdGhpbmsganVzdCB0aGUgZmFjdCB0aGF0IHNvbWUgcGVvcGxlIGhhcHBlbiB0byBi ZSBmYW1pbGlhciB3aXRoIGlNZXNzYWdlIGlzIHN1ZmZpY2llbnQganVzdGlmaWNhdGlvbiB0byBt YWtlIGl0IGEgZ29vZCBleGFtcGxlIHRvIHVzZSBpbiB0aGUgZHJhZnQg4oCTIHBhcnRpY3VsYXJs eSBzaW5jZSBpdCBoYXMgc2hvcnQgY29taW5ncyBzdWNoIGFzDQogYmVpbmcgY3VycmVudGx5IHJl c3RyaWN0ZWQgdG8gYSBzaW5nbGUgcGxhdGZvcm0uIEkgYmVsaWV2ZSBXaGF0c2FwcCBoYXMgdGhl IG1vc3QgdXNlcuKAmXMgYW5kIGFsc28gaGFzIG11bHRpIHZlbmRvciBzdXBwb3J0LiBJIHN1cHBv c2UgYSBsaXN0IG9mIGUuZ+KAmXMgaXMgT0sgYnV0IEkgZG9u4oCZdCBzZWUgd2h5IHdlIG5lZWQg dG8gZGVzY3JpYmUgaW4gYW55IGRldGFpbCBhIHNwZWNpZmljIHNlcnZpY2Ug4oCTIHNpbmNlIG1v c3Qgb2YgdGhlbSBoYXZlIHNpbWlsYXINCiBjaGFyYWN0ZXJpc3RpY3MuJmx0Oy9BQSZndDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JIHRoaW5r IHRoZSBmYWN0IHRoYXQgcGVvcGxlIGFyZSBmYW1pbGlhciB3aXRoIGlNZXNzYWdlIGlzIGEgdmVy eSBnb29kIHJlYXNvbiB0byBsaXN0IGl0IGFzIG9uZSBleGFtcGxlLiBJJ20gaGFwcHkgdG8gaW5j bHVkZSBvdGhlciBleGFtcGxlcywgaW5jbHVkaW5nDQogV2hhdHNhcHAuIEkgd291bGQgYWxzbyBi ZSBoYXBweSB0byBtYWtlIHRoZSBkZXNjcmlwdGl2ZSB0ZXh0IHRoZXJlIGxlc3Mgc3BlY2lmaWMg dG8gYW55IHBhcnRpY3VsYXIgdmVuZG9yLCBidXQgSSBkbyBoYXZlIGEgaGFyZCB0aW1lIHNlZWlu ZyBob3cgbGlzdGluZyBpTWVzc2FnZSBoZXJlIHdvdWxkIG1ha2UgcGVvcGxlIG1pc3VuZGVyc3Rh bmQgdGhlIHByb2JsZW0gc3RhdGVtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0FBXSBNeSBwcm9ibGVtIGlz IHdpdGggdGhlIHN0YXRlbWVudCDigJw8L3NwYW4+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5kb21haW5zIHRoYXQgaGF2ZSBubyByZWxhdGlvbnNoaXAgd2l0aCB0aGUgbnVtYmVyIGFzc2ln bmVl4oCdPC9zcGFuPjwvaT4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DZXJ0YWlubHkg dGhleSBoYXZlIGEgcmVsYXRpb25zaGlwIOKAkyBpbiBmYWN0IGEgY2xvc2UgYW5kIHRydXN0ZWQg b25lIGFuZCB0aGUgaG9tZSBkb21haW4gcHJvdmlkZXMgdGhlIG51bWJlciB0byBhc3NlcnQgdG8g dGhlIHJvYW1lZCB0byBkb21haW4uICZuYnNwO1NvIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgbWFk ZSBjbGVhcmVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2theSwgcGVyIHRoZSB0 ZXh0IEkgc2VudCBpbiBteSBsYXN0IG1haWwsIHdlIGNhbiBtYWtlIHRoaXMgY2xlYXJlci4gQWdh aW4sIHdoYXQgdGhpcyBtZWFucyBmb3IgU1RJUiBpcyB0aGF0IHRoZSB0aGUgcm9hbWluZyBjYXJy aWVyIHdvbid0IGhhdmUgdGhlIGF1dGhvcml0eSBvdmVyIHRoZSBudW1iZXIuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Kb24gUGV0ZXJzb248L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TmV1c3RhciwgSW5jLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPlRoaXMgdHJhbnNtaXNz aW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg aW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90 ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxl Z2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRo aXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVu dCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBp biBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwg ZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5p bnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu PGJyPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD2338E4827BXMB104ADSrimnet_-- From jon.peterson@neustar.biz Tue Nov 5 08:47:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49C21E8264 for ; Tue, 5 Nov 2013 08:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.87 X-Spam-Level: X-Spam-Status: No, score=-105.87 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t0dI6ersqkU for ; Tue, 5 Nov 2013 08:47:40 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 27AC011E80E9 for ; Tue, 5 Nov 2013 08:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383670596; x=1699025526; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=rWMQi/sJEfXmPSxgP59BLPs8Mw5f9WgxpLEK5w2p+oA=; b=ms3H7Jcly3h2Lro7EyHF2YfgPwaRQ1sxHM5sCstvWnfveHGtaCHOpPvsMbnYXJ nJMwq4s9G+KppKYPBiuCAy9w== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.34967004; Tue, 05 Nov 2013 11:56:35 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 5 Nov 2013 11:46:31 -0500 From: "Peterson, Jon" To: Michael Hammer , "aallen@blackberry.com" , "stir@ietf.org" Thread-Topic: [stir] comments on draft-ietf-stir-problem-statement-00 Thread-Index: Ac7QUSi+XuSwVM/UQPSEhXox+oZw/gJFOdUAABAW9ID//+tngP/+vPxggAJlnwA= Date: Tue, 5 Nov 2013 16:46:31 +0000 Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEF691A@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.128.72] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: LGpkpz3hgHUQtxOsaWUU4A== Content-Type: multipart/alternative; boundary="_000_CE9E5573AF9CBjonpetersonneustarbiz_" MIME-Version: 1.0 Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:47:47 -0000 --_000_CE9E5573AF9CBjonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I can see in principle how it might seem to make little difference if we we= re to replace mentions of any vendor(s) with a description of services whic= h have this property, which have been deployed to hundreds of millions of e= ndpoints, and which establish that an out-of-band identity system is possib= le. Maybe that is where we ultimately need to go here. I'll have a slide to= discuss this today. The problem is that the single paragraph of the problem-statement document = that references "that vendor" is part of a larger section called "Environme= ntal Changes," and the first sentence of that paragraph makes it clear we a= re talking about "shifts in the communications marketplace," not just techn= ical ideas that may or may not have been implemented or deployed. I maintai= n that specific existence proofs are necessary to explain why we are revisi= ting identity today. Or to put it differently, there have been arguments on= this list that an out-of-band identity system is simply not viable, a non-= starter, and removing obvious existence proof examples from the problem-sta= tement draft would seem to bolster those arguments at the cost of disconnec= ting our work from the reality of the marketplace. That's why I think refer= ences to actual deployed systems should remain. Regarding roaming, agreed that there are conceivable ways to work roaming i= nto the credential systems we're considering. I think we're a pretty long w= ay from considering transport-specific implications of this work. The only = points we need to capture here in the problem statement are the points abou= t authority, I think. Jon Peterson Neustar, Inc. From: Michael Hammer > Date: Tuesday, November 5, 2013 7:50 AM To: Jon Peterson = >, "aallen@blackberry.com" >, "stir@ietf.org" = > Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00 Jon, It would be possible to describe the salient features of any given service = without naming it. I think the principle proposed is to not denigrate nor promote any particul= ar vendor=92s implementation. One could argue that you will cross the line of misappropriating some vendo= r=92s IPR. Not sure if anyone has asked the vendor in question if they want to be name= d in an ID. Using IETF solutions and naming them is probably OK, since that is public. Concerning roaming service providers (carriers may have regulatory implicat= ions), visited system are given the crypto-credentials with which to authenticate = a user that can then make outbound calls from that visited system. It is certainly possible that additional credentials could be extended from= the home network to the visited one to use to authenticate the calling party to the called p= arty. That however would likely require some liaison with 3GPP to determine what attributes an= d functions should be supported in mobile network. Has the IETF considered what might be adopted into IMS, VoLTE and such? Mike From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Peterson, Jon Sent: Monday, November 04, 2013 6:26 PM To: Andrew Allen; stir@ietf.org Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 I don=92t think just the fact that some people happen to be familiar wi= th iMessage is sufficient justification to make it a good example to use in= the draft =96 particularly since it has short comings such as being curren= tly restricted to a single platform. I believe Whatsapp has the most user= =92s and also has multi vendor support. I suppose a list of e.g=92s is OK b= ut I don=92t see why we need to describe in any detail a specific service = =96 since most of them have similar characteristics. I think the fact that people are familiar with iMessage is a very good reas= on to list it as one example. I'm happy to include other examples, includin= g Whatsapp. I would also be happy to make the descriptive text there less s= pecific to any particular vendor, but I do have a hard time seeing how list= ing iMessage here would make people misunderstand the problem statement. [AA] My problem is with the statement =93domains that have no relationship = with the number assignee=94 Certainly they have a relationship =96 in fact = a close and trusted one and the home domain provides the number to assert t= o the roamed to domain. So I think it needs to be made clearer. Okay, per the text I sent in my last mail, we can make this clearer. Again,= what this means for STIR is that the the roaming carrier won't have the au= thority over the number. Jon Peterson Neustar, Inc. --_000_CE9E5573AF9CBjonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I can see in principle how it might seem to make little difference if = we were to replace mentions of any vendor(s) with a description of services= which have this property, which have been deployed to hundreds of millions= of endpoints, and which establish that an out-of-band identity system is possible. Maybe that is where we ul= timately need to go here. I'll have a slide to discuss this today. 

The problem is that the single paragraph of the problem-statement docu= ment that references "that vendor" is part of a larger section ca= lled "Environmental Changes," and the first sentence of that para= graph makes it clear we are talking about "shifts in the communications marketplace," not just technical ideas that may or= may not have been implemented or deployed. I maintain that specific existe= nce proofs are necessary to explain why we are revisiting identity today. O= r to put it differently, there have been arguments on this list that an out-of-band identity system is simply not v= iable, a non-starter, and removing obvious existence proof examples from th= e problem-statement draft would seem to bolster those arguments at the cost= of disconnecting our work from the reality of the marketplace. That's why I think references to actual de= ployed systems should remain.

Regarding roaming, agreed that there are conceivable ways to work roam= ing into the credential systems we're considering. I think we're a pretty l= ong way from considering transport-specific implications of this work. The = only points we need to capture here in the problem statement are the points about authority, I think.

Jon Peterson
Neustar, Inc.

From: Michael Hammer <michael.hammer@yaanatech.com><= br> Date: Tuesday, November 5, 2013 7:5= 0 AM
To: Jon Peterson <jon.peterson@neustar.biz>, "aallen@blackberry.com" <aallen@blackberry.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] comments on dra= ft-ietf-stir-problem-statement-00

Jon,=

 

It would be possible t= o describe the salient features of any given service without naming it.

I think the principle = proposed is to not denigrate nor promote any particular vendor=92s implemen= tation.

One could argue that y= ou will cross the line of misappropriating some vendor=92s IPR.<= /span>

Not sure if anyone has= asked the vendor in question if they want to be named in an ID.=

Using IETF solutions a= nd naming them is probably OK, since that is public.

 

Concerning roaming ser= vice providers (carriers may have regulatory implications),

visited system are giv= en the crypto-credentials with which to authenticate a user

that can then make out= bound calls from that visited system. 

 

It is certainly possib= le that additional credentials could be extended from the home network

to the visited one to = use to authenticate the calling party to the called party.  That howev= er

would likely require s= ome liaison with 3GPP to determine what attributes and functions

should be supported in= mobile network. 

Has the IETF considere= d what might be adopted into IMS, VoLTE and such?

 

Mike=

 

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Monday, November 04, 2013 6:26 PM
To: Andrew Allen; stir@ietf.org=
Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00=

 

<AA>I don=92t th= ink just the fact that some people happen to be familiar with iMessage is s= ufficient justification to make it a good example to use in the draft =96 p= articularly since it has short comings such as being currently restricted to a single platform. I believe Whatsapp has th= e most user=92s and also has multi vendor support. I suppose a list of e.g= =92s is OK but I don=92t see why we need to describe in any detail a specif= ic service =96 since most of them have similar characteristics.</AA>

 

I think the fact that people are famil= iar with iMessage is a very good reason to list it as one example. I'm happ= y to include other examples, including Whatsapp. I would also be happy to make the descriptive text there less sp= ecific to any particular vendor, but I do have a hard time seeing how listi= ng iMessage here would make people misunderstand the problem statement.

 

[AA] My problem is with the statemen= t =93domains that have no relationshi= p with the number assignee=94 Certainly they have a relationship= =96 in fact a close and trusted one and the home domain provides the numbe= r to assert to the roamed to domain.  So I think it needs to be made c= learer.

 

Okay, per the text I sent in my last mail, we can ma= ke this clearer. Again, what this means for STIR is that the the roaming ca= rrier won't have the authority over the number. 

 

Jon Peterson

Neustar, Inc.

&n= bsp;

 --_000_CE9E5573AF9CBjonpetersonneustarbiz_-- From richard@shockey.us Tue Nov 5 08:49:26 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53A011E81B4 for ; Tue, 5 Nov 2013 08:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.964 X-Spam-Level: X-Spam-Status: No, score=-101.964 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdwHlALmSkwH for ; Tue, 5 Nov 2013 08:49:16 -0800 (PST) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 7F5B111E81BB for ; Tue, 5 Nov 2013 08:49:16 -0800 (PST) Received: (qmail 22292 invoked by uid 0); 5 Nov 2013 16:48:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.mail.unifiedlayer.com with SMTP; 5 Nov 2013 16:48:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=6Krz3Xxsn2OeHP8EfNitwlu0Tskkk4WDkz5+DwyisvQ=; b=jvVyh2dms1q54HHQc2Oa1QbfrOXPjPPrXoLS1dN3IKozYqm9ZguM46ECIH7Gv164IssUqeOC3We/fbmpnehmXjc4YFxzmZmjGa93VwfFBXoGd/xpNsjSVDtxqxF8fUpb; Received: from [173.79.179.104] (port=53456 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VdjoE-0003Ls-Ly; Tue, 05 Nov 2013 09:48:55 -0700 From: "Richard Shockey" To: "'Andrew Allen'" , "'Peterson, Jon'" , References: <596979554D802045BBD45C051A4399E40D40A87A@STNTEXMB10.cis.neustar.com> In-Reply-To: Date: Tue, 5 Nov 2013 11:48:54 -0500 Message-ID: <019201ceda46$ea2f7e30$be8e7a90$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0193_01CEDA1D.015E0A10" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHJ25qBxOpRY5sK5i6/LfwKVYDGEwI1pNzGmg8pauA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:49:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0193_01CEDA1D.015E0A10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 Excellent +1=20 =20 From: Andrew Allen [mailto:aallen@blackberry.com]=20 Sent: Tuesday, November 05, 2013 11:45 AM To: Peterson, Jon; 'Richard Shockey'; 'stir@ietf.org' Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00 =20 =20 Jon =20 I have not used iMessage so using it as an example doesn=E2=80=99t help = me or the large community of non iPhone users out there to understand. I = have however used WhatsApp, BlackBerry Messenger and Viber =E2=80=93 all = of which are very popular messaging services. WeChat is another = messaging services that is also extremely popular in China and many = other Asian countries. =20 I don=E2=80=99t see anything special about iMessage =E2=80=93 other = services have more users, have multi-platform support or have been = around long before iPhone was a gleam in the Steve Jobs=E2=80=99 eye and = all provide an out of band connection. =20 My proposal is to rewrite the text as follows: =20 =20 For example, the Apple iMessage service, which allows iPhone users to = send SMS messages to one another over the Internet rather than over the = PSTN. Like VIPR, iMessage creates an out-of-band connection over the = Internet between iPhones; unlike VIPR, the rendezvous service is = provided by a trusted centralized database of iPhones rather than by a = DHT. While Apple's service is specific to customers of its smart = phones, it seems clear that similar databases could be provided by = neutral third parties in a position to coordinate between endpoints. =20 REWRITE AS: =20 Mobile messaging services, (e.g. Whatsapp, Viber, BlackBerry Messenger, = Apple=E2=80=99s iMessage and WeChat), allow smart phone users to send = text messages to one another over the Internet rather than over the = PSTN. Like VIPR, such services create an out-of-band connection over = the Internet between smart phones; unlike VIPR, the rendezvous service = is provided by a trusted centralized database rather than by a DHT. = While such messaging services are specific to the users of the specific = service, it seems clear that similar databases could be provided by = neutral third parties in a position to coordinate between endpoints. =20 =20 Andrew =20 From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 Sent: Monday, November 04, 2013 9:20 PM To: 'Richard Shockey'; Andrew Allen; 'stir@ietf.org' Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00 =20 Well. Maybe I understood Andrew's message a bit differently than you = did. What he originally asked was that services like Blackberry = Messenger (also an out-of-band service like iMessage) be included so we = don't appear to be favoring the work of a single monolithic vendor. He = then asked that we reference something like Whatsapp, a platform-neutral = service along these lines. I haven't objected to either of those = requests. But the suggestion that we restrict this section to some other = vendor's solution while removing the one with which people trying to = understand the problem are most familiar would, I think, be a different = matter. The objective of this document is not to promote any solution, it's a = problem statement document. Whatever we reference here is entirely = exemplary and explicitly not a component of the STIR solution. While we = can all see the vehemence of your personal objection, I am not seeing = any rational reason here to strike information from the document that = actually helps people to understand what this work is about. Nor do I = think your curious construal of Andrew's (actually quite reasonable) = request, when combined with your own more obscure complaint, justifies = issuing blanket commands as you do below. Why don't we leave it to the = chairs to assess consensus. Jon Peterson Neustar, Inc. Sent with Good (www.good.com ) -----Original Message----- From: Richard Shockey [richard@shockey.us ] Sent: Monday, November 04, 2013 08:27 PM Eastern Standard Time To: Peterson, Jon; 'Andrew Allen'; stir@ietf.org =20 Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00 Jon .. what about NO don=E2=80=99t you understand.=20 =20 We object to the references. Remove them now. =20 From: stir-bounces@ietf.org = [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Monday, November 04, 2013 6:26 PM To: Andrew Allen; stir@ietf.org =20 Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 =20 I don=E2=80=99t think just the fact that some people happen to be = familiar with iMessage is sufficient justification to make it a good = example to use in the draft =E2=80=93 particularly since it has short = comings such as being currently restricted to a single platform. I = believe Whatsapp has the most user=E2=80=99s and also has multi vendor = support. I suppose a list of e.g=E2=80=99s is OK but I don=E2=80=99t see = why we need to describe in any detail a specific service =E2=80=93 since = most of them have similar characteristics. =20 I think the fact that people are familiar with iMessage is a very good = reason to list it as one example. I'm happy to include other examples, = including Whatsapp. I would also be happy to make the descriptive text = there less specific to any particular vendor, but I do have a hard time = seeing how listing iMessage here would make people misunderstand the = problem statement. =20 [AA] My problem is with the statement =E2=80=9Cdomains that have no = relationship with the number assignee=E2=80=9D Certainly they have a = relationship =E2=80=93 in fact a close and trusted one and the home = domain provides the number to assert to the roamed to domain. So I = think it needs to be made clearer. =20 =20 Okay, per the text I sent in my last mail, we can make this clearer. = Again, what this means for STIR is that the the roaming carrier won't = have the authority over the number.=20 =20 Jon Peterson Neustar, Inc. =20 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. ------=_NextPart_000_0193_01CEDA1D.015E0A10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

Excellent +1 =

 

From: Andrew Allen = [mailto:aallen@blackberry.com]
Sent: Tuesday, November 05, = 2013 11:45 AM
To: Peterson, Jon; 'Richard Shockey'; = 'stir@ietf.org'
Subject: RE: [stir] comments on = draft-ietf-stir-problem-statement-00

 

 

Jon

 

I have not used iMessage = so using it as an example doesn=E2=80=99t help me or the large community = of non iPhone users out there to understand. I have however used = WhatsApp, BlackBerry Messenger and Viber =E2=80=93 all of which are very = popular messaging services. WeChat is another messaging services that is = also extremely popular in China and many other Asian = countries.

 

I don=E2=80=99t see = anything special about iMessage =E2=80=93 other services have more = users, have multi-platform support or have been around long before = iPhone was a gleam in the Steve Jobs=E2=80=99 eye and all provide an out = of band connection.

 

My proposal is to = rewrite the text as follows:

 

 

For example, the Apple iMessage service, which allows = iPhone users to send SMS messages to one another over the Internet = rather than over the PSTN.  Like VIPR, iMessage creates an = out-of-band connection over the Internet between iPhones; unlike VIPR, = the rendezvous service is provided by a trusted centralized database of = iPhones rather than by a DHT.  While Apple's service is specific to = customers of its smart phones, it seems clear that similar databases = could be provided by neutral third parties in a position to coordinate = between endpoints.

 

REWRITE = AS:

 

Mobile messaging services, (e.g. Whatsapp, Viber, = BlackBerry Messenger, Apple=E2=80=99s iMessage and WeChat), allow smart = phone users to send text messages to one another over the Internet = rather than over the PSTN.  Like VIPR, such services create an = out-of-band connection over the Internet between smart phones; unlike = VIPR, the rendezvous service is provided by a trusted centralized = database rather than by a DHT.  While such messaging services are = specific to the users of the specific service, it seems clear that = similar databases could be provided by neutral third parties in a = position to coordinate between endpoints.

 

 

Andrew

 

 

Well. = Maybe I understood Andrew's message a bit differently than you did. What = he originally asked was that services like Blackberry Messenger (also an = out-of-band service like iMessage) be included so we don't appear to be = favoring the work of a single monolithic vendor. He then asked that we = reference something like Whatsapp, a platform-neutral service along = these lines. I haven't objected to either of those requests. But the = suggestion that we restrict this section to some other vendor's solution = while removing the one with which people trying to understand the = problem are most familiar would, I think, be a different = matter.

The objective of this document is not to promote any = solution, it's a problem statement document. Whatever we reference here = is entirely exemplary and explicitly not a component of the STIR = solution. While we can all see the vehemence of your personal objection, = I am not seeing any rational reason here to strike information from the = document that actually helps people to understand what this work is = about. Nor do I think your curious construal of Andrew's (actually quite = reasonable) request, when combined with your own more obscure complaint, = justifies issuing blanket commands as you do below. Why don't we leave = it to the chairs to assess consensus.

Jon Peterson
Neustar, = Inc.



Sent with Good (www.good.com)


-----Original = Message-----
From: Richard Shockey [richard@shockey.us]
Sent:&nb= sp;Monday, November 04, 2013 08:27 PM Eastern Standard = Time
To: Peterson, Jon; 'Andrew Allen'; stir@ietf.org
Subject: R= E: [stir] comments on = draft-ietf-stir-problem-statement-00

Jon .. what about NO = don=E2=80=99t you understand. 

 

We object to the = references. Remove them now.

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On Behalf Of Peterson, Jon
Sent: Monday, November 04, = 2013 6:26 PM
To: Andrew Allen; stir@ietf.org
Subject: Re: = [stir] comments on = draft-ietf-stir-problem-statement-00

 

<AA>I don=E2=80=99t think just the fact = that some people happen to be familiar with iMessage is sufficient = justification to make it a good example to use in the draft =E2=80=93 = particularly since it has short comings such as being currently = restricted to a single platform. I believe Whatsapp has the most = user=E2=80=99s and also has multi vendor support. I suppose a list of = e.g=E2=80=99s is OK but I don=E2=80=99t see why we need to describe in = any detail a specific service =E2=80=93 since most of them have similar = characteristics.</AA>

 

I think the fact that people are familiar with = iMessage is a very good reason to list it as one example. I'm happy to = include other examples, including Whatsapp. I would also be happy to = make the descriptive text there less specific to any particular vendor, = but I do have a hard time seeing how listing iMessage here would make = people misunderstand the problem = statement.

 

[AA] My problem is with the statement = =E2=80=9Cdomains that have no = relationship with the number assignee=E2=80=9D Certainly they have a relationship =E2=80=93 in = fact a close and trusted one and the home domain provides the number to = assert to the roamed to domain.  So I think it needs to be made = clearer.

 

Okay, per the text I sent in my last mail, we can make = this clearer. Again, what this means for STIR is that the the roaming = carrier won't have the authority over the = number. 

 

Jon Peterson

Neustar, Inc.

 

=

---------------------------------------------------------= ------------
This transmission (including any attachments) may = contain confidential information, privileged material (including = material protected by the solicitor-client or other applicable = privileges), or constitute non-public information. Any use of this = information by anyone other than the intended recipient is prohibited. = If you have received this transmission in error, please immediately = reply to the sender and delete this information from your system. Use, = dissemination, distribution, or reproduction of this transmission by = unintended recipients is not authorized and may be = unlawful.

------=_NextPart_000_0193_01CEDA1D.015E0A10-- From jon.peterson@neustar.biz Tue Nov 5 08:49:38 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB5411E81DC for ; Tue, 5 Nov 2013 08:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.02 X-Spam-Level: X-Spam-Status: No, score=-106.02 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAFhcTSqHQTP for ; Tue, 5 Nov 2013 08:49:34 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id DE19D11E81F3 for ; Tue, 5 Nov 2013 08:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383670773; x=1699025526; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=5btSd0WAbO6t2rVYIJkiDSLR/xIPqBQbEL4JELO1Vig=; b=VJ/rOQpDoMFgfZuBRIdDP3QMSO2VS2sRzysmtbeK48HWmPLM/+sM3d3L+3zV2+ 0VgN3yb1H7Qy03qOKUbM1jzQ== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.34967223; Tue, 05 Nov 2013 11:59:32 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 5 Nov 2013 11:49:25 -0500 From: "Peterson, Jon" To: Andrew Allen , 'Richard Shockey' , "'stir@ietf.org'" Thread-Topic: [stir] comments on draft-ietf-stir-problem-statement-00 Thread-Index: Ac7QUSi+XuSwVM/UQPSEhXox+oZw/gJFOdUAABAW9ID//+tngIAAp9QAgABE4kf//50YUIAAmZuA Date: Tue, 5 Nov 2013 16:49:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.128.72] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 3GoWl09MVSo/9UhvhfLsOg== Content-Type: multipart/alternative; boundary="_000_CE9E6104AFA96jonpetersonneustarbiz_" MIME-Version: 1.0 Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:49:38 -0000 --_000_CE9E6104AFA96jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sure, something along these lines would be fine. I would want to restrict t= he list to services that operate on telephone numbers and have the property= that they deliver the originating telephone number to the destination alon= g with the message, and that this attestation has some basis in reality. Do= all those services have that property? Jon Peterson Neustar, Inc. From: Andrew Allen > Date: Tuesday, November 5, 2013 8:44 AM To: Jon Peterson = >, Richard Shockey >, "'stir@= ietf.org'" > Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00 Jon I have not used iMessage so using it as an example doesn=92t help me or the= large community of non iPhone users out there to understand. I have howeve= r used WhatsApp, BlackBerry Messenger and Viber =96 all of which are very p= opular messaging services. WeChat is another messaging services that is als= o extremely popular in China and many other Asian countries. I don=92t see anything special about iMessage =96 other services have more = users, have multi-platform support or have been around long before iPhone w= as a gleam in the Steve Jobs=92 eye and all provide an out of band connecti= on. My proposal is to rewrite the text as follows: For example, the Apple iMessage service, which allows iPhone users to send = SMS messages to one another over the Internet rather than over the PSTN. L= ike VIPR, iMessage creates an out-of-band connection over the Internet betw= een iPhones; unlike VIPR, the rendezvous service is provided by a trusted c= entralized database of iPhones rather than by a DHT. While Apple's service= is specific to customers of its smart phones, it seems clear that similar = databases could be provided by neutral third parties in a position to coord= inate between endpoints. REWRITE AS: Mobile messaging services, (e.g. Whatsapp, Viber, BlackBerry Messenger, App= le=92s iMessage and WeChat), allow smart phone users to send text messages = to one another over the Internet rather than over the PSTN. Like VIPR, suc= h services create an out-of-band connection over the Internet between smart= phones; unlike VIPR, the rendezvous service is provided by a trusted centr= alized database rather than by a DHT. While such messaging services are sp= ecific to the users of the specific service, it seems clear that similar da= tabases could be provided by neutral third parties in a position to coordin= ate between endpoints. Andrew From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Monday, November 04, 2013 9:20 PM To: 'Richard Shockey'; Andrew Allen; 'stir@ietf.org' Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00 Well. Maybe I understood Andrew's message a bit differently than you did. W= hat he originally asked was that services like Blackberry Messenger (also a= n out-of-band service like iMessage) be included so we don't appear to be f= avoring the work of a single monolithic vendor. He then asked that we refer= ence something like Whatsapp, a platform-neutral service along these lines.= I haven't objected to either of those requests. But the suggestion that we= restrict this section to some other vendor's solution while removing the o= ne with which people trying to understand the problem are most familiar wou= ld, I think, be a different matter. The objective of this document is not to promote any solution, it's a probl= em statement document. Whatever we reference here is entirely exemplary and= explicitly not a component of the STIR solution. While we can all see the = vehemence of your personal objection, I am not seeing any rational reason h= ere to strike information from the document that actually helps people to u= nderstand what this work is about. Nor do I think your curious construal of= Andrew's (actually quite reasonable) request, when combined with your own = more obscure complaint, justifies issuing blanket commands as you do below.= Why don't we leave it to the chairs to assess consensus. Jon Peterson Neustar, Inc. Sent with Good (www.good.com) -----Original Message----- From: Richard Shockey [richard@shockey.us] Sent: Monday, November 04, 2013 08:27 PM Eastern Standard Time To: Peterson, Jon; 'Andrew Allen'; stir@ietf.org Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00 Jon .. what about NO don=92t you understand. We object to the references. Remove them now. From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Peterson, Jon Sent: Monday, November 04, 2013 6:26 PM To: Andrew Allen; stir@ietf.org Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 I don=92t think just the fact that some people happen to be familiar wi= th iMessage is sufficient justification to make it a good example to use in= the draft =96 particularly since it has short comings such as being curren= tly restricted to a single platform. I believe Whatsapp has the most user= =92s and also has multi vendor support. I suppose a list of e.g=92s is OK b= ut I don=92t see why we need to describe in any detail a specific service = =96 since most of them have similar characteristics. I think the fact that people are familiar with iMessage is a very good reas= on to list it as one example. I'm happy to include other examples, includin= g Whatsapp. I would also be happy to make the descriptive text there less s= pecific to any particular vendor, but I do have a hard time seeing how list= ing iMessage here would make people misunderstand the problem statement. [AA] My problem is with the statement =93domains that have no relationship = with the number assignee=94Certainly they have a relationship =96 in fact a= close and trusted one and the home domain provides the number to assert to= the roamed to domain. So I think it needs to be made clearer. Okay, per the text I sent in my last mail, we can make this clearer. Again,= what this means for STIR is that the the roaming carrier won't have the au= thority over the number. Jon Peterson Neustar, Inc. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_CE9E6104AFA96jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Sure, something along these lines would be fine. I would want to restr= ict the list to services that operate on telephone numbers and have the pro= perty that they deliver the originating telephone number to the destination= along with the message, and that this attestation has some basis in reality. Do all those services have tha= t property?

Jon Peterson
Neustar, Inc.

From: Andrew Allen <aallen@blackberry.com>
Date: Tuesday, November 5, 2013 8:4= 4 AM
To: Jon Peterson <jon.peterson@neustar.biz>, Richard Sho= ckey <richard@shockey.us>, = "'stir@ietf.org'" <stir@ietf.org>
Subject: RE: [stir] comments on dra= ft-ietf-stir-problem-statement-00

 

Jon<= /p>

 

I have not used iMessa= ge so using it as an example doesn=92t help me or the large community of no= n iPhone users out there to understand. I have however used WhatsApp, Black= Berry Messenger and Viber =96 all of which are very popular messaging services. WeChat is another messaging services = that is also extremely popular in China and many other Asian countries.

 

I don=92t see anything= special about iMessage =96 other services have more users, have multi-plat= form support or have been around long before iPhone was a gleam in the Stev= e Jobs=92 eye and all provide an out of band connection.

 

My proposal is to rewr= ite the text as follows:

 

 

For example, the Apple iMessage service, which allows iPhone user= s to send SMS messages to one another over the Internet rather than over th= e PSTN.  Like VIPR, iMessage creates an out-of-band connection over the Internet between iPhones; unlike VIPR, = the rendezvous service is provided by a trusted centralized database of iPh= ones rather than by a DHT.  While Apple's service is specific to custo= mers of its smart phones, it seems clear that similar databases could be provided by neutral third parties in a pos= ition to coordinate between endpoints.

 

REWRITE AS:=

 

Mobile messaging services, (e.g. Whatsapp, Viber, BlackBerry Mess= enger, Apple=92s iMessage and WeChat), allow smart phone users to send text= messages to one another over the Internet rather than over the PSTN.  Like VIPR, such services create an out-of= -band connection over the Internet between smart phones; unlike VIPR, the r= endezvous service is provided by a trusted centralized database rather than= by a DHT.  While such messaging services are specific to the users of the specific service, it seems clear that sim= ilar databases could be provided by neutral third parties in a position to = coordinate between endpoints.

 

 

Andrew

 

From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: Monday, November 04, 2013 9:20 PM
To: 'Richard Shockey'; Andrew Allen; 'stir@ietf.org'
Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00=

 

Well. Maybe I understood Andrew's message a bit differ= ently than you did. What he originally asked was that services like Blackbe= rry Messenger (also an out-of-band service like iMessage) be included so we don't appear to be favoring the work of a= single monolithic vendor. He then asked that we reference something like W= hatsapp, a platform-neutral service along these lines. I haven't objected t= o either of those requests. But the suggestion that we restrict this section to some other vendor's soluti= on while removing the one with which people trying to understand the proble= m are most familiar would, I think, be a different matter.

The objective of this document is not to promote any solution, it's a probl= em statement document. Whatever we reference here is entirely exemplary and= explicitly not a component of the STIR solution. While we can all see the = vehemence of your personal objection, I am not seeing any rational reason here to strike information from the do= cument that actually helps people to understand what this work is about. No= r do I think your curious construal of Andrew's (actually quite reasonable)= request, when combined with your own more obscure complaint, justifies issuing blanket commands as you do b= elow. Why don't we leave it to the chairs to assess consensus.

Jon Peterson
Neustar, Inc.



Sent with Good (www.good.com)


-----Original Message-----
From: Richard Shockey [ri= chard@shockey.us]
Sent: Monday, November 04, 2013 08:27 PM Eastern Standard Time<= br> To: Peterson, Jon; 'Andrew Allen'; stir@ietf.org
Subject: RE: [stir] comments on draft-ietf-stir-problem-stateme= nt-00


Jon .. what about NO d= on=92t you understand. 

 

We object to the refer= ences. Remove them now.

 

From: stir-bounces@ietf.org [mailt= o:stir-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Monday, November 04, 2013 6:26 PM
To: Andrew Allen; stir@ietf.org=
Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00=

 

<AA>I don=92t th= ink just the fact that some people happen to be familiar with iMessage is s= ufficient justification to make it a good example to use in the draft =96 p= articularly since it has short comings such as being currently restricted to a single platform. I believe Whatsapp has th= e most user=92s and also has multi vendor support. I suppose a list of e.g= =92s is OK but I don=92t see why we need to describe in any detail a specif= ic service =96 since most of them have similar characteristics.</AA>

 

I think the fact that people are famil= iar with iMessage is a very good reason to list it as one example. I'm happ= y to include other examples, including Whatsapp. I would also be happy to make the descriptive text there less sp= ecific to any particular vendor, but I do have a hard time seeing how listi= ng iMessage here would make people misunderstand the problem statement.

 

[AA] My problem is with the statemen= t =93domains that have no relationshi= p with the number assignee=94Certa= inly they have a relationship =96 in fact a close and trusted one and the home = domain provides the number to assert to the roamed to domain.  So I th= ink it needs to be made clearer.

 

Okay, per the text I sent in my last mail, we can ma= ke this clearer. Again, what this means for STIR is that the the roaming ca= rrier won't have the authority over the number. 

 

Jon Peterson

Neustar, Inc.

 <= /span>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
 --_000_CE9E6104AFA96jonpetersonneustarbiz_-- From br@brianrosen.net Tue Nov 5 10:04:30 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7220521E8183 for ; Tue, 5 Nov 2013 10:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuvTS1c1piT3 for ; Tue, 5 Nov 2013 10:04:26 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id E5C6611E81F8 for ; Tue, 5 Nov 2013 10:03:36 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id x12so5056565qcv.28 for ; Tue, 05 Nov 2013 10:03:20 -0800 (PST) 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:message-id:references:to; bh=y2+MPqZnzqA3+lgYW9zBTVlDLwuyYiuYyqklh9tP8aU=; b=QlJmbA2HbxZViINGD12VQ0lrUBcTqd4pK8fVgEbQTVgmyXZv1F3T1OoYjRGmmyP4RC VLMAva1o9Od8kVYGM8HcnvUE8REAM7VCgeW1Q1hHbNh4/Y6I0axkdtqxWhY5qzu+b6Wq VFH6jng96iOdN1KsdmhGR3hSbvyxXFi2oWkcVhgvDDAXOuCKbIDOnW24Jjt+oPP4xfm8 STzPKBMimesqdB+LjDYnaq7ehk9Wmm7KW8nSClrrD+4Rf9n6PT5vNwbhEjJZBy2E0Mde DbcEdozsL4sp2c7Bw8fR4gS5DnOeDP08H9CcjhMVifHmY4MA8UPx1hMoSCDiUwzAE0gT 9p7Q== X-Gm-Message-State: ALoCoQlvbxqjwoK4yJT/JwqKjhIivfx9ZMkVU6pOkX3RbSHWkkVLsrTxOLjiFIN/XqqFf/8khPgh X-Received: by 10.49.59.115 with SMTP id y19mr31130295qeq.8.1383674600329; Tue, 05 Nov 2013 10:03:20 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:bc29:f526:2fd0:9b70]) by mx.google.com with ESMTPSA id u3sm60930918qej.8.2013.11.05.10.03.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 10:03:19 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_50B9458E-9343-4753-ABFC-145C7F199851" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: Date: Tue, 5 Nov 2013 10:03:06 -0800 Message-Id: References: To: Jon Peterson X-Mailer: Apple Mail (2.1816) Cc: "stir@ietf.org" , Andrew Allen , Richard Shockey Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:04:30 -0000 --Apple-Mail=_50B9458E-9343-4753-ABFC-145C7F199851 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I believe they all do. FWIW, the most interesting aspect of what happened with iMessage is that = the iOS Messages app that used to be a strictly SMS interface was = upgraded, with roughly no change to the UI, to use IP rather than PSTN, = seamlessly, by one vendor. As Jon points out, the identity (the TN) did = not change, but the protocol and the trust anchor changed. The other examples Andrew cites were always OTT apps which piggy-back on = the TN as a unique identifier. Some of them just assume you own the TN, = some of them use an SMS verification message to prove you do. That said,I=92m happy with Andrews proposed edits. Brian On Nov 5, 2013, at 8:49 AM, Peterson, Jon = wrote: >=20 > Sure, something along these lines would be fine. I would want to = restrict the list to services that operate on telephone numbers and have = the property that they deliver the originating telephone number to the = destination along with the message, and that this attestation has some = basis in reality. Do all those services have that property? >=20 > Jon Peterson > Neustar, Inc. >=20 > From: Andrew Allen > Date: Tuesday, November 5, 2013 8:44 AM > To: Jon Peterson , Richard Shockey = , "'stir@ietf.org'" > Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00 >=20 > =20 > Jon > =20 > I have not used iMessage so using it as an example doesn=92t help me = or the large community of non iPhone users out there to understand. I = have however used WhatsApp, BlackBerry Messenger and Viber =96 all of = which are very popular messaging services. WeChat is another messaging = services that is also extremely popular in China and many other Asian = countries. > =20 > I don=92t see anything special about iMessage =96 other services have = more users, have multi-platform support or have been around long before = iPhone was a gleam in the Steve Jobs=92 eye and all provide an out of = band connection. > =20 > My proposal is to rewrite the text as follows: > =20 > =20 > For example, the Apple iMessage service, which allows iPhone users to = send SMS messages to one another over the Internet rather than over the = PSTN. Like VIPR, iMessage creates an out-of-band connection over the = Internet between iPhones; unlike VIPR, the rendezvous service is = provided by a trusted centralized database of iPhones rather than by a = DHT. While Apple's service is specific to customers of its smart = phones, it seems clear that similar databases could be provided by = neutral third parties in a position to coordinate between endpoints. > =20 > REWRITE AS: > =20 > Mobile messaging services, (e.g. Whatsapp, Viber, BlackBerry = Messenger, Apple=92s iMessage and WeChat), allow smart phone users to = send text messages to one another over the Internet rather than over the = PSTN. Like VIPR, such services create an out-of-band connection over = the Internet between smart phones; unlike VIPR, the rendezvous service = is provided by a trusted centralized database rather than by a DHT. = While such messaging services are specific to the users of the specific = service, it seems clear that similar databases could be provided by = neutral third parties in a position to coordinate between endpoints. > =20 > =20 > Andrew > =20 > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > Sent: Monday, November 04, 2013 9:20 PM > To: 'Richard Shockey'; Andrew Allen; 'stir@ietf.org' > Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00 > =20 > Well. Maybe I understood Andrew's message a bit differently than you = did. What he originally asked was that services like Blackberry = Messenger (also an out-of-band service like iMessage) be included so we = don't appear to be favoring the work of a single monolithic vendor. He = then asked that we reference something like Whatsapp, a platform-neutral = service along these lines. I haven't objected to either of those = requests. But the suggestion that we restrict this section to some other = vendor's solution while removing the one with which people trying to = understand the problem are most familiar would, I think, be a different = matter. >=20 > The objective of this document is not to promote any solution, it's a = problem statement document. Whatever we reference here is entirely = exemplary and explicitly not a component of the STIR solution. While we = can all see the vehemence of your personal objection, I am not seeing = any rational reason here to strike information from the document that = actually helps people to understand what this work is about. Nor do I = think your curious construal of Andrew's (actually quite reasonable) = request, when combined with your own more obscure complaint, justifies = issuing blanket commands as you do below. Why don't we leave it to the = chairs to assess consensus. >=20 > Jon Peterson > Neustar, Inc. >=20 >=20 >=20 > Sent with Good (www.good.com) >=20 >=20 > -----Original Message----- > From: Richard Shockey [richard@shockey.us] > Sent: Monday, November 04, 2013 08:27 PM Eastern Standard Time > To: Peterson, Jon; 'Andrew Allen'; stir@ietf.org > Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00 >=20 >=20 > Jon .. what about NO don=92t you understand.=20 > =20 > We object to the references. Remove them now. > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Peterson, Jon > Sent: Monday, November 04, 2013 6:26 PM > To: Andrew Allen; stir@ietf.org > Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 > =20 > I don=92t think just the fact that some people happen to be = familiar with iMessage is sufficient justification to make it a good = example to use in the draft =96 particularly since it has short comings = such as being currently restricted to a single platform. I believe = Whatsapp has the most user=92s and also has multi vendor support. I = suppose a list of e.g=92s is OK but I don=92t see why we need to = describe in any detail a specific service =96 since most of them have = similar characteristics. > =20 > I think the fact that people are familiar with iMessage is a very good = reason to list it as one example. I'm happy to include other examples, = including Whatsapp. I would also be happy to make the descriptive text = there less specific to any particular vendor, but I do have a hard time = seeing how listing iMessage here would make people misunderstand the = problem statement. > =20 > [AA] My problem is with the statement =93domains that have no = relationship with the number assignee=94Certainly they have a = relationship =96 in fact a close and trusted one and the home domain = provides the number to assert to the roamed to domain. So I think it = needs to be made clearer. > =20 > =20 > Okay, per the text I sent in my last mail, we can make this clearer. = Again, what this means for STIR is that the the roaming carrier won't = have the authority over the number.=20 > =20 > Jon Peterson > Neustar, Inc. > =20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_50B9458E-9343-4753-ABFC-145C7F199851 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = believe they all do.

FWIW, the most interesting = aspect of what happened with iMessage is that the iOS Messages app that = used to be a strictly SMS interface was upgraded, with roughly no change = to the UI, to use IP rather than PSTN, seamlessly, by one vendor. =  As Jon points out, the identity (the TN) did not change, but the = protocol and the trust anchor changed.

The = other examples Andrew cites were always OTT apps which piggy-back on the = TN as a unique identifier.  Some of them just assume you own the = TN, some of them use an SMS verification message to prove you = do.

That said,I=92m happy with Andrews proposed = edits.

Brian

On Nov 5, = 2013, at 8:49 AM, Peterson, Jon <jon.peterson@neustar.biz> = wrote:


Sure, something along these lines = would be fine. I would want to restrict the list to services that = operate on telephone numbers and have the property that they deliver the = originating telephone number to the destination along with the message, = and that this attestation has some basis in reality. Do all those = services have that property?

Jon Peterson
Neustar, = Inc.

From: Andrew Allen <aallen@blackberry.com>
Date: Tuesday, November 5, = 2013 8:44 AM
To: Jon Peterson <jon.peterson@neustar.biz>, Richard = Shockey <richard@shockey.us>, "'stir@ietf.org'" <stir@ietf.org>
Subject: RE: [stir] comments = on draft-ietf-stir-problem-statement-00

 
Jon
 
I have not used iMessage so using it = as an example doesn=92t help me or the large community of non iPhone = users out there to understand. I have however used WhatsApp, BlackBerry = Messenger and Viber =96 all of which are very popular messaging = services. WeChat is another messaging services that is also extremely = popular in China and many other Asian = countries.
 
I don=92t = see anything special about iMessage =96 other services have more users, = have multi-platform support or have been around long before iPhone was a = gleam in the Steve Jobs=92 eye and all provide an out of band = connection.
 
My = proposal is to rewrite the text as follows:
 
 
For example, the Apple iMessage service, which allows = iPhone users to send SMS messages to one another over the Internet = rather than over the PSTN.  Like VIPR, iMessage creates an = out-of-band connection over the Internet between iPhones; unlike VIPR, = the rendezvous service is provided by a trusted centralized database of = iPhones rather than by a DHT.  While Apple's service is specific to = customers of its smart phones, it seems clear that similar databases = could be provided by neutral third parties in a position to coordinate = between endpoints.
 
REWRITE = AS:
 
Mobile messaging services, (e.g. Whatsapp, Viber, BlackBerry = Messenger, Apple=92s iMessage and WeChat), allow smart phone users to = send text messages to one another over the Internet rather than over the = PSTN.  Like VIPR, such services create an out-of-band connection = over the Internet between smart phones; unlike VIPR, the rendezvous = service is provided by a trusted centralized database rather than by a = DHT.  While such messaging services are specific to the users of = the specific service, it seems clear that similar databases could be = provided by neutral third parties in a position to coordinate between = endpoints.
 
 
Andrew
 
From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
Sent: Monday, November 04, 2013 = 9:20 PM
To: 'Richard Shockey'; Andrew = Allen; 'stir@ietf.org'
Subject: RE: [stir] comments on = draft-ietf-stir-problem-statement-00
 
Well. = Maybe I understood Andrew's message a bit differently than you did. What = he originally asked was that services like Blackberry Messenger (also an = out-of-band service like iMessage) be included so we don't appear to be = favoring the work of a single monolithic vendor. He then asked that we = reference something like Whatsapp, a platform-neutral service along = these lines. I haven't objected to either of those requests. But the = suggestion that we restrict this section to some other vendor's solution = while removing the one with which people trying to understand the = problem are most familiar would, I think, be a different = matter.

The objective of this document is not to promote any = solution, it's a problem statement document. Whatever we reference here = is entirely exemplary and explicitly not a component of the STIR = solution. While we can all see the vehemence of your personal objection, = I am not seeing any rational reason here to strike information from the = document that actually helps people to understand what this work is = about. Nor do I think your curious construal of Andrew's (actually quite = reasonable) request, when combined with your own more obscure complaint, = justifies issuing blanket commands as you do below. Why don't we leave = it to the chairs to assess consensus.

Jon Peterson
Neustar, = Inc.



Sent with Good (www.good.com)


-----Original = Message-----
From: Richard Shockey [richard@shockey.us]
Sent: Monday, = November 04, 2013 08:27 PM Eastern Standard = Time
To: Peterson, Jon; 'Andrew Allen'; stir@ietf.org
Subject: RE: [stir] = comments on = draft-ietf-stir-problem-statement-00


Jon .. = what about NO don=92t you understand. 
 
We object to the references. Remove = them now.
 
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, = Jon
Sent: Monday, November 04, 2013 = 6:26 PM
To: Andrew Allen; stir@ietf.org
Subject: Re: [stir] comments on = draft-ietf-stir-problem-statement-00
 
<AA>I don=92t = think just the fact that some people happen to be familiar with iMessage = is sufficient justification to make it a good example to use in the = draft =96 particularly since it has short comings such as being = currently restricted to a single platform. I believe Whatsapp has the = most user=92s and also has multi vendor support. I suppose a list of = e.g=92s is OK but I don=92t see why we need to describe in any detail a = specific service =96 since most of them have similar = characteristics.</AA>
 
I think the fact that people are = familiar with iMessage is a very good reason to list it as one example. = I'm happy to include other examples, including Whatsapp. I would also be = happy to make the descriptive text there less specific to any particular = vendor, but I do have a hard time seeing how listing iMessage here would = make people misunderstand the problem = statement.
 
[AA] My = problem is with the statement =93domains that = have no relationship with the number assignee=94Certainly they have a relationship =96 = in fact a close and trusted one and the home domain provides the number = to assert to the roamed to domain.  So I think it needs to be made = clearer.
 
 =
Okay, per = the text I sent in my last mail, we can make this clearer. Again, what = this means for STIR is that the the roaming carrier won't have the = authority over the number. 
 
Jon = Peterson
Neustar, Inc.
 
-----------------------= ----------------------------------------------
This transmission = (including any attachments) may contain confidential information, = privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful.
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/m= ailman/listinfo/stir

= --Apple-Mail=_50B9458E-9343-4753-ABFC-145C7F199851-- From David.Holmes@sprint.com Tue Nov 5 11:12:09 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143A321E8093 for ; Tue, 5 Nov 2013 11:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EofBsJiol4BT for ; Tue, 5 Nov 2013 11:12:03 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id D27D211E8117 for ; Tue, 5 Nov 2013 11:12:03 -0800 (PST) Received: from mail10-co9-R.bigfish.com (10.236.132.233) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.22; Tue, 5 Nov 2013 19:12:03 +0000 Received: from mail10-co9 (localhost [127.0.0.1]) by mail10-co9-R.bigfish.com (Postfix) with ESMTP id 3E6D01002D6 for ; Tue, 5 Nov 2013 19:12:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.25; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzc85fhzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh18c673h1de097h186068hz2fh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2184h2216h1155h) Received-SPF: pass (mail10-co9: domain of sprint.com designates 144.230.168.25 as permitted sender) client-ip=144.230.168.25; envelope-from=David.Holmes@sprint.com; helo=plsasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail10-co9 (localhost.localdomain [127.0.0.1]) by mail10-co9 (MessageSwitch) id 1383678720388461_5511; Tue, 5 Nov 2013 19:12:00 +0000 (UTC) Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.246]) by mail10-co9.bigfish.com (Postfix) with ESMTP id 574BB3A0091 for ; Tue, 5 Nov 2013 19:12:00 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 5 Nov 2013 19:11:59 +0000 Received: from PDAWEH02.ad.sprint.com (pdaweh02.corp.sprint.com [144.226.111.42]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA5JBvYT010628 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Nov 2013 13:11:58 -0600 Received: from pdawm06a.ad.sprint.com ([169.254.1.201]) by PDAWEH02.ad.sprint.com ([144.226.111.42]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 13:11:57 -0600 From: "Holmes, David W [NTK]" To: "stir@ietf.org" Thread-Topic: [stir] broken links on agenda page? Thread-Index: Ac7aWsOMUf+w5o0TT9OAIHZSAVTuSA== Date: Tue, 5 Nov 2013 19:11:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.229.76.114] Content-Type: multipart/alternative; boundary="_000_F2A3B01434AD424F98139C02123503930111C645PDAWM06Aadsprin_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [stir] broken links on agenda page? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:12:09 -0000 --_000_F2A3B01434AD424F98139C02123503930111C645PDAWM06Aadsprin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anyone else having issues with the first two document link on the agenda pa= ge http://tools.ietf.org/wg/stir/agenda?item=3Dagenda-88-stir.html ? BR/David ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_F2A3B01434AD424F98139C02123503930111C645PDAWM06Aadsprin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anyone else having issu= es with the first two document link on the agenda page http://tools.ietf.org/wg/stir/agenda?item=3Dagenda-88-stir.html ?

 

BR/David



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_F2A3B01434AD424F98139C02123503930111C645PDAWM06Aadsprin_-- From mary.ietf.barnes@gmail.com Tue Nov 5 12:05:10 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FD821F9DF0 for ; Tue, 5 Nov 2013 12:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JUrIaEUrF4r for ; Tue, 5 Nov 2013 12:05:09 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id E422C21F9F45 for ; Tue, 5 Nov 2013 12:05:06 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id f4so2667040wiw.16 for ; Tue, 05 Nov 2013 12:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4glXwdkCVOgOTSaTkvHDloop7VHYsWOMv6mkLzS5PlQ=; b=X4bZ2SAOnoXVfpB1WpuU/7UJMWKKQk9Y7JjwDF21EVA/2g3a+CJqSojqmTy0gbGh2h zqGfxLYoS8orEXzrRFzPVpvbSuGzA9DcfTEtrsE5JvmrTEHfdA3IXJ+53dJoZToXk+yH 6MIuQ3sWoUQj7zwDtzZoWHJtOfNJaXexGmF7AXLP3ewJ5B6AgsOVp3i5XlB3beW+/YhD 67j+JfZTQrB+9PVxQXC0U93GcZjK3F4hT4stVU/GZLb9oo1EUyhv/vNC4rsRzClIkXj3 azk5xfXu6MqXe7xitV/x6O4KZYZ/UxaqzT3f7lrfAPalwFQxqKU4sf/f03XSd6DXjitz IgBg== MIME-Version: 1.0 X-Received: by 10.194.239.40 with SMTP id vp8mr8416329wjc.45.1383681905931; Tue, 05 Nov 2013 12:05:05 -0800 (PST) Received: by 10.216.36.4 with HTTP; Tue, 5 Nov 2013 12:05:05 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Nov 2013 14:05:05 -0600 Message-ID: From: Mary Barnes To: "Holmes, David W [NTK]" Content-Type: multipart/alternative; boundary=001a11c1b4527c3ac004ea738c12 Cc: "stir@ietf.org" Subject: Re: [stir] broken links on agenda page? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 20:05:10 -0000 --001a11c1b4527c3ac004ea738c12 Content-Type: text/plain; charset=ISO-8859-1 Yeah, those links are broken. Here's the correct ones: http://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ or for the explicit version: http://www.ietf.org/id/draft-ietf-stir-problem-statement-00.txt AND http://datatracker.ietf.org/doc/draft-ietf-stir-threats/ http://www.ietf.org/id/draft-ietf-stir-threats-00.txt Mary. On Tue, Nov 5, 2013 at 1:11 PM, Holmes, David W [NTK] < David.Holmes@sprint.com> wrote: > Anyone else having issues with the first two document link on the agenda > page http://tools.ietf.org/wg/stir/agenda?item=agenda-88-stir.html ? > > > > BR/David > > ------------------------------ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you are > not the intended recipient, please contact the sender and delete all copies > of the message. > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > --001a11c1b4527c3ac004ea738c12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 5, 2013 at 1:11 PM, H= olmes, David W [NTK] <David.Holmes@sprint.com> wrote:<= br>

Anyone else having issues= with the first two document link on the agenda page http://tools.ietf.org/wg/stir/agenda?item=3Dagenda-88-st= ir.html ?

=A0

BR/David



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir


--001a11c1b4527c3ac004ea738c12-- From fmousinh@cisco.com Tue Nov 5 14:34:22 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA9421E80AA for ; Tue, 5 Nov 2013 14:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c-DV4UwzqC2 for ; Tue, 5 Nov 2013 14:34:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AE62611E81A7 for ; Tue, 5 Nov 2013 14:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36158; q=dns/txt; s=iport; t=1383690856; x=1384900456; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=2c7mzNb38pb6Zq3GC3czzmvZcAbihNtjIueOXWSLaxc=; b=aYU9E3+Evi5X6WMt+L6GucyRCVSc6SA6iU4m2t9aGwwXs/d+AN+rSm6W 8o/FxjKE/6/eCRI457NKU9P4fA2436LSuYUMUYVrky58qKveeg4zsbwzI TW3CXwKYiKv5UbxAGK4v0PEbBSPSNJ+EdZL9Asv3LFrgZ4NJmNvrivNUJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioHAO9xeVKtJV2Z/2dsb2JhbABQBgOCQ0Q4U79HgSwWbQeCJQEBAQMBAQEBKgQ2BxAHBgEIEQMBAQEWCwEGLgsUCQgCBBMJEodgBg2dLJErkCGOFwMGgSEHAQwKAQYEB4QeA5NpQoNfkgmDJoFoAgcXBhw X-IronPort-AV: E=Sophos;i="4.93,642,1378857600"; d="scan'208,217";a="281157462" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 05 Nov 2013 22:34:15 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA5MYFpr023886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Nov 2013 22:34:15 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 16:34:14 -0600 From: "Fernando Mousinho (fmousinh)" To: "stir@ietf.org" Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQHO2ncnkmgbes0hE0e5ixM8EUlibA== Date: Tue, 5 Nov 2013 22:34:14 +0000 Message-ID: In-Reply-To: <4B1956260CD29F4A9622F00322FE05319381A907C4@BOBO1A.bobotek.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.92.240] Content-Type: multipart/alternative; boundary="_000_CE9ED89F2D9DDfmousinhciscocom_" MIME-Version: 1.0 Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:34:22 -0000 --_000_CE9ED89F2D9DDfmousinhciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I would suggest we add a new attack type to section 3. More and more compan= ies are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for identificati= on. If I call from my home phone number, I=92m informed that I don=92t need= to provide any further identification because my number is on file. Some (= all?) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation =96 but in this = case, the =93victim=94 is a business, unlike the other two scenarios we=92v= e listed so far. Addressing this scenario would actually turn STIR into a feature, given it = would enable contact centers of all sizes to eliminate the need for caller = identification from known TNs. From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen >, "Peterson, J= on" > Cc: "stir@ietf.org" >, Richard Shockey >, "'DO= LLY, MARTIN C'" >, 'Robert Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the follo= wing sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is = simply the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the rendere= d information. No issues with leaving this as it=92s a valid point. Anoth= er (increasing) motivation is to evade network and/or endpoint defenses tha= t may block based on CPN. So however it=92s worded, I think it=92s important to allow for both attack= objectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bo= unces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; '= DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" > > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draf= t: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried = in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in= the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> > > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [mailto:s= tir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --_000_CE9ED89F2D9DDfmousinhciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I would suggest we add a new attack type to section 3. More and more c= ompanies are using the caller ID for account validation. For example, if I = call my credit card provider from my office number, they ask me for identif= ication. If I call from my home phone number, I=92m informed that I don=92t need to provide any further id= entification because my number is on file. Some (all?) companies that imple= ment this type of validation rely on SS7 today.

Ultimately, this is yet another variation of impersonation =96 but in = this case, the =93victim=94 is a business, unlike the other two scenarios w= e=92ve listed so far.

Addressing this scenario would actually turn STIR into a feature, give= n it would enable contact centers of all sizes to eliminate the need for ca= ller identification from known TNs.



From: Alex Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, 2013 at 1= 2:51 PM
To: Brian Rosen <br@brianrosen.net>, "Peterson, Jon" = <jon.peterson@neustar.biz>
Cc: "stir@ietf.org" <stir@i= etf.org>, Richard Shockey <= richard@shockey.us>, "'DOLLY, MARTIN C'" <md3135@att.com>, 'Robert Sparks' <rjsparks@nostr= um.com>
Subject: Re: [stir] draft-peterson-= stir-threats-00.txt

Jon,

 

Thanks for the response.  The intention in #= 1 below is to clarify the following sentence:

 

The primary attack vector is

   therefore one where the attacker con= trives for the calling telephone

   number in signaling to be a particul= ar chosen number, one that the

   attacker does not have the authority= to call from, in order for that

   number to be rendered on the term= inating side. 

 

This might be misconstrued as indicating that the= objective of spoofing is simply the rendering of a spoofed number on the r= eceiving display, causing mistaken conclusions that defenses might be limit= ed to securing the rendered information.  No issues with leaving this as it=92s a valid point.  Another (= increasing) motivation is to evade network and/or endpoint defenses that ma= y block based on CPN. 

 

So however it=92s worded, I think it=92s importan= t to allow for both attack objectives of a spoofed presentation at the endp= oint and in transit.   

 

Regards,

 

Alex

 

> -----Original Message-----

> From: stir-bounces@ietf.org [mail= to:stir-bounces@ietf.org] On Behalf Of

> Brian Rosen

> Sent: Tuesday, October 01, 2013 9:29 AM

> To: Peterson, Jon

> Cc: stir@ie= tf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard

> Shockey

> Subject: Re: [stir] draft-peterson-stir-thre= ats-00.txt

>

> Don't think there is much MESSAGE.  MSR= P is about all we see, and XMPP is

> more likely than that.

>

> Brian

>

> On Oct 1, 2013, at 12:24 PM, "Peterson,= Jon" <jon.peterson@neustar.biz&g= t;

> wrote:

>

> > Thanks for these notes, Alex. Some resp= onses below.

> >

> >> Here are several comments that shou= ld feed into the IETF Peterson draft:

> >>

> >> *   Remove any assumption= s that the solution cannot be in-network

> [IMO,

> >> both endpoint and in-network soluti= ons should be facilitated]

> >

> > Agreed that both in-band and out-of-ban= d solutions can usually be

> > implemented in either endpoints or in i= ntermediaries of various kinds.

> > If I see text that implies otherwise, I= 'll certainly change it.

> >

> >> *   Add a sessionless att= ack scenario.  A spam payload may be carried in

> a

> >> SIP INVITE or MESSAGE, which might = contain stock market advice even

> >> in a display name field.  Thes= e attacks do NOT require session

> establishment.

> >> More generally, we should be mindfu= l of the fact that SIP is used in

> >> telephony form more than voice sess= ion setup.

> >

> > Probably if we were going to include a = sessionless attack scenario, it

> > would be with regular text messages (wh= ether carried on the PSTN over

> > TCAP or with some Internet protocol, in= cluding MESSAGE) rather than

> > with an INVITE, which typically wouldn'= t result in a payload being

> > immediately rendered to a user. More on= this below with your suggested

> text.

> >

> >> Here's some suggested markup:

> >>

> >>

> >> 1.    Replace 2nd se= ntence of 2nd paragraph of 1.0 Introduction with:

> >>

> >> The primary attack vector is

> >>  therefore one where the attac= ker contrives for the calling telephone

> >> number in signaling to be a particu= lar chosen number that the

> >> attacker does not have the authorit= y to call from.

> >

> > What you want here is to remove the imp= lication that the number will

> > be rendered on the terminating side? Wh= ile there are some attacks

> > where that isn't significant, perhaps, = I would say it is significant

> > in the primary attack vectors that conc= ern us.

> >

> >> 2.  Replace 3rd paragraph of 2= .1 Endpoints with:

> >>

> >>     Smart devic= es are generally based on computers with some degree

> >> of programmability, the capacity to= access the Internet, and

> >> capabilities of rendering text, aud= io and/or images.  This includes

> >> smart phones, telephone application= s on desktop and laptop computers,

> >> IP private branch exchanges, and so= on.

> >

> > I can add the notion that smart devices= can render text, audio and/or

> > images as you suggest.

> >

> >> 3.  Add to 3.3 Attack Scenario= s:

> >>

> >>       Impe= rsonation, IP-Mobile Text Message

> >>

> >>       &nbs= p;An attacker with an computer sends a high volume of SIP MESSAGE

> >> spam message to IP-enabled smart ph= ones using randomized calling

> >> party numbers.

> >>

> >>       Coun= termeasure: in-band authenticated identity

> >

> > Provided we're talking about end-to-end= SIP use of MESSAGE, agreed

> > that in-band would be the right counter= measure. I am curious though

> > whether practically speaking there is e= nough use of MESSAGE in this

> > fashion that we're actually seeing high= -volume spam over MESSAGE

> > today. Either way, no problem having an= attack scenario of this form in the

> document.

> >

> > Jon Peterson

> > Neustar, Inc.

> >

> >> Regards,

> >>

> >> Alex

> >>

> >>> -----Original Message-----

> >>> From: stir-= bounces@ietf.org [mailto:stir-bounces@ietf.o= rg] On Behalf

> >>> Of Richard Shockey

> >>> Sent: Monday, September 30, 201= 3 1:11 PM

> >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] draft-peter= son-stir-threats-00.txt

> >>>

> >>> +1

> >>>

> >>> -----Original Message-----

> >>> From: stir-= bounces@ietf.org [mailto:stir-bounces@ietf.o= rg] On Behalf

> >>> Of DOLLY, MARTIN C

> >>> Sent: Monday, September 30, 201= 3 12:58 PM

> >>> To: Robert Sparks

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] draft-peter= son-stir-threats-00.txt

> >>>

> >>> Yes, ok

> >>>

> >>> Martin Dolly

> >>> Lead Member of Technical Staff<= /p>

> >>> Core Network & Gov't/Regula= tory Standards AT&T Labs - Network

> >>> Technology

> >>> +1-609-903-3360

> >>> md3135@att.com

> >>>

> >>>> On Sep 30, 2013, at 12:47 P= M, "Robert Sparks"

> >>>> <rjsp= arks@nostrum.com>

> >>> wrote:

> >>>>

> >>>>> On 9/26/13 3:42 PM, DOL= LY, MARTIN C wrote:

> >>>>> With Hadriel comments i= ncorporated, it is a start

> >>>> Hi Martin -

> >>>>

> >>>> Just to make sure - I think= you're referring to Hadriel's comments

> >>>> on the

> >>> problem statement document?

> >>>> I don't think Hadriel's com= mented directly on stir-threats yet.

> >>>>

> >>>> In any case, we _are_ talki= ng about a starting place, not a

> >>>> finished

> >>> product.

> >>>>

> >>>> If there's no other objecti= on, I'd like to get Jon to submit the

> >>>> threats

> >>> document as a WG -00 as soon as= it's convenient.

> >>>>

> >>>> RjS

> >>>>>

> >>>>> -----Original Message--= ---

> >>>>> From: stir-bounces@ietf.org [mailto:stir-bounce= s@ietf.org] On

> >>>>> Behalf Of Russ Housley<= /p>

> >>>>> Sent: Thursday, Septemb= er 26, 2013 4:37 PM

> >>>>> To: IETF STIR Mail List=

> >>>>> Subject: Re: [stir] dra= ft-peterson-stir-threats-00.txt

> >>>>>

> >>>>> It has been six days, I= 'd like to hear from more people about this

> >>> document.  Martin asked fo= r an additional week, so I'm sure we will

> >>> hear from him soon.

> >>>>>

> >>>>> Russ

> >>>>>

> >>>>>

> >>>>>> On Sep 20, 2013, at= 5:23 PM, Russ Housley wrote:

> >>>>>>

> >>>>>> http://www.ietf.org/i= d/draft-peterson-stir-threats-00.txt

> >>>>>>

> >>>>>> Should the working = group adopt this I-D as the starting point for

> >>>>>> the

> >>> STIR threat docuent?

> >>>>>>

> >>>>>> Russ

> >>>>> _______________________= ________________________

> >>>>> stir mailing list

> >>>>> stir@ietf.o= rg

> >>>>> https://www.ietf.org/= mailman/listinfo/stir

> >>>>

> >>>> ___________________________= ____________________

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

> >>>

> >>> _______________________________= ________________

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

> >

> > _______________________________________= ________

> > stir mailing list

> > stir@ietf.org

> > https://www.ietf.org/= mailman/listinfo/stir

>

> ____________________________________________= ___

> stir mailing list

> stir@ietf.org

> https://ww= w.ietf.org/mailman/listinfo/stir

 --_000_CE9ED89F2D9DDfmousinhciscocom_-- From Pierce.Gorman@sprint.com Tue Nov 5 15:05:25 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB27F21F9609 for ; Tue, 5 Nov 2013 15:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.774 X-Spam-Level: X-Spam-Status: No, score=-3.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIoTWClhXtGH for ; Tue, 5 Nov 2013 15:05:13 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id CBBD511E8179 for ; Tue, 5 Nov 2013 15:05:12 -0800 (PST) Received: from mail191-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Tue, 5 Nov 2013 23:05:12 +0000 Received: from mail191-va3 (localhost [127.0.0.1]) by mail191-va3-R.bigfish.com (Postfix) with ESMTP id 0374D2001E4; Tue, 5 Nov 2013 23:05:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.229.32.57; KIP:(null); UIP:(null); IPV:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zzbb2dI98dI9371Ic85fh542I1432I1447Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068h8275fhz2fh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h1155h) Received-SPF: pass (mail191-va3: domain of sprint.com designates 144.229.32.57 as permitted sender) client-ip=144.229.32.57; envelope-from=Pierce.Gorman@sprint.com; helo=pdaasdm2.corp.sprint.com ; p.sprint.com ; Received: from mail191-va3 (localhost.localdomain [127.0.0.1]) by mail191-va3 (MessageSwitch) id 1383692708463276_16482; Tue, 5 Nov 2013 23:05:08 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.226]) by mail191-va3.bigfish.com (Postfix) with ESMTP id 6AE79120040; Tue, 5 Nov 2013 23:05:08 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 5 Nov 2013 23:05:07 +0000 Received: from PLSWEH03.ad.sprint.com (plsweh03.corp.sprint.com [144.226.242.132]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA5N566Y008255 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Nov 2013 17:05:07 -0600 Received: from pdawm10a.ad.sprint.com ([169.254.2.186]) by PLSWEH03.ad.sprint.com ([144.226.242.132]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 17:05:06 -0600 From: "Gorman, Pierce A [NTK]" To: "Fernando Mousinho (fmousinh)" , "stir@ietf.org" Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQHO2nc0UwzhVvA23kepk+N3A5gBjZoXQFMA Date: Tue, 5 Nov 2013 23:05:05 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE05319381A907C4@BOBO1A.bobotek.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.21] Content-Type: multipart/alternative; boundary="_000_B4C06A5710F0ED4583B3CF5E9C6B21D855159DACPDAWM10Aadsprin_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:05:25 -0000 --_000_B4C06A5710F0ED4583B3CF5E9C6B21D855159DACPDAWM10Aadsprin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with your characterization of businesses as victim of caller ID fra= ud however contact centers also use TN as a key to improve information avai= lable to call agents to reduce average time-per-call and increase capacity = of the call center. So I don't agree that STIR would "eliminate the need f= or caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more compan= ies are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for identificati= on. If I call from my home phone number, I'm informed that I don't need to = provide any further identification because my number is on file. Some (all?= ) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this ca= se, the "victim" is a business, unlike the other two scenarios we've listed= so far. Addressing this scenario would actually turn STIR into a feature, given it = would enable contact centers of all sizes to eliminate the need for caller = identification from known TNs. From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen >, "Peterson, J= on" > Cc: "stir@ietf.org" >, Richard Shockey >, "'DO= LLY, MARTIN C'" >, 'Robert Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the follo= wing sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is = simply the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the rendere= d information. No issues with leaving this as it's a valid point. Another= (increasing) motivation is to evade network and/or endpoint defenses that = may block based on CPN. So however it's worded, I think it's important to allow for both attack obj= ectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bo= unces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; '= DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" > > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draf= t: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried = in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in= the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> > > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [mailto:s= tir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_B4C06A5710F0ED4583B3CF5E9C6B21D855159DACPDAWM10Aadsprin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with your characterization of busin= esses as victim of caller ID fraud however contact centers also use TN as a= key to improve information available to call agents to reduce average time-per-call and increase capacity of the call center.&nbs= p; So I don’t agree that STIR would “eliminate the need for cal= ler identification from known TNs.”

 

But perhaps I misunderstood your last sente= nce?

 

 

From: Fernan= do Mousinho (fmousinh) [mailto:fmousinh@cisco.com]
Sent: November 05, 2013 4:34 PM
To: stir@ietf.org
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

I woul= d suggest we add a new attack type to section 3. More and more companies ar= e using the caller ID for account validation. For example, if I call my cre= dit card provider from my office number, they ask me for identification. If I call from my home phone number, IR= 17;m informed that I don’t need to provide any further identification= because my number is on file. Some (all?) companies that implement this ty= pe of validation rely on SS7 today.

 =

Ultima= tely, this is yet another variation of impersonation – but in this ca= se, the “victim” is a business, unlike the other two scenarios = we’ve listed so far.

 =

Addres= sing this scenario would actually turn STIR into a feature, given it would = enable contact centers of all sizes to eliminate the need for caller identi= fication from known TNs.

 =

 =

 =

From: Alex Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, 2013 at 12:51 PM
To: Brian Rosen <br@brianros= en.net>, "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "stir@ietf.org" &= lt;stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "= ;'DOLLY, MARTIN C'" <md3135@att.c= om>, 'Robert Sparks' <rjsparks@nostr= um.com>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 =

Jon,

 

Thanks for the respon= se.  The intention in #1 below is to clarify the following sentence:

 

The primary at= tack vector is

   therefor= e one where the attacker contrives for the calling telephone

   number i= n signaling to be a particular chosen number, one that the

   attacker= does not have the authority to call from, in order for that

   numbe= r to be rendered on the terminating side. 

 

This might be miscons= trued as indicating that the objective of spoofing is simply the rendering = of a spoofed number on the receiving display, causing mistaken conclusions = that defenses might be limited to securing the rendered information.  No issues with leaving this as it’s = a valid point.  Another (increasing) motivation is to evade network an= d/or endpoint defenses that may block based on CPN. 

 

So however it’s= worded, I think it’s important to allow for both attack objectives o= f a spoofed presentation at the endpoint and in transit.   

 

Regards,

 

Alex

 

> -----Original Me= ssage-----

> From: stir-bounces@ietf.org [mailto:= stir-bounces@ietf.org] On Behalf Of

> Brian Rosen

> Sent: Tuesday, O= ctober 01, 2013 9:29 AM

> To: Peterson, Jo= n

> Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richar= d

> Shockey

> Subject: Re: [st= ir] draft-peterson-stir-threats-00.txt

>

> Don't think ther= e is much MESSAGE.  MSRP is about all we see, and XMPP is

> more likely than= that.

>

> Brian

>

> On Oct 1, 2013, = at 12:24 PM, "Peterson, Jon" <jon.pete= rson@neustar.biz>

> wrote:

>

> > Thanks for = these notes, Alex. Some responses below.

> >

> >> Here ar= e several comments that should feed into the IETF Peterson draft:

> >><= /p>

> >> * =   Remove any assumptions that the solution cannot be in-network=

> [IMO,

> >> both en= dpoint and in-network solutions should be facilitated]

> >

> > Agreed that= both in-band and out-of-band solutions can usually be

> > implemented= in either endpoints or in intermediaries of various kinds.

> > If I see te= xt that implies otherwise, I'll certainly change it.

> >

> >> * =   Add a sessionless attack scenario.  A spam payload may be carri= ed in

> a

> >> SIP INV= ITE or MESSAGE, which might contain stock market advice even

> >> in a di= splay name field.  These attacks do NOT require session

> establishment.

> >> More ge= nerally, we should be mindful of the fact that SIP is used in

> >> telepho= ny form more than voice session setup.

> >

> > Probably if= we were going to include a sessionless attack scenario, it

> > would be wi= th regular text messages (whether carried on the PSTN over

> > TCAP or wit= h some Internet protocol, including MESSAGE) rather than

> > with an INV= ITE, which typically wouldn't result in a payload being

> > immediately= rendered to a user. More on this below with your suggested

> text.

> >

> >> Here's = some suggested markup:

> >><= /p>

> >><= /p>

> >> 1. = ;   Replace 2nd sentence of 2nd paragraph of 1.0 Introduction wit= h:

> >><= /p>

> >> The pri= mary attack vector is

> >>  t= herefore one where the attacker contrives for the calling telephone<= /p>

> >> number = in signaling to be a particular chosen number that the

> >> attacke= r does not have the authority to call from.

> >

> > What you wa= nt here is to remove the implication that the number will

> > be rendered= on the terminating side? While there are some attacks

> > where that = isn't significant, perhaps, I would say it is significant

> > in the prim= ary attack vectors that concern us.

> >

> >> 2. = ; Replace 3rd paragraph of 2.1 Endpoints with:

> >><= /p>

> >> &n= bsp;   Smart devices are generally based on computers with some d= egree

> >> of prog= rammability, the capacity to access the Internet, and

> >> capabil= ities of rendering text, audio and/or images.  This includes

> >> smart p= hones, telephone applications on desktop and laptop computers,

> >> IP priv= ate branch exchanges, and so on.

> >

> > I can add t= he notion that smart devices can render text, audio and/or

> > images as y= ou suggest.

> >

> >> 3. = ; Add to 3.3 Attack Scenarios:

> >><= /p>

> >>  &= nbsp;    Impersonation, IP-Mobile Text Message

> >><= /p>

> >>  &= nbsp;     An attacker with an computer sends a high vol= ume of SIP MESSAGE

> >> spam me= ssage to IP-enabled smart phones using randomized calling

> >> party n= umbers.

> >><= /p>

> >>  &= nbsp;    Countermeasure: in-band authenticated identity

> >

> > Provided we= 're talking about end-to-end SIP use of MESSAGE, agreed

> > that in-ban= d would be the right countermeasure. I am curious though

> > whether pra= ctically speaking there is enough use of MESSAGE in this

> > fashion tha= t we're actually seeing high-volume spam over MESSAGE

> > today. Eith= er way, no problem having an attack scenario of this form in the

> document.=

> >

> > Jon Peterso= n

> > Neustar, In= c.

> >

> >> Regards= ,

> >><= /p>

> >> Alex

> >><= /p>

> >>> ---= --Original Message-----

> >>> Fro= m: stir-bounces@ietf.or= g [mailto:stir-bounces@ietf.org]= On Behalf

> >>> Of = Richard Shockey

> >>> Sen= t: Monday, September 30, 2013 1:11 PM

> >>> To:= 'DOLLY, MARTIN C'; 'Robert Sparks'

> >>> Cc:= stir@ietf.org=

> >>> Sub= ject: Re: [stir] draft-peterson-stir-threats-00.txt

> >>>

> >>> = 3;1

> >>>

> >>> ---= --Original Message-----

> >>> Fro= m: stir-bounces@ietf.or= g [mailto:stir-bounces@ietf.org]= On Behalf

> >>> Of = DOLLY, MARTIN C

> >>> Sen= t: Monday, September 30, 2013 12:58 PM

> >>> To:= Robert Sparks

> >>> Cc:= stir@ietf.org=

> >>> Sub= ject: Re: [stir] draft-peterson-stir-threats-00.txt

> >>>

> >>> Yes= , ok

> >>>

> >>> Mar= tin Dolly

> >>> Lea= d Member of Technical Staff

> >>> Cor= e Network & Gov't/Regulatory Standards AT&T Labs - Network

> >>> Tec= hnology

> >>> = 3;1-609-903-3360

> >>> md3135@att.com

> >>>

> >>>>= On Sep 30, 2013, at 12:47 PM, "Robert Sparks"

> >>>>= <rjsparks@nostrum.com>

> >>> wro= te:

> >>>>=

> >>>>= > On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote:

> >>>>= > With Hadriel comments incorporated, it is a start

> >>>>= Hi Martin -

> >>>>=

> >>>>= Just to make sure - I think you're referring to Hadriel's comments<= /p>

> >>>>= on the

> >>> pro= blem statement document?

> >>>>= I don't think Hadriel's commented directly on stir-threats yet.

> >>>>=

> >>>>= In any case, we _are_ talking about a starting place, not a

> >>>>= finished

> >>> pro= duct.

> >>>>=

> >>>>= If there's no other objection, I'd like to get Jon to submit the

> >>>>= threats

> >>> doc= ument as a WG -00 as soon as it's convenient.

> >>>>=

> >>>>= RjS

> >>>>= >

> >>>>= > -----Original Message-----

> >>>>= > From: stir-bounces@ietf.or= g [mailto:stir-bounces@ietf.org]= On

> >>>>= > Behalf Of Russ Housley

> >>>>= > Sent: Thursday, September 26, 2013 4:37 PM

> >>>>= > To: IETF STIR Mail List

> >>>>= > Subject: Re: [stir] draft-peterson-stir-threats-00.txt

> >>>>= >

> >>>>= > It has been six days, I'd like to hear from more people about this

> >>> doc= ument.  Martin asked for an additional week, so I'm sure we will

> >>> hea= r from him soon.

> >>>>= >

> >>>>= > Russ

> >>>>= >

> >>>>= >

> >>>>= >> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote:

> >>>>= >>

> >>>>= >> http://www.ietf.org/= id/draft-peterson-stir-threats-00.txt

> >>>>= >>

> >>>>= >> Should the working group adopt this I-D as the starting point for<= /span>

> >>>>= >> the

> >>> STI= R threat docuent?

> >>>>= >>

> >>>>= >> Russ

> >>>>= > _______________________________________________

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

> >>> ___= ____________________________________________

> >>> sti= r mailing list

> >>> stir@ietf.org=

> >>> https://www.ietf.org= /mailman/listinfo/stir

> >>>

> >>> ___= ____________________________________________

> >>> sti= r mailing list

> >>> stir@ietf.org=

> >>> https://www.ietf.org= /mailman/listinfo/stir

> >> _______= ________________________________________

> >> stir ma= iling list

> >> stir@ietf.org=

> >> https://www.ietf.org= /mailman/listinfo/stir

> >

> > ___________= ____________________________________

> > stir mailin= g list

> > stir@ietf.org=

> > https://www.ietf.org= /mailman/listinfo/stir

>

> ________________= _______________________________

> stir mailing lis= t

> stir@ietf.org=

> https://www.ietf.org= /mailman/listinfo/stir



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_B4C06A5710F0ED4583B3CF5E9C6B21D855159DACPDAWM10Aadsprin_-- From fmousinh@cisco.com Tue Nov 5 15:26:09 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C6111E80F7 for ; Tue, 5 Nov 2013 15:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQmLPxx8TIra for ; Tue, 5 Nov 2013 15:26:04 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBBA21E80BA for ; Tue, 5 Nov 2013 15:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50411; q=dns/txt; s=iport; t=1383693963; x=1384903563; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=UsrPREO7GM9rpdETyoYSgpc9giapRWvffzpszj6Jgpg=; b=AkuzbW4qMKITLJ5pZhDi5NnoSgNASDmknXNH1rkuRQ0bcYFQ/BZEeFhE M720sEo3RlFizbx2zzntLFPeMFnF0l+s2AJEUvoP63eZjntpG88cKZPBT d/JdBB5N66IsxOtRVmZj2HQcfXjni++bcDjgdiYbmuo6wzM70eXNxhz/9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAGt9eVKtJV2c/2dsb2JhbABDDQYDgkNEOFO/R4EmFnSCJQEBAQMBAQEBFxcoDgcQBwYBCBEDAQEBFAILAQYuCxQJCAIEARIJEodgBg2uQpAhjggPAwaBAgwTBgEBBgYKAQIEBAeEHgOTaUKDX5IJgyaBaAIHFwYc X-IronPort-AV: E=Sophos;i="4.93,642,1378857600"; d="scan'208,217";a="281166981" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 05 Nov 2013 23:25:59 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA5NPx7L022082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 23:25:59 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 17:25:58 -0600 From: "Fernando Mousinho (fmousinh)" To: "Gorman, Pierce A [NTK]" , "stir@ietf.org" Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQHO2ncnkmgbes0hE0e5ixM8EUlibJoXppSA//+w6oA= Date: Tue, 5 Nov 2013 23:25:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.89.134] Content-Type: multipart/alternative; boundary="_000_CE9EE40A2DA2Efmousinhciscocom_" MIME-Version: 1.0 Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:26:09 -0000 --_000_CE9EE40A2DA2Efmousinhciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Let me rephrase it=85 it may eliminate the need for other forms of caller i= dentification beyond what STIR will provide, depending on the specific use = case. For example, a credit card company may choose to rely entirely on STI= R before allowing a card to be unblocked by an IVR (and as I said earlier, = many companies do it today). In other use cases, the TN alone is not suffic= ient information =96 my health care provider will want to know which member= of the family is calling. I agree that ANI is already broadly used to improve customer service today.= However, it is not usually deemed as a secure enough mechanism to validate= the caller (therefore this WG!), except if you are a large organization th= at can leverage things like SS7. STIR would make this type of validation av= ailable to a broader number of companies. Going on a tangent=85 perhaps this is out of scope, but there is not a lot = of discussion about called party hijacking. Couldn=92t a man-in-the-middle = try to answer calls on my behalf? If my bank is calling me, I want to make = sure it=92s really them before carrying a conversation, but wouldn=92t they= want the same? From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho >, "sti= r@ietf.org" > Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fra= ud however contact centers also use TN as a key to improve information avai= lable to call agents to reduce average time-per-call and increase capacity = of the call center. So I don=92t agree that STIR would =93eliminate the ne= ed for caller identification from known TNs.=94 But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more compan= ies are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for identificati= on. If I call from my home phone number, I=92m informed that I don=92t need= to provide any further identification because my number is on file. Some (= all?) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation =96 but in this = case, the =93victim=94 is a business, unlike the other two scenarios we=92v= e listed so far. Addressing this scenario would actually turn STIR into a feature, given it = would enable contact centers of all sizes to eliminate the need for caller = identification from known TNs. From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen >, "Peterson, J= on" > Cc: "stir@ietf.org" >, Richard Shockey >, "'DO= LLY, MARTIN C'" >, 'Robert Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the follo= wing sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is = simply the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the rendere= d information. No issues with leaving this as it=92s a valid point. Anoth= er (increasing) motivation is to evade network and/or endpoint defenses tha= t may block based on CPN. So however it=92s worded, I think it=92s important to allow for both attack= objectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bo= unces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; '= DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" > > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draf= t: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried = in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in= the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> > > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [mailto:s= tir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_CE9EE40A2DA2Efmousinhciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9329341513EDCE4CA667CA4A952E8A05@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Let me rephrase it=85 it may eliminate the need for other forms of cal= ler identification beyond what STIR will provide, depending on the specific= use case. For example, a credit card company may choose to rely entirely o= n STIR before allowing a card to be unblocked by an IVR (and as I said earlier, many companies do it today). I= n other use cases, the TN alone is not sufficient information =96 my health= care provider will want to know which member of the family is calling.

I agree that ANI is already broadly used to improve customer service t= oday. However, it is not usually deemed as a secure enough mechanism to val= idate the caller (therefore this WG!), except if you are a large organizati= on that can leverage things like SS7. STIR would make this type of validation available to a broader number= of companies.


Going on a tangent=85 perhaps this is out of scope, but there is not a= lot of discussion about called party hijacking. Couldn=92t a man-in-the-mi= ddle try to answer calls on my behalf? If my bank is calling me, I want to = make sure it=92s really them before carrying a conversation, but wouldn=92t they want the same? 


From: <Gorman>, "Pierce = A [NTK]" <Pierce.Gorman= @sprint.com>
Date: Tuesday, November 5, 2013 at = 6:05 PM
To: Fernando Mousinho <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] draft-peterson-= stir-threats-00.txt

I agree with your characterization of businesses as vict= im of caller ID fraud however contact centers also use TN as a key to impro= ve information available to call agents to reduce average time-per-call and increase capacity of the call center.&= nbsp; So I don=92t agree that STIR would =93eliminate the need for caller i= dentification from known TNs.=94

 

But perhaps I misunderstood your last sentence?

 

 

From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com]
Sent: November 05, 2013 4:34 PM
To: stir@ietf.org
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

I woul= d suggest we add a new attack type to section 3. More and more companies ar= e using the caller ID for account validation. For example, if I call my cre= dit card provider from my office number, they ask me for identification. If I call from my home phone number, I=92m= informed that I don=92t need to provide any further identification because= my number is on file. Some (all?) companies that implement this type of va= lidation rely on SS7 today.

 =

Ultima= tely, this is yet another variation of impersonation =96 but in this case, = the =93victim=94 is a business, unlike the other two scenarios we=92ve list= ed so far.

 =

Addres= sing this scenario would actually turn STIR into a feature, given it would = enable contact centers of all sizes to eliminate the need for caller identi= fication from known TNs.

 =

 =

 =

From: Alex Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, 2013 at 12:51 PM
To: Brian Rosen <br@brianros= en.net>, "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "stir@ietf.org" &= lt;stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "= ;'DOLLY, MARTIN C'" <md3135@att.c= om>, 'Robert Sparks' <rjsparks@nostr= um.com>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 =

Jon,

 

Thanks for the respon= se.  The intention in #1 below is to clarify the following sentence:

 

The primary at= tack vector is

   therefor= e one where the attacker contrives for the calling telephone

   number i= n signaling to be a particular chosen number, one that the

   attacker= does not have the authority to call from, in order for that

   numbe= r to be rendered on the terminating side. 

 

This might be miscons= trued as indicating that the objective of spoofing is simply the rendering = of a spoofed number on the receiving display, causing mistaken conclusions = that defenses might be limited to securing the rendered information.  No issues with leaving this as it=92s a va= lid point.  Another (increasing) motivation is to evade network and/or= endpoint defenses that may block based on CPN. 

 

So however it=92s wor= ded, I think it=92s important to allow for both attack objectives of a spoo= fed presentation at the endpoint and in transit.   

 

Regards,

 

Alex

 

> -----Original Me= ssage-----

> From: stir-bounces@ietf.org [mailto:= stir-bounces@ietf.org] On Behalf Of

> Brian Rosen

> Sent: Tuesday, O= ctober 01, 2013 9:29 AM

> To: Peterson, Jo= n

> Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richar= d

> Shockey

> Subject: Re: [st= ir] draft-peterson-stir-threats-00.txt

>

> Don't think ther= e is much MESSAGE.  MSRP is about all we see, and XMPP is

> more likely than= that.

>

> Brian

>

> On Oct 1, 2013, = at 12:24 PM, "Peterson, Jon" <jon.pete= rson@neustar.biz>

> wrote:

>

> > Thanks for = these notes, Alex. Some responses below.

> >

> >> Here ar= e several comments that should feed into the IETF Peterson draft:

> >><= /p>

> >> * =   Remove any assumptions that the solution cannot be in-network=

> [IMO,

> >> both en= dpoint and in-network solutions should be facilitated]

> >

> > Agreed that= both in-band and out-of-band solutions can usually be

> > implemented= in either endpoints or in intermediaries of various kinds.

> > If I see te= xt that implies otherwise, I'll certainly change it.

> >

> >> * =   Add a sessionless attack scenario.  A spam payload may be carri= ed in

> a

> >> SIP INV= ITE or MESSAGE, which might contain stock market advice even

> >> in a di= splay name field.  These attacks do NOT require session

> establishment.

> >> More ge= nerally, we should be mindful of the fact that SIP is used in

> >> telepho= ny form more than voice session setup.

> >

> > Probably if= we were going to include a sessionless attack scenario, it

> > would be wi= th regular text messages (whether carried on the PSTN over

> > TCAP or wit= h some Internet protocol, including MESSAGE) rather than

> > with an INV= ITE, which typically wouldn't result in a payload being

> > immediately= rendered to a user. More on this below with your suggested

> text.

> >

> >> Here's = some suggested markup:

> >><= /p>

> >><= /p>

> >> 1. = ;   Replace 2nd sentence of 2nd paragraph of 1.0 Introduction wit= h:

> >><= /p>

> >> The pri= mary attack vector is

> >>  t= herefore one where the attacker contrives for the calling telephone<= /p>

> >> number = in signaling to be a particular chosen number that the

> >> attacke= r does not have the authority to call from.

> >

> > What you wa= nt here is to remove the implication that the number will

> > be rendered= on the terminating side? While there are some attacks

> > where that = isn't significant, perhaps, I would say it is significant

> > in the prim= ary attack vectors that concern us.

> >

> >> 2. = ; Replace 3rd paragraph of 2.1 Endpoints with:

> >><= /p>

> >> &n= bsp;   Smart devices are generally based on computers with some d= egree

> >> of prog= rammability, the capacity to access the Internet, and

> >> capabil= ities of rendering text, audio and/or images.  This includes

> >> smart p= hones, telephone applications on desktop and laptop computers,

> >> IP priv= ate branch exchanges, and so on.

> >

> > I can add t= he notion that smart devices can render text, audio and/or

> > images as y= ou suggest.

> >

> >> 3. = ; Add to 3.3 Attack Scenarios:

> >><= /p>

> >>  &= nbsp;    Impersonation, IP-Mobile Text Message

> >><= /p>

> >>  &= nbsp;     An attacker with an computer sends a high vol= ume of SIP MESSAGE

> >> spam me= ssage to IP-enabled smart phones using randomized calling

> >> party n= umbers.

> >><= /p>

> >>  &= nbsp;    Countermeasure: in-band authenticated identity

> >

> > Provided we= 're talking about end-to-end SIP use of MESSAGE, agreed

> > that in-ban= d would be the right countermeasure. I am curious though

> > whether pra= ctically speaking there is enough use of MESSAGE in this

> > fashion tha= t we're actually seeing high-volume spam over MESSAGE

> > today. Eith= er way, no problem having an attack scenario of this form in the

> document.=

> >

> > Jon Peterso= n

> > Neustar, In= c.

> >

> >> Regards= ,

> >><= /p>

> >> Alex

> >><= /p>

> >>> ---= --Original Message-----

> >>> Fro= m: stir-bounces@ietf.or= g [mailto:stir-bounces@ietf.org]= On Behalf

> >>> Of = Richard Shockey

> >>> Sen= t: Monday, September 30, 2013 1:11 PM

> >>> To:= 'DOLLY, MARTIN C'; 'Robert Sparks'

> >>> Cc:= stir@ietf.org=

> >>> Sub= ject: Re: [stir] draft-peterson-stir-threats-00.txt

> >>>

> >>> = 3;1

> >>>

> >>> ---= --Original Message-----

> >>> Fro= m: stir-bounces@ietf.or= g [mailto:stir-bounces@ietf.org]= On Behalf

> >>> Of = DOLLY, MARTIN C

> >>> Sen= t: Monday, September 30, 2013 12:58 PM

> >>> To:= Robert Sparks

> >>> Cc:= stir@ietf.org=

> >>> Sub= ject: Re: [stir] draft-peterson-stir-threats-00.txt

> >>>

> >>> Yes= , ok

> >>>

> >>> Mar= tin Dolly

> >>> Lea= d Member of Technical Staff

> >>> Cor= e Network & Gov't/Regulatory Standards AT&T Labs - Network

> >>> Tec= hnology

> >>> = 3;1-609-903-3360

> >>> md3135@att.com

> >>>

> >>>>= On Sep 30, 2013, at 12:47 PM, "Robert Sparks"

> >>>>= <rjsparks@nostrum.com>

> >>> wro= te:

> >>>>=

> >>>>= > On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote:

> >>>>= > With Hadriel comments incorporated, it is a start

> >>>>= Hi Martin -

> >>>>=

> >>>>= Just to make sure - I think you're referring to Hadriel's comments<= /p>

> >>>>= on the

> >>> pro= blem statement document?

> >>>>= I don't think Hadriel's commented directly on stir-threats yet.

> >>>>=

> >>>>= In any case, we _are_ talking about a starting place, not a

> >>>>= finished

> >>> pro= duct.

> >>>>=

> >>>>= If there's no other objection, I'd like to get Jon to submit the

> >>>>= threats

> >>> doc= ument as a WG -00 as soon as it's convenient.

> >>>>=

> >>>>= RjS

> >>>>= >

> >>>>= > -----Original Message-----

> >>>>= > From: stir-bounces@ietf.or= g [mailto:stir-bounces@ietf.org]= On

> >>>>= > Behalf Of Russ Housley

> >>>>= > Sent: Thursday, September 26, 2013 4:37 PM

> >>>>= > To: IETF STIR Mail List

> >>>>= > Subject: Re: [stir] draft-peterson-stir-threats-00.txt

> >>>>= >

> >>>>= > It has been six days, I'd like to hear from more people about this

> >>> doc= ument.  Martin asked for an additional week, so I'm sure we will

> >>> hea= r from him soon.

> >>>>= >

> >>>>= > Russ

> >>>>= >

> >>>>= >

> >>>>= >> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote:

> >>>>= >>

> >>>>= >> http://www.ietf.org/= id/draft-peterson-stir-threats-00.txt

> >>>>= >>

> >>>>= >> Should the working group adopt this I-D as the starting point for<= /span>

> >>>>= >> the

> >>> STI= R threat docuent?

> >>>>= >>

> >>>>= >> Russ

> >>>>= > _______________________________________________

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

> >>> ___= ____________________________________________

> >>> sti= r mailing list

> >>> stir@ietf.org=

> >>> https://www.ietf.org= /mailman/listinfo/stir

> >>>

> >>> ___= ____________________________________________

> >>> sti= r mailing list

> >>> stir@ietf.org=

> >>> https://www.ietf.org= /mailman/listinfo/stir

> >> _______= ________________________________________

> >> stir ma= iling list

> >> stir@ietf.org=

> >> https://www.ietf.org= /mailman/listinfo/stir

> >

> > ___________= ____________________________________

> > stir mailin= g list

> > stir@ietf.org=

> > https://www.ietf.org= /mailman/listinfo/stir

>

> ________________= _______________________________

> stir mailing lis= t

> stir@ietf.org=

> https://www.ietf.org= /mailman/listinfo/stir



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_CE9EE40A2DA2Efmousinhciscocom_-- From alex@bobotek.net Tue Nov 5 17:20:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF25021E808F for ; Tue, 5 Nov 2013 17:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcwTeuFCt1rd for ; Tue, 5 Nov 2013 17:20:04 -0800 (PST) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id AC48711E811A for ; Tue, 5 Nov 2013 17:20:04 -0800 (PST) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta07.emeryville.ca.mail.comcast.net with comcast id m1F31m0011eYJf8A71L4HK; Wed, 06 Nov 2013 01:20:04 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by omta19.emeryville.ca.mail.comcast.net with comcast id m1L21m00C4EJ4tY011L2NH; Wed, 06 Nov 2013 01:20:03 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Tue, 5 Nov 2013 17:07:58 -0800 From: Alex Bobotek To: Andrew Allen , "Peterson, Jon" , 'Richard Shockey' , "'stir@ietf.org'" Date: Tue, 5 Nov 2013 17:07:57 -0800 Thread-Topic: [stir] comments on draft-ietf-stir-problem-statement-00 Thread-Index: Ac7QUSi+XuSwVM/UQPSEhXox+oZw/gJFOdUAABAW9ID//+tngIAAp9QAgABE4kf//50YUP/+upfA Message-ID: <4B1956260CD29F4A9622F00322FE0531D0FDE6C379@BOBO1A.bobotek.net> References: <596979554D802045BBD45C051A4399E40D40A87A@STNTEXMB10.cis.neustar.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4B1956260CD29F4A9622F00322FE0531D0FDE6C379BOBO1Abobotek_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383700804; bh=AGwDRAleMM9+q9fy8iWz9fxe8kCs2Zhi9I7b9NJjUIk=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=P/EvVvkDSV9FgVqTVsApDFuSVear9cLXu9FkcrbeC8lFZNbcxXHQ5kAnOITxlic8j 0E/TugVAVoActBKjjE6ict33qZHIgtDwqXlhMogH0ZB5xcmsPRs4a+xFH03dEWIXEu wn5PKdLdhRuJ0n/Cf5E/I3kuFeGeyvRYn50fC24u1x+q8m0iq4MJMRqA9EQs26T7PD bkhldzqE3J/uzhaTbQZUnuFOTvTpIjcMO16c4ti1szzB4cNoP01OCKZfZPREo+6qRC Oukg+GNdrAydyosfB4u1OC1eL9jPka+C6+Y53lW6oteIUL2WZZ7SyuSOKoOjZSkWW6 SHhQp4YXzDUuQ== Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:20:42 -0000 --_000_4B1956260CD29F4A9622F00322FE0531D0FDE6C379BOBO1Abobotek_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIOKAnHJhdGhlciB0aGFuIG92ZXIgdGhlIFBTVE7igJ0gYW5kIOKAnG91dCBvZiBiYW5kIGNv bm5lY3Rpb27igJ0gcGFydHMgY291bGQgYmUgaW1wcm92ZWQuDQoNCg0KMS4gICAgICAgIE1vYmls ZSB0ZXh0IG1lc3NhZ2luZyBpbiBtYW55IGNvdW50cmllcyAoZS5nLiwgTm9ydGggQW1lcmljYW4p IGRvZXNu4oCZdCB0b3VjaCB0aGUgUFNUTi4gIEl0IGdvZXMgb3ZlciBwcml2YXRlIHNpZ25hbGlu ZyBhbmQgSVAgbmV0d29ya3MsIHNvbWV0aW1lcyB0dW5uZWxlZCB0aHJvdWdoIHRoZSBJbnRlcm5l dC4gIFN1Z2dlc3Rpb246ICBzdHJpa2Ug4oCcIHJhdGhlciB0aGFuIG92ZXIgdGhlIFBTVE7igJ0u DQoNCjIuICAgICAgIE1hbnkgb2YgdGhlIGxpc3RlZCBJUCB0ZXh0IG1lc3NhZ2luZyBzZXJ2aWNl cyBkbyBub3QgY3JlYXRlIGVuZC10by1lbmQgTDQgY29ubmVjdGlvbnMgb3IgTDUrIGVuZHVyaW5n IHNlc3Npb25zL2RpYWxvZ3MgKGUuZy4sIFJGQyAzNDI44oCZcyBNRVNTQUdFIGRvZXMgbm90IHJl cXVpcmUgYSBTSVAgZGlhbG9nIGJldHdlZW4gbWVzc2FnaW5nIGVuZHBvaW50cykuICBJdOKAmXMg bm90IGNsZWFyIHRvIG1lIHdoZXRoZXIgdGhlIHRlcm0g4oCcY29ubmVjdGlvbuKAnSBpcyBpbXBy ZWNpc2UsIG9yIHRoZXJlIGlzIGFub3RoZXIgaXNzdWUuIFNpbWlsYXJseSwgSSBkb27igJl0IHVu ZGVyc3RhbmQgd2h5IGlNZXNzYWdlIGFuZCBzaW1pbGFyIHNob3VsZCBiZSBjb25zaWRlcmVkIG91 dCBvZiBiYW5kLiAgVG8gbWUsIOKAnG91dCBvZiBiYW5k4oCdIG1lYW5zIG91dHNpZGUgb2YgYW4g ZXN0YWJsaXNoZWQgcHJpbWFyeSBjb21tdW5pY2F0aW9ucyBjaGFubmVsLiAgU3VnZ2VzdGlvbjog IHVzZSB0aGUgYWNjZXB0ZWQgaW5kdXN0cnkgdGVybSDigJxvdmVyIHRoZSB0b3DigJ0gaW5zdGVh ZCBvZiDigJxvdXQtb2YtYmFuZOKAnSBhbmQgc29tZSBwcm9wZXJseSBhbWJpZ3VvdXMgdGVybSBz dWNoIGFzIOKAnGNvbW11bmljYXRpb25zIHBhdGjigJ0gaW5zdGVhZCBvZiDigJxjb25uZWN0aW9u 4oCdLg0KDQpSZWdhcmRzLA0KDQpBbGV4DQouDQoNCg0KRnJvbTogc3Rpci1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmV3IEFs bGVuDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAwNSwgMjAxMyA4OjQ1IEFNDQpUbzogUGV0ZXJz b24sIEpvbjsgJ1JpY2hhcmQgU2hvY2tleSc7ICdzdGlyQGlldGYub3JnJw0KU3ViamVjdDogUmU6 IFtzdGlyXSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDAN Cg0KDQpKb24NCg0KSSBoYXZlIG5vdCB1c2VkIGlNZXNzYWdlIHNvIHVzaW5nIGl0IGFzIGFuIGV4 YW1wbGUgZG9lc27igJl0IGhlbHAgbWUgb3IgdGhlIGxhcmdlIGNvbW11bml0eSBvZiBub24gaVBo b25lIHVzZXJzIG91dCB0aGVyZSB0byB1bmRlcnN0YW5kLiBJIGhhdmUgaG93ZXZlciB1c2VkIFdo YXRzQXBwLCBCbGFja0JlcnJ5IE1lc3NlbmdlciBhbmQgVmliZXIg4oCTIGFsbCBvZiB3aGljaCBh cmUgdmVyeSBwb3B1bGFyIG1lc3NhZ2luZyBzZXJ2aWNlcy4gV2VDaGF0IGlzIGFub3RoZXIgbWVz c2FnaW5nIHNlcnZpY2VzIHRoYXQgaXMgYWxzbyBleHRyZW1lbHkgcG9wdWxhciBpbiBDaGluYSBh bmQgbWFueSBvdGhlciBBc2lhbiBjb3VudHJpZXMuDQoNCkkgZG9u4oCZdCBzZWUgYW55dGhpbmcg c3BlY2lhbCBhYm91dCBpTWVzc2FnZSDigJMgb3RoZXIgc2VydmljZXMgaGF2ZSBtb3JlIHVzZXJz LCBoYXZlIG11bHRpLXBsYXRmb3JtIHN1cHBvcnQgb3IgaGF2ZSBiZWVuIGFyb3VuZCBsb25nIGJl Zm9yZSBpUGhvbmUgd2FzIGEgZ2xlYW0gaW4gdGhlIFN0ZXZlIEpvYnPigJkgZXllIGFuZCBhbGwg cHJvdmlkZSBhbiBvdXQgb2YgYmFuZCBjb25uZWN0aW9uLg0KDQpNeSBwcm9wb3NhbCBpcyB0byBy ZXdyaXRlIHRoZSB0ZXh0IGFzIGZvbGxvd3M6DQoNCg0KRm9yIGV4YW1wbGUsIHRoZSBBcHBsZSBp TWVzc2FnZSBzZXJ2aWNlLCB3aGljaCBhbGxvd3MgaVBob25lIHVzZXJzIHRvIHNlbmQgU01TIG1l c3NhZ2VzIHRvIG9uZSBhbm90aGVyIG92ZXIgdGhlIEludGVybmV0IHJhdGhlciB0aGFuIG92ZXIg dGhlIFBTVE4uICBMaWtlIFZJUFIsIGlNZXNzYWdlIGNyZWF0ZXMgYW4gb3V0LW9mLWJhbmQgY29u bmVjdGlvbiBvdmVyIHRoZSBJbnRlcm5ldCBiZXR3ZWVuIGlQaG9uZXM7IHVubGlrZSBWSVBSLCB0 aGUgcmVuZGV6dm91cyBzZXJ2aWNlIGlzIHByb3ZpZGVkIGJ5IGEgdHJ1c3RlZCBjZW50cmFsaXpl ZCBkYXRhYmFzZSBvZiBpUGhvbmVzIHJhdGhlciB0aGFuIGJ5IGEgREhULiAgV2hpbGUgQXBwbGUn cyBzZXJ2aWNlIGlzIHNwZWNpZmljIHRvIGN1c3RvbWVycyBvZiBpdHMgc21hcnQgcGhvbmVzLCBp dCBzZWVtcyBjbGVhciB0aGF0IHNpbWlsYXIgZGF0YWJhc2VzIGNvdWxkIGJlIHByb3ZpZGVkIGJ5 IG5ldXRyYWwgdGhpcmQgcGFydGllcyBpbiBhIHBvc2l0aW9uIHRvIGNvb3JkaW5hdGUgYmV0d2Vl biBlbmRwb2ludHMuDQoNClJFV1JJVEUgQVM6DQoNCk1vYmlsZSBtZXNzYWdpbmcgc2VydmljZXMs IChlLmcuIFdoYXRzYXBwLCBWaWJlciwgQmxhY2tCZXJyeSBNZXNzZW5nZXIsIEFwcGxl4oCZcyBp TWVzc2FnZSBhbmQgV2VDaGF0KSwgYWxsb3cgc21hcnQgcGhvbmUgdXNlcnMgdG8gc2VuZCB0ZXh0 IG1lc3NhZ2VzIHRvIG9uZSBhbm90aGVyIG92ZXIgdGhlIEludGVybmV0IHJhdGhlciB0aGFuIG92 ZXIgdGhlIFBTVE4uICBMaWtlIFZJUFIsIHN1Y2ggc2VydmljZXMgY3JlYXRlIGFuIG91dC1vZi1i YW5kIGNvbm5lY3Rpb24gb3ZlciB0aGUgSW50ZXJuZXQgYmV0d2VlbiBzbWFydCBwaG9uZXM7IHVu bGlrZSBWSVBSLCB0aGUgcmVuZGV6dm91cyBzZXJ2aWNlIGlzIHByb3ZpZGVkIGJ5IGEgdHJ1c3Rl ZCBjZW50cmFsaXplZCBkYXRhYmFzZSByYXRoZXIgdGhhbiBieSBhIERIVC4gIFdoaWxlIHN1Y2gg bWVzc2FnaW5nIHNlcnZpY2VzIGFyZSBzcGVjaWZpYyB0byB0aGUgdXNlcnMgb2YgdGhlIHNwZWNp ZmljIHNlcnZpY2UsIGl0IHNlZW1zIGNsZWFyIHRoYXQgc2ltaWxhciBkYXRhYmFzZXMgY291bGQg YmUgcHJvdmlkZWQgYnkgbmV1dHJhbCB0aGlyZCBwYXJ0aWVzIGluIGEgcG9zaXRpb24gdG8gY29v cmRpbmF0ZSBiZXR3ZWVuIGVuZHBvaW50cy4NCg0KDQpBbmRyZXcNCg0KRnJvbTogUGV0ZXJzb24s IEpvbiBbbWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpel0NClNlbnQ6IE1vbmRheSwgTm92 ZW1iZXIgMDQsIDIwMTMgOToyMCBQTQ0KVG86ICdSaWNoYXJkIFNob2NrZXknOyBBbmRyZXcgQWxs ZW47ICdzdGlyQGlldGYub3JnJw0KU3ViamVjdDogUkU6IFtzdGlyXSBjb21tZW50cyBvbiBkcmFm dC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDANCg0KV2VsbC4gTWF5YmUgSSB1bmRlcnN0 b29kIEFuZHJldydzIG1lc3NhZ2UgYSBiaXQgZGlmZmVyZW50bHkgdGhhbiB5b3UgZGlkLiBXaGF0 IGhlIG9yaWdpbmFsbHkgYXNrZWQgd2FzIHRoYXQgc2VydmljZXMgbGlrZSBCbGFja2JlcnJ5IE1l c3NlbmdlciAoYWxzbyBhbiBvdXQtb2YtYmFuZCBzZXJ2aWNlIGxpa2UgaU1lc3NhZ2UpIGJlIGlu Y2x1ZGVkIHNvIHdlIGRvbid0IGFwcGVhciB0byBiZSBmYXZvcmluZyB0aGUgd29yayBvZiBhIHNp bmdsZSBtb25vbGl0aGljIHZlbmRvci4gSGUgdGhlbiBhc2tlZCB0aGF0IHdlIHJlZmVyZW5jZSBz b21ldGhpbmcgbGlrZSBXaGF0c2FwcCwgYSBwbGF0Zm9ybS1uZXV0cmFsIHNlcnZpY2UgYWxvbmcg dGhlc2UgbGluZXMuIEkgaGF2ZW4ndCBvYmplY3RlZCB0byBlaXRoZXIgb2YgdGhvc2UgcmVxdWVz dHMuIEJ1dCB0aGUgc3VnZ2VzdGlvbiB0aGF0IHdlIHJlc3RyaWN0IHRoaXMgc2VjdGlvbiB0byBz b21lIG90aGVyIHZlbmRvcidzIHNvbHV0aW9uIHdoaWxlIHJlbW92aW5nIHRoZSBvbmUgd2l0aCB3 aGljaCBwZW9wbGUgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0gYXJlIG1vc3QgZmFt aWxpYXIgd291bGQsIEkgdGhpbmssIGJlIGEgZGlmZmVyZW50IG1hdHRlci4NCg0KVGhlIG9iamVj dGl2ZSBvZiB0aGlzIGRvY3VtZW50IGlzIG5vdCB0byBwcm9tb3RlIGFueSBzb2x1dGlvbiwgaXQn cyBhIHByb2JsZW0gc3RhdGVtZW50IGRvY3VtZW50LiBXaGF0ZXZlciB3ZSByZWZlcmVuY2UgaGVy ZSBpcyBlbnRpcmVseSBleGVtcGxhcnkgYW5kIGV4cGxpY2l0bHkgbm90IGEgY29tcG9uZW50IG9m IHRoZSBTVElSIHNvbHV0aW9uLiBXaGlsZSB3ZSBjYW4gYWxsIHNlZSB0aGUgdmVoZW1lbmNlIG9m IHlvdXIgcGVyc29uYWwgb2JqZWN0aW9uLCBJIGFtIG5vdCBzZWVpbmcgYW55IHJhdGlvbmFsIHJl YXNvbiBoZXJlIHRvIHN0cmlrZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBkb2N1bWVudCB0aGF0IGFj dHVhbGx5IGhlbHBzIHBlb3BsZSB0byB1bmRlcnN0YW5kIHdoYXQgdGhpcyB3b3JrIGlzIGFib3V0 LiBOb3IgZG8gSSB0aGluayB5b3VyIGN1cmlvdXMgY29uc3RydWFsIG9mIEFuZHJldydzIChhY3R1 YWxseSBxdWl0ZSByZWFzb25hYmxlKSByZXF1ZXN0LCB3aGVuIGNvbWJpbmVkIHdpdGggeW91ciBv d24gbW9yZSBvYnNjdXJlIGNvbXBsYWludCwganVzdGlmaWVzIGlzc3VpbmcgYmxhbmtldCBjb21t YW5kcyBhcyB5b3UgZG8gYmVsb3cuIFdoeSBkb24ndCB3ZSBsZWF2ZSBpdCB0byB0aGUgY2hhaXJz IHRvIGFzc2VzcyBjb25zZW5zdXMuDQoNCkpvbiBQZXRlcnNvbg0KTmV1c3RhciwgSW5jLg0KDQoN Cg0KU2VudCB3aXRoIEdvb2QgKHd3dy5nb29kLmNvbTxodHRwOi8vd3d3Lmdvb2QuY29tPikNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmljaGFyZCBTaG9ja2V5IFtyaWNo YXJkQHNob2NrZXkudXM8bWFpbHRvOnJpY2hhcmRAc2hvY2tleS51cz5dDQpTZW50OiBNb25kYXks IE5vdmVtYmVyIDA0LCAyMDEzIDA4OjI3IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IFBl dGVyc29uLCBKb247ICdBbmRyZXcgQWxsZW4nOyBzdGlyQGlldGYub3JnPG1haWx0bzpzdGlyQGll dGYub3JnPg0KU3ViamVjdDogUkU6IFtzdGlyXSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXN0aXIt cHJvYmxlbS1zdGF0ZW1lbnQtMDANCg0KSm9uIC4uIHdoYXQgYWJvdXQgTk8gZG9u4oCZdCB5b3Ug dW5kZXJzdGFuZC4NCg0KV2Ugb2JqZWN0IHRvIHRoZSByZWZlcmVuY2VzLiBSZW1vdmUgdGhlbSBu b3cuDQoNCkZyb206IHN0aXItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3Rpci1ib3VuY2VzQGll dGYub3JnPiBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBldGVy c29uLCBKb24NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDQsIDIwMTMgNjoyNiBQTQ0KVG86IEFu ZHJldyBBbGxlbjsgc3RpckBpZXRmLm9yZzxtYWlsdG86c3RpckBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbc3Rpcl0gY29tbWVudHMgb24gZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50 LTAwDQoNCjxBQT5JIGRvbuKAmXQgdGhpbmsganVzdCB0aGUgZmFjdCB0aGF0IHNvbWUgcGVvcGxl IGhhcHBlbiB0byBiZSBmYW1pbGlhciB3aXRoIGlNZXNzYWdlIGlzIHN1ZmZpY2llbnQganVzdGlm aWNhdGlvbiB0byBtYWtlIGl0IGEgZ29vZCBleGFtcGxlIHRvIHVzZSBpbiB0aGUgZHJhZnQg4oCT IHBhcnRpY3VsYXJseSBzaW5jZSBpdCBoYXMgc2hvcnQgY29taW5ncyBzdWNoIGFzIGJlaW5nIGN1 cnJlbnRseSByZXN0cmljdGVkIHRvIGEgc2luZ2xlIHBsYXRmb3JtLiBJIGJlbGlldmUgV2hhdHNh cHAgaGFzIHRoZSBtb3N0IHVzZXLigJlzIGFuZCBhbHNvIGhhcyBtdWx0aSB2ZW5kb3Igc3VwcG9y dC4gSSBzdXBwb3NlIGEgbGlzdCBvZiBlLmfigJlzIGlzIE9LIGJ1dCBJIGRvbuKAmXQgc2VlIHdo eSB3ZSBuZWVkIHRvIGRlc2NyaWJlIGluIGFueSBkZXRhaWwgYSBzcGVjaWZpYyBzZXJ2aWNlIOKA kyBzaW5jZSBtb3N0IG9mIHRoZW0gaGF2ZSBzaW1pbGFyIGNoYXJhY3RlcmlzdGljcy48L0FBPg0K DQpJIHRoaW5rIHRoZSBmYWN0IHRoYXQgcGVvcGxlIGFyZSBmYW1pbGlhciB3aXRoIGlNZXNzYWdl IGlzIGEgdmVyeSBnb29kIHJlYXNvbiB0byBsaXN0IGl0IGFzIG9uZSBleGFtcGxlLiBJJ20gaGFw cHkgdG8gaW5jbHVkZSBvdGhlciBleGFtcGxlcywgaW5jbHVkaW5nIFdoYXRzYXBwLiBJIHdvdWxk IGFsc28gYmUgaGFwcHkgdG8gbWFrZSB0aGUgZGVzY3JpcHRpdmUgdGV4dCB0aGVyZSBsZXNzIHNw ZWNpZmljIHRvIGFueSBwYXJ0aWN1bGFyIHZlbmRvciwgYnV0IEkgZG8gaGF2ZSBhIGhhcmQgdGlt ZSBzZWVpbmcgaG93IGxpc3RpbmcgaU1lc3NhZ2UgaGVyZSB3b3VsZCBtYWtlIHBlb3BsZSBtaXN1 bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHN0YXRlbWVudC4NCg0KW0FBXSBNeSBwcm9ibGVtIGlzIHdp dGggdGhlIHN0YXRlbWVudCDigJxkb21haW5zIHRoYXQgaGF2ZSBubyByZWxhdGlvbnNoaXAgd2l0 aCB0aGUgbnVtYmVyIGFzc2lnbmVl4oCdIENlcnRhaW5seSB0aGV5IGhhdmUgYSByZWxhdGlvbnNo aXAg4oCTIGluIGZhY3QgYSBjbG9zZSBhbmQgdHJ1c3RlZCBvbmUgYW5kIHRoZSBob21lIGRvbWFp biBwcm92aWRlcyB0aGUgbnVtYmVyIHRvIGFzc2VydCB0byB0aGUgcm9hbWVkIHRvIGRvbWFpbi4g IFNvIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgbWFkZSBjbGVhcmVyLg0KDQoNCg0KDQpPa2F5LCBw ZXIgdGhlIHRleHQgSSBzZW50IGluIG15IGxhc3QgbWFpbCwgd2UgY2FuIG1ha2UgdGhpcyBjbGVh cmVyLiBBZ2Fpbiwgd2hhdCB0aGlzIG1lYW5zIGZvciBTVElSIGlzIHRoYXQgdGhlIHRoZSByb2Ft aW5nIGNhcnJpZXIgd29uJ3QgaGF2ZSB0aGUgYXV0aG9yaXR5IG92ZXIgdGhlIG51bWJlci4NCg0K Sm9uIFBldGVyc29uDQpOZXVzdGFyLCBJbmMuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21p c3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHBy b3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZp bGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2Yg dGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9u IGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9u LCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1 bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1 bC4NCg== --_000_4B1956260CD29F4A9622F00322FE0531D0FDE6C379BOBO1Abobotek_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTcyMzc2OTM3Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTM2ODExNzQ4MCA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlRoZSDigJxyYXRoZXIgdGhhbiBvdmVyIHRoZSBQ U1RO4oCdIGFuZCDigJxvdXQgb2YgYmFuZCBjb25uZWN0aW9u4oCdIHBhcnRzIGNvdWxkIGJlIGlt cHJvdmVkLsKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4xLjxzcGFuIHN0eWxlPSdmb250Ojcu MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz7CoE1vYmlsZSB0ZXh0IG1lc3NhZ2luZyBpbiBtYW55IGNvdW50cmllcyAoZS5nLiwgTm9y dGggQW1lcmljYW4pIGRvZXNu4oCZdCB0b3VjaCB0aGUgUFNUTi7CoCBJdCBnb2VzIG92ZXIgcHJp dmF0ZSBzaWduYWxpbmcgYW5kIElQIG5ldHdvcmtzLCBzb21ldGltZXMgdHVubmVsZWQgdGhyb3Vn aCB0aGUgSW50ZXJuZXQuIMKgU3VnZ2VzdGlvbjrCoCBzdHJpa2Ug4oCcIHJhdGhlciB0aGFuIG92 ZXIgdGhlIFBTVE7igJ0uwqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQ YXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxzcGFu IHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjIuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPk1hbnkg b2YgdGhlIGxpc3RlZCBJUCB0ZXh0IG1lc3NhZ2luZyBzZXJ2aWNlcyBkbyBub3QgY3JlYXRlIGVu ZC10by1lbmQgTDQgY29ubmVjdGlvbnMgb3IgTDUrIGVuZHVyaW5nIHNlc3Npb25zL2RpYWxvZ3Mg KGUuZy4sIFJGQyAzNDI44oCZcyBNRVNTQUdFIGRvZXMgbm90IHJlcXVpcmUgYSBTSVAgZGlhbG9n IGJldHdlZW4gbWVzc2FnaW5nIGVuZHBvaW50cykuwqAgSXTigJlzIG5vdCBjbGVhciB0byBtZSB3 aGV0aGVyIHRoZSB0ZXJtIOKAnGNvbm5lY3Rpb27igJ0gaXMgaW1wcmVjaXNlLCBvciB0aGVyZSBp cyBhbm90aGVyIGlzc3VlLiBTaW1pbGFybHksIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBpTWVz c2FnZSBhbmQgc2ltaWxhciBzaG91bGQgYmUgY29uc2lkZXJlZCBvdXQgb2YgYmFuZC7CoCBUbyBt ZSwg4oCcb3V0IG9mIGJhbmTigJ0gbWVhbnMgb3V0c2lkZSBvZiBhbiBlc3RhYmxpc2hlZCBwcmlt YXJ5IGNvbW11bmljYXRpb25zIGNoYW5uZWwuwqAgU3VnZ2VzdGlvbjrCoCB1c2UgdGhlIGFjY2Vw dGVkIGluZHVzdHJ5IHRlcm0g4oCcb3ZlciB0aGUgdG9w4oCdIGluc3RlYWQgb2Yg4oCcb3V0LW9m LWJhbmTigJ0gYW5kIHNvbWUgcHJvcGVybHkgYW1iaWd1b3VzIHRlcm0gc3VjaCBhcyDigJxjb21t dW5pY2F0aW9ucyBwYXRo4oCdIGluc3RlYWQgb2Yg4oCcY29ubmVjdGlvbuKAnS7CoCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPkFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz4uwqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjI1aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1N c29Ob3JtYWw+PGI+RnJvbTo8L2I+IHN0aXItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0aXIt Ym91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5BbmRyZXcgQWxsZW48YnI+PGI+ U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDA1LCAyMDEzIDg6NDUgQU08YnI+PGI+VG86PC9i PiBQZXRlcnNvbiwgSm9uOyAnUmljaGFyZCBTaG9ja2V5JzsgJ3N0aXJAaWV0Zi5vcmcnPGJyPjxi PlN1YmplY3Q6PC9iPiBSZTogW3N0aXJdIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc3Rpci1wcm9i bGVtLXN0YXRlbWVudC0wMDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPkkgaGF2ZSBub3QgdXNlZCBpTWVzc2FnZSBzbyB1c2luZyBpdCBhcyBhbiBleGFt cGxlIGRvZXNu4oCZdCBoZWxwIG1lIG9yIHRoZSBsYXJnZSBjb21tdW5pdHkgb2Ygbm9uIGlQaG9u ZSB1c2VycyBvdXQgdGhlcmUgdG8gdW5kZXJzdGFuZC4gSSBoYXZlIGhvd2V2ZXIgdXNlZCBXaGF0 c0FwcCwgQmxhY2tCZXJyeSBNZXNzZW5nZXIgYW5kIFZpYmVyIOKAkyBhbGwgb2Ygd2hpY2ggYXJl IHZlcnkgcG9wdWxhciBtZXNzYWdpbmcgc2VydmljZXMuIFdlQ2hhdCBpcyBhbm90aGVyIG1lc3Nh Z2luZyBzZXJ2aWNlcyB0aGF0IGlzIGFsc28gZXh0cmVtZWx5IHBvcHVsYXIgaW4gQ2hpbmEgYW5k IG1hbnkgb3RoZXIgQXNpYW4gY291bnRyaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PkkgZG9u4oCZdCBzZWUgYW55dGhpbmcgc3BlY2lhbCBhYm91dCBpTWVzc2FnZSDigJMgb3RoZXIg c2VydmljZXMgaGF2ZSBtb3JlIHVzZXJzLCBoYXZlIG11bHRpLXBsYXRmb3JtIHN1cHBvcnQgb3Ig aGF2ZSBiZWVuIGFyb3VuZCBsb25nIGJlZm9yZSBpUGhvbmUgd2FzIGEgZ2xlYW0gaW4gdGhlIFN0 ZXZlIEpvYnPigJkgZXllIGFuZCBhbGwgcHJvdmlkZSBhbiBvdXQgb2YgYmFuZCBjb25uZWN0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPk15IHByb3Bvc2FsIGlzIHRvIHJld3JpdGUg dGhlIHRleHQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkZvciBleGFtcGxlLCB0aGUg QXBwbGUgaU1lc3NhZ2Ugc2VydmljZSwgd2hpY2ggYWxsb3dzIGlQaG9uZSB1c2VycyB0byBzZW5k IFNNUyBtZXNzYWdlcyB0byBvbmUgYW5vdGhlciBvdmVyIHRoZSBJbnRlcm5ldCByYXRoZXIgdGhh biBvdmVyIHRoZSBQU1ROLiZuYnNwOyBMaWtlIFZJUFIsIGlNZXNzYWdlIGNyZWF0ZXMgYW4gb3V0 LW9mLWJhbmQgY29ubmVjdGlvbiBvdmVyIHRoZSBJbnRlcm5ldCBiZXR3ZWVuIGlQaG9uZXM7IHVu bGlrZSBWSVBSLCB0aGUgcmVuZGV6dm91cyBzZXJ2aWNlIGlzIHByb3ZpZGVkIGJ5IGEgdHJ1c3Rl ZCBjZW50cmFsaXplZCBkYXRhYmFzZSBvZiBpUGhvbmVzIHJhdGhlciB0aGFuIGJ5IGEgREhULiZu YnNwOyBXaGlsZSBBcHBsZSdzIHNlcnZpY2UgaXMgc3BlY2lmaWMgdG8gY3VzdG9tZXJzIG9mIGl0 cyBzbWFydCBwaG9uZXMsIGl0IHNlZW1zIGNsZWFyIHRoYXQgc2ltaWxhciBkYXRhYmFzZXMgY291 bGQgYmUgcHJvdmlkZWQgYnkgbmV1dHJhbCB0aGlyZCBwYXJ0aWVzIGluIGEgcG9zaXRpb24gdG8g Y29vcmRpbmF0ZSBiZXR3ZWVuIGVuZHBvaW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz5SRVdSSVRFIEFTOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+TW9iaWxlIG1lc3NhZ2luZyBzZXJ2aWNlcywgKGUuZy4gV2hhdHNhcHAs IFZpYmVyLCBCbGFja0JlcnJ5IE1lc3NlbmdlciwgQXBwbGXigJlzIGlNZXNzYWdlIGFuZCBXZUNo YXQpLCBhbGxvdyBzbWFydCBwaG9uZSB1c2VycyB0byBzZW5kIHRleHQgbWVzc2FnZXMgdG8gb25l IGFub3RoZXIgb3ZlciB0aGUgSW50ZXJuZXQgcmF0aGVyIHRoYW4gb3ZlciB0aGUgUFNUTi4mbmJz cDsgTGlrZSBWSVBSLCBzdWNoIHNlcnZpY2VzIGNyZWF0ZSBhbiBvdXQtb2YtYmFuZCBjb25uZWN0 aW9uIG92ZXIgdGhlIEludGVybmV0IGJldHdlZW4gc21hcnQgcGhvbmVzOyB1bmxpa2UgVklQUiwg dGhlIHJlbmRlenZvdXMgc2VydmljZSBpcyBwcm92aWRlZCBieSBhIHRydXN0ZWQgY2VudHJhbGl6 ZWQgZGF0YWJhc2UgcmF0aGVyIHRoYW4gYnkgYSBESFQuJm5ic3A7IFdoaWxlIHN1Y2ggbWVzc2Fn aW5nIHNlcnZpY2VzIGFyZSBzcGVjaWZpYyB0byB0aGUgdXNlcnMgb2YgdGhlIHNwZWNpZmljIHNl cnZpY2UsIGl0IHNlZW1zIGNsZWFyIHRoYXQgc2ltaWxhciBkYXRhYmFzZXMgY291bGQgYmUgcHJv dmlkZWQgYnkgbmV1dHJhbCB0aGlyZCBwYXJ0aWVzIGluIGEgcG9zaXRpb24gdG8gY29vcmRpbmF0 ZSBiZXR3ZWVuIGVuZHBvaW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz5BbmRyZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Iic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFBldGVyc29uLCBKb24gWzxhIGhyZWY9Im1haWx0 bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXoiPm1haWx0bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5i aXo8L2E+XSA8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMDQsIDIwMTMgOToyMCBQ TTxicj48Yj5Ubzo8L2I+ICdSaWNoYXJkIFNob2NrZXknOyBBbmRyZXcgQWxsZW47ICdzdGlyQGll dGYub3JnJzxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtzdGlyXSBjb21tZW50cyBvbiBkcmFmdC1p ZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPldlbGwuIE1h eWJlIEkgdW5kZXJzdG9vZCBBbmRyZXcncyBtZXNzYWdlIGEgYml0IGRpZmZlcmVudGx5IHRoYW4g eW91IGRpZC4gV2hhdCBoZSBvcmlnaW5hbGx5IGFza2VkIHdhcyB0aGF0IHNlcnZpY2VzIGxpa2Ug QmxhY2tiZXJyeSBNZXNzZW5nZXIgKGFsc28gYW4gb3V0LW9mLWJhbmQgc2VydmljZSBsaWtlIGlN ZXNzYWdlKSBiZSBpbmNsdWRlZCBzbyB3ZSBkb24ndCBhcHBlYXIgdG8gYmUgZmF2b3JpbmcgdGhl IHdvcmsgb2YgYSBzaW5nbGUgbW9ub2xpdGhpYyB2ZW5kb3IuIEhlIHRoZW4gYXNrZWQgdGhhdCB3 ZSByZWZlcmVuY2Ugc29tZXRoaW5nIGxpa2UgV2hhdHNhcHAsIGEgcGxhdGZvcm0tbmV1dHJhbCBz ZXJ2aWNlIGFsb25nIHRoZXNlIGxpbmVzLiBJIGhhdmVuJ3Qgb2JqZWN0ZWQgdG8gZWl0aGVyIG9m IHRob3NlIHJlcXVlc3RzLiBCdXQgdGhlIHN1Z2dlc3Rpb24gdGhhdCB3ZSByZXN0cmljdCB0aGlz IHNlY3Rpb24gdG8gc29tZSBvdGhlciB2ZW5kb3IncyBzb2x1dGlvbiB3aGlsZSByZW1vdmluZyB0 aGUgb25lIHdpdGggd2hpY2ggcGVvcGxlIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBwcm9ibGVt IGFyZSBtb3N0IGZhbWlsaWFyIHdvdWxkLCBJIHRoaW5rLCBiZSBhIGRpZmZlcmVudCBtYXR0ZXIu PGJyPjxicj5UaGUgb2JqZWN0aXZlIG9mIHRoaXMgZG9jdW1lbnQgaXMgbm90IHRvIHByb21vdGUg YW55IHNvbHV0aW9uLCBpdCdzIGEgcHJvYmxlbSBzdGF0ZW1lbnQgZG9jdW1lbnQuIFdoYXRldmVy IHdlIHJlZmVyZW5jZSBoZXJlIGlzIGVudGlyZWx5IGV4ZW1wbGFyeSBhbmQgZXhwbGljaXRseSBu b3QgYSBjb21wb25lbnQgb2YgdGhlIFNUSVIgc29sdXRpb24uIFdoaWxlIHdlIGNhbiBhbGwgc2Vl IHRoZSB2ZWhlbWVuY2Ugb2YgeW91ciBwZXJzb25hbCBvYmplY3Rpb24sIEkgYW0gbm90IHNlZWlu ZyBhbnkgcmF0aW9uYWwgcmVhc29uIGhlcmUgdG8gc3RyaWtlIGluZm9ybWF0aW9uIGZyb20gdGhl IGRvY3VtZW50IHRoYXQgYWN0dWFsbHkgaGVscHMgcGVvcGxlIHRvIHVuZGVyc3RhbmQgd2hhdCB0 aGlzIHdvcmsgaXMgYWJvdXQuIE5vciBkbyBJIHRoaW5rIHlvdXIgY3VyaW91cyBjb25zdHJ1YWwg b2YgQW5kcmV3J3MgKGFjdHVhbGx5IHF1aXRlIHJlYXNvbmFibGUpIHJlcXVlc3QsIHdoZW4gY29t YmluZWQgd2l0aCB5b3VyIG93biBtb3JlIG9ic2N1cmUgY29tcGxhaW50LCBqdXN0aWZpZXMgaXNz dWluZyBibGFua2V0IGNvbW1hbmRzIGFzIHlvdSBkbyBiZWxvdy4gV2h5IGRvbid0IHdlIGxlYXZl IGl0IHRvIHRoZSBjaGFpcnMgdG8gYXNzZXNzIGNvbnNlbnN1cy48YnI+PGJyPkpvbiBQZXRlcnNv bjxicj5OZXVzdGFyLCBJbmMuPGJyPjxicj48YnI+PGJyPlNlbnQgd2l0aCBHb29kICg8YSBocmVm PSJodHRwOi8vd3d3Lmdvb2QuY29tIj53d3cuZ29vZC5jb208L2E+KTxicj48YnI+PGJyPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPjxiPkZyb206Jm5ic3A7PC9iPlJpY2hhcmQgU2hvY2tl eSBbPGEgaHJlZj0ibWFpbHRvOnJpY2hhcmRAc2hvY2tleS51cyI+cmljaGFyZEBzaG9ja2V5LnVz PC9hPl08YnI+PGI+U2VudDombmJzcDs8L2I+TW9uZGF5LCBOb3ZlbWJlciAwNCwgMjAxMyAwODoy NyBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWU8YnI+PGI+VG86Jm5ic3A7PC9iPlBldGVyc29uLCBK b247ICdBbmRyZXcgQWxsZW4nOyA8YSBocmVmPSJtYWlsdG86c3RpckBpZXRmLm9yZyI+c3RpckBp ZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDombmJzcDs8L2I+UkU6IFtzdGlyXSBjb21tZW50cyBv biBkcmFmdC1pZXRmLXN0aXItcHJvYmxlbS1zdGF0ZW1lbnQtMDA8YnI+PGJyPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PkpvbiAuLiB3aGF0IGFib3V0IE5PIGRvbuKAmXQgeW91IHVuZGVyc3RhbmQuJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2Ugb2JqZWN0IHRvIHRoZSByZWZlcmVuY2VzLiBSZW1v dmUgdGhlbSBub3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+ PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj5Gcm9tOjwvYj4g PGEgaHJlZj0ibWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZyI+c3Rpci1ib3VuY2VzQGlldGYu b3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnN0 aXItYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZjwvYj4gUGV0ZXJzb24sIEpv bjxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAwNCwgMjAxMyA2OjI2IFBNPGJyPjxi PlRvOjwvYj4gQW5kcmV3IEFsbGVuOyA8YSBocmVmPSJtYWlsdG86c3RpckBpZXRmLm9yZyI+c3Rp ckBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbc3Rpcl0gY29tbWVudHMgb24g ZHJhZnQtaWV0Zi1zdGlyLXByb2JsZW0tc3RhdGVtZW50LTAwPG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbHQ7QUEmZ3Q7SSBkb27i gJl0IHRoaW5rIGp1c3QgdGhlIGZhY3QgdGhhdCBzb21lIHBlb3BsZSBoYXBwZW4gdG8gYmUgZmFt aWxpYXIgd2l0aCBpTWVzc2FnZSBpcyBzdWZmaWNpZW50IGp1c3RpZmljYXRpb24gdG8gbWFrZSBp dCBhIGdvb2QgZXhhbXBsZSB0byB1c2UgaW4gdGhlIGRyYWZ0IOKAkyBwYXJ0aWN1bGFybHkgc2lu Y2UgaXQgaGFzIHNob3J0IGNvbWluZ3Mgc3VjaCBhcyBiZWluZyBjdXJyZW50bHkgcmVzdHJpY3Rl ZCB0byBhIHNpbmdsZSBwbGF0Zm9ybS4gSSBiZWxpZXZlIFdoYXRzYXBwIGhhcyB0aGUgbW9zdCB1 c2Vy4oCZcyBhbmQgYWxzbyBoYXMgbXVsdGkgdmVuZG9yIHN1cHBvcnQuIEkgc3VwcG9zZSBhIGxp c3Qgb2YgZS5n4oCZcyBpcyBPSyBidXQgSSBkb27igJl0IHNlZSB3aHkgd2UgbmVlZCB0byBkZXNj cmliZSBpbiBhbnkgZGV0YWlsIGEgc3BlY2lmaWMgc2VydmljZSDigJMgc2luY2UgbW9zdCBvZiB0 aGVtIGhhdmUgc2ltaWxhciBjaGFyYWN0ZXJpc3RpY3MuJmx0Oy9BQSZndDs8L3NwYW4+PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPkkgdGhpbmsgdGhlIGZhY3QgdGhhdCBwZW9wbGUgYXJlIGZhbWls aWFyIHdpdGggaU1lc3NhZ2UgaXMgYSB2ZXJ5IGdvb2QgcmVhc29uIHRvIGxpc3QgaXQgYXMgb25l IGV4YW1wbGUuIEknbSBoYXBweSB0byBpbmNsdWRlIG90aGVyIGV4YW1wbGVzLCBpbmNsdWRpbmcg V2hhdHNhcHAuIEkgd291bGQgYWxzbyBiZSBoYXBweSB0byBtYWtlIHRoZSBkZXNjcmlwdGl2ZSB0 ZXh0IHRoZXJlIGxlc3Mgc3BlY2lmaWMgdG8gYW55IHBhcnRpY3VsYXIgdmVuZG9yLCBidXQgSSBk byBoYXZlIGEgaGFyZCB0aW1lIHNlZWluZyBob3cgbGlzdGluZyBpTWVzc2FnZSBoZXJlIHdvdWxk IG1ha2UgcGVvcGxlIG1pc3VuZGVyc3RhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5bQUFdIE15IHBy b2JsZW0gaXMgd2l0aCB0aGUgc3RhdGVtZW50IOKAnDwvc3Bhbj48aT48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPmRvbWFpbnMgdGhhdCBoYXZlIG5vIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBudW1i ZXIgYXNzaWduZWXigJ08L3NwYW4+PC9pPiA8c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Q2Vy dGFpbmx5IHRoZXkgaGF2ZSBhIHJlbGF0aW9uc2hpcCDigJMgaW4gZmFjdCBhIGNsb3NlIGFuZCB0 cnVzdGVkIG9uZSBhbmQgdGhlIGhvbWUgZG9tYWluIHByb3ZpZGVzIHRoZSBudW1iZXIgdG8gYXNz ZXJ0IHRvIHRoZSByb2FtZWQgdG8gZG9tYWluLiAmbmJzcDtTbyBJIHRoaW5rIGl0IG5lZWRzIHRv IGJlIG1hZGUgY2xlYXJlci48L3NwYW4+PG86cD48L286cD48L3A+PHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IDwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPk9rYXksIHBlciB0aGUgdGV4dCBJIHNlbnQgaW4gbXkgbGFzdCBtYWlsLCB3ZSBjYW4g bWFrZSB0aGlzIGNsZWFyZXIuIEFnYWluLCB3aGF0IHRoaXMgbWVhbnMgZm9yIFNUSVIgaXMgdGhh dCB0aGUgdGhlIHJvYW1pbmcgY2FycmllciB3b24ndCBoYXZlIHRoZSBhdXRob3JpdHkgb3ZlciB0 aGUgbnVtYmVyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5Kb24gUGV0ZXJzb248L3Nw YW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPk5ldXN0YXIsIEluYy48L3NwYW4+PG86cD48L286cD48L3A+PC9k aXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj5UaGlzIHRyYW5zbWlz c2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJv dGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmls ZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0 aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGll bnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVu aW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVs LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_4B1956260CD29F4A9622F00322FE0531D0FDE6C379BOBO1Abobotek_-- From richard@shockey.us Wed Nov 6 05:25:32 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6117421E80D3 for ; Wed, 6 Nov 2013 05:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNYA7QMCdZJR for ; Wed, 6 Nov 2013 05:25:25 -0800 (PST) Received: from oproxy4-pub.mail.unifiedlayer.com (oproxy4-pub.mail.unifiedlayer.com [74.220.216.66]) by ietfa.amsl.com (Postfix) with SMTP id 15EB111E8197 for ; Wed, 6 Nov 2013 05:25:25 -0800 (PST) Received: (qmail 8453 invoked by uid 0); 6 Nov 2013 13:25:15 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy4.mail.unifiedlayer.com with SMTP; 6 Nov 2013 13:25:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=P/PFzEV0VtPqdfSLmShhMhutPcA2gyQF+h8CqgDugjg=; b=gSdV87qLgK668hm5kBosqKc02yPx4lfTzdqQxgvAZ79T7mHF5nHDeN3dGxDwooQWRN/Vb6sio7caciJP2lTWW+3OJau0BWf1KNEYVmrUKIlLTjNSTPAkGVeo5+Ypv9Nf; Received: from [173.79.179.104] (port=49301 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ve36g-0002Z5-BA; Wed, 06 Nov 2013 06:25:14 -0700 From: "Richard Shockey" To: "'Fernando Mousinho \(fmousinh\)'" , "'Gorman, Pierce A [NTK]'" , References: In-Reply-To: Date: Wed, 6 Nov 2013 08:25:11 -0500 Message-ID: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0137_01CEDAC9.B79107E0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEejKIqiVp51SYOKACkQGhco8HJEJt4yvcA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 13:25:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0137_01CEDAC9.B79107E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree with Pierce here and respectfully disagree that STIR might eliminate the need for other forms of caller identification. Though your use case of credit card validation is a useful one and you are right there are still applications that use SS7 for things that have nothing to do with call setup. I agree with you STIR may have more applications beyond the obvious ones of realtime session validation. It's been my experience recently that there is a use case for something MORE in the identification of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identify themselves to the consumer before establishing a conversation is exactly what this process is about. STIR is essential but it's a multi-faceted problem that may require multi-faceted solutions.. and enhanced CNAM + being only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a utility worker before I let them into my house to make repairs. I would want some validation that the call to me to reconfirm the appointments was in fact from the utility in question. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it. it may eliminate the need for other forms of caller identification beyond what STIR will provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to be unblocked by an IVR (and as I said earlier, many companies do it today). In other use cases, the TN alone is not sufficient information - my health care provider will want to know which member of the family is calling. I agree that ANI is already broadly used to improve customer service today. However, it is not usually deemed as a secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things like SS7. STIR would make this type of validation available to a broader number of companies. Going on a tangent. perhaps this is out of scope, but there is not a lot of discussion about called party hijacking. Couldn't a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it's really them before carrying a conversation, but wouldn't they want the same? From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho >, "stir@ietf.org " Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fraud however contact centers also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the call center. So I don't agree that STIR would "eliminate the need for caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more companies are using the caller ID for account validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my home phone number, I'm informed that I don't need to provide any further identification because my number is on file. Some (all?) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this case, the "victim" is a business, unlike the other two scenarios we've listed so far. Addressing this scenario would actually turn STIR into a feature, given it would enable contact centers of all sizes to eliminate the need for caller identification from known TNs. From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen >, "Peterson, Jon" > Cc: "stir@ietf.org " >, Richard Shockey >, "'DOLLY, MARTIN C'" >, 'Robert Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the following sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is simply the rendering of a spoofed number on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information. No issues with leaving this as it's a valid point. Another (increasing) motivation is to evade network and/or endpoint defenses that may block based on CPN. So however it's worded, I think it's important to allow for both attack objectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org ; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" < jon.peterson@neustar.biz> > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draft: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> < rjsparks@nostrum.com> > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. ------=_NextPart_000_0137_01CEDAC9.B79107E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Pierce here = and respectfully disagree that STIR might eliminate the need for other = forms of caller identification.  Though your use case of credit = card validation is a useful one and you are right there are still = applications that use SS7 for things that have nothing to do with call = setup. I agree with you STIR may have more applications beyond the = obvious ones of realtime session validation.

 

It’s been my = experience recently that there is a use case for something MORE in the = identification of the session as it is presented to the called party. = This is the CNAM + idea we are kicking around on the CNIT = list.

 

_______________________________________________

cnit mailing list

cnit@ietf.org

https://www.ietf.org/= mailman/listinfo/cnit

 

But your use case of a = bank wanting to make sure they could properly identify themselves to the = consumer before establishing a conversation is exactly what this process = is about.  STIR is essential but it’s a multi-faceted problem = that may require multi-faceted solutions.. and enhanced CNAM + being = only one of them.   Its not unreasonable to discuss those. =

 

The obviously analogy is = I would want to see some real identification of a utility worker before = I let them into my house to make repairs.  I would want some = validation that the call to me to reconfirm the appointments was in fact = from the utility in question.

 

 

 

From: stir-bounces@ietf.org = [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 6:26 = PM
To: Gorman, Pierce A [NTK]; = stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

Let me rephrase it… it may = eliminate the need for other forms of caller identification beyond what = STIR will provide, depending on the specific use case. For example, a = credit card company may choose to rely entirely on STIR before allowing = a card to be unblocked by an IVR (and as I said earlier, many companies = do it today). In other use cases, the TN alone is not sufficient = information – my health care provider will want to know which = member of the family is calling.

 

=

I = agree that ANI is already broadly used to improve customer service = today. However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of = companies.

 

=

 

=

Going on a tangent… perhaps = this is out of scope, but there is not a lot of discussion about called = party hijacking. Couldn’t a man-in-the-middle try to answer calls = on my behalf? If my bank is calling me, I want to make sure it’s = really them before carrying a conversation, but wouldn’t they want = the same? 

 

=

 

=

From: = <Gorman>, "Pierce A = [NTK]" <Pierce.Gorman@sprint.com>=
Date: Tuesday, November 5, 2013 at 6:05 PM
To: = Fernando Mousinho <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: = RE: [stir] = draft-peterson-stir-threats-00.txt

 

=

I agree with = your characterization of businesses as victim of caller ID fraud however = contact centers also use TN as a key to improve information available to = call agents to reduce average time-per-call and increase capacity of the = call center.  So I don’t agree that STIR would = “eliminate the need for caller identification from known = TNs.”

 

But perhaps I = misunderstood your last sentence?

 

 

= From:= Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] =
Sent: November 05, 2013 4:34 PM
To: stir@ietf.org
Subject: Re: = [stir] draft-peterson-stir-threats-00.txt

 

I would = suggest we add a new attack type to section 3. More and more companies = are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I’m informed = that I don’t need to provide any further identification because my = number is on file. Some (all?) companies that implement this type of = validation rely on SS7 today.

 

Ultimately, this is yet another = variation of impersonation – but in this case, the = “victim” is a business, unlike the other two scenarios = we’ve listed so far.

 

Addressing this scenario would = actually turn STIR into a feature, given it would enable contact centers = of all sizes to eliminate the need for caller identification from known = TNs.

 

 

 

From: = Alex Bobotek <alex@bobotek.net>
Date: = Tuesday, October 1, 2013 at 12:51 PM
To: Brian Rosen = <br@brianrosen.net>, = "Peterson, Jon" <jon.peterson@neustar.biz>=
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, = "'DOLLY, MARTIN C'" <md3135@att.com>, 'Robert Sparks' = <rjsparks@nostrum.com>
S= ubject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

Jon,

 

Thanks for the = response.  The intention in #1 below is to clarify the following = sentence:

 

The primary = attack vector is

   therefore one where the attacker = contrives for the calling telephone

   number in = signaling to be a particular chosen number, one that = the

   attacker does not have the authority = to call from, in order for that

   number = to be rendered on the terminating side. 

 

This might be = misconstrued as indicating that the objective of spoofing is simply the = rendering of a spoofed number on the receiving display, causing mistaken = conclusions that defenses might be limited to securing the rendered = information.  No issues with leaving this as it’s a valid = point.  Another (increasing) motivation is to evade network and/or = endpoint defenses that may block based on CPN.  =

 

So however it’s = worded, I think it’s important to allow for both attack objectives = of a spoofed presentation at the endpoint and in transit.  =  

 

Regards,

 

Alex

 

> -----Original = Message-----

> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On Behalf Of

> Brian Rosen

> Sent: Tuesday, = October 01, 2013 9:29 AM

> To: Peterson, = Jon

> Cc: stir@ietf.org; Alex Bobotek; 'Robert = Sparks'; 'DOLLY, MARTIN C'; Richard

> = Shockey

> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> =

> Don't think there is much MESSAGE.  MSRP = is about all we see, and XMPP is

> more likely than = that.

>

> = Brian

>

> On Oct 1, 2013, at = 12:24 PM, "Peterson, Jon" <jon.peterson@neustar.biz<= /span>>

> wrote:

> =

> > Thanks for these notes, Alex. Some = responses below.

> >

> >> Here are = several comments that should feed into the IETF Peterson = draft:

> >>

> >> = *   Remove any assumptions that the solution cannot be = in-network

> [IMO,

> >> both = endpoint and in-network solutions should be = facilitated]

> >

> > Agreed that = both in-band and out-of-band solutions can usually = be

> > implemented in either endpoints or in = intermediaries of various kinds.

> > If I see text = that implies otherwise, I'll certainly change = it.

> >

> >> = *   Add a sessionless attack scenario.  A spam payload = may be carried in

> a

> >> SIP = INVITE or MESSAGE, which might contain stock market advice = even

> >> in a display name field.  These = attacks do NOT require session

> = establishment.

> >> More generally, we should be mindful = of the fact that SIP is used in

> >> telephony = form more than voice session setup.

> = >

> > Probably if we were going to include a = sessionless attack scenario, it

> > would be with = regular text messages (whether carried on the PSTN = over

> > TCAP or with some Internet protocol, = including MESSAGE) rather than

> > with an = INVITE, which typically wouldn't result in a payload = being

> > immediately rendered to a user. More on = this below with your suggested

> = text.

> >

> >> Here's = some suggested markup:

> = >>

> >>

> >> = 1.    Replace 2nd sentence of 2nd paragraph of 1.0 = Introduction with:

> >>

> >> The = primary attack vector is

> >>  = therefore one where the attacker contrives for the calling = telephone

> >> number in signaling to be a = particular chosen number that the

> >> attacker = does not have the authority to call from.

> = >

> > What you want here is to remove the = implication that the number will

> > be rendered = on the terminating side? While there are some = attacks

> > where that isn't significant, perhaps, I = would say it is significant

> > in the = primary attack vectors that concern us.

> = >

> >> 2.  Replace 3rd paragraph of = 2.1 Endpoints with:

> >>

> = >>     Smart devices are generally based on = computers with some degree

> >> of = programmability, the capacity to access the Internet, = and

> >> capabilities of rendering text, = audio and/or images.  This includes

> >> smart = phones, telephone applications on desktop and laptop = computers,

> >> IP private branch exchanges, and so = on.

> >

> > I can add the = notion that smart devices can render text, audio = and/or

> > images as you = suggest.

> >

> >> 3.  = Add to 3.3 Attack Scenarios:

> = >>

> >>       = Impersonation, IP-Mobile Text Message

> = >>

> >>       =  An attacker with an computer sends a high volume of SIP = MESSAGE

> >> spam message to IP-enabled smart = phones using randomized calling

> >> party = numbers.

> >>

> >>  =      Countermeasure: in-band authenticated = identity

> >

> > Provided = we're talking about end-to-end SIP use of MESSAGE, = agreed

> > that in-band would be the right = countermeasure. I am curious though

> > whether = practically speaking there is enough use of MESSAGE in = this

> > fashion that we're actually seeing = high-volume spam over MESSAGE

> > today. Either = way, no problem having an attack scenario of this form in = the

> document.

> = >

> > Jon Peterson

> > Neustar, = Inc.

> >

> >> = Regards,

> >>

> >> = Alex

> >>

> >>> = -----Original Message-----

> >>> From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.= org] On Behalf

> >>> Of = Richard Shockey

> >>> Sent: Monday, September 30, 2013 = 1:11 PM

> >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'

> >>> Cc: stir@ietf.org<= o:p>

> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>

> >>> +1

> = >>>

> >>> -----Original = Message-----

> >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.= org] On Behalf

> >>> Of = DOLLY, MARTIN C

> >>> Sent: Monday, September 30, 2013 = 12:58 PM

> >>> To: Robert = Sparks

> >>> Cc: stir@ietf.org<= o:p>

> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>

> >>> Yes, ok

> = >>>

> >>> Martin = Dolly

> >>> Lead Member of Technical = Staff

> >>> Core Network & = Gov't/Regulatory Standards AT&T Labs - = Network

> >>> = Technology

> >>> = +1-609-903-3360

> >>> md3135@att.com=

> >>>

> >>>> = On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"

> >>>> <rjsparks@nostrum.com>

> >>> wrote:

> = >>>>

> >>>>> On 9/26/13 3:42 PM, = DOLLY, MARTIN C wrote:

> = >>>>> With Hadriel comments incorporated, it is a = start

> >>>> Hi Martin = -

> >>>>

> >>>> = Just to make sure - I think you're referring to Hadriel's = comments

> >>>> on = the

> >>> problem statement = document?

> >>>> I don't think Hadriel's = commented directly on stir-threats yet.

> = >>>>

> >>>> In any case, we _are_ = talking about a starting place, not a

> >>>> = finished

> >>> product.

> = >>>>

> >>>> If there's no other = objection, I'd like to get Jon to submit the

> >>>> = threats

> >>> document as a WG -00 as soon as = it's convenient.

> >>>>

> >>>> = RjS

> >>>>>

> = >>>>> -----Original Message-----

> = >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.= org] On

> >>>>> Behalf Of Russ = Housley

> >>>>> Sent: Thursday, = September 26, 2013 4:37 PM

> = >>>>> To: IETF STIR Mail List

> = >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>>>

> >>>>> It has been six days, = I'd like to hear from more people about this

> >>> = document.  Martin asked for an additional week, so I'm sure we = will

> >>> hear from him = soon.

> >>>>>

> = >>>>> Russ

> = >>>>>

> >>>>>

> = >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley = wrote:

> = >>>>>>

> = >>>>>> http://www.ietf.org/id/dr= aft-peterson-stir-threats-00.txt

> = >>>>>>

> = >>>>>> Should the working group adopt this I-D as the = starting point for

> >>>>>> = the

> >>> STIR threat = docuent?

> = >>>>>>

> = >>>>>> Russ

> = >>>>> = _______________________________________________

> = >>>>> stir mailing list

> = >>>>> stir@ietf.org<= o:p>

> >>>>> https://www.ietf.org/mail= man/listinfo/stir

> = >>>>

> >>>> = _______________________________________________

> >>>> = stir mailing list

> >>>> stir@ietf.org<= o:p>

> >>>> https://www.ietf.org/mail= man/listinfo/stir

> >>> = _______________________________________________

> >>> stir = mailing list

> >>> stir@ietf.org<= o:p>

> >>> https://www.ietf.org/mail= man/listinfo/stir

> = >>>

> >>> = _______________________________________________

> >>> stir = mailing list

> >>> stir@ietf.org<= o:p>

> >>> https://www.ietf.org/mail= man/listinfo/stir

> >> = _______________________________________________

> >> stir = mailing list

> >> stir@ietf.org<= o:p>

> >> https://www.ietf.org/mail= man/listinfo/stir

> = >

> > = _______________________________________________

> > stir mailing = list

> > stir@ietf.org<= o:p>

> > https://www.ietf.org/mail= man/listinfo/stir

> =

> = _______________________________________________

> stir mailing = list

> stir@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/stir

 

This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

=
------=_NextPart_000_0137_01CEDAC9.B79107E0-- From br@brianrosen.net Wed Nov 6 12:41:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D9C11E812B for ; Wed, 6 Nov 2013 12:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.497 X-Spam-Level: X-Spam-Status: No, score=-103.497 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6LZgt8SaJYW for ; Wed, 6 Nov 2013 12:41:03 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 918C821F9F6C for ; Wed, 6 Nov 2013 12:41:02 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id e9so38837qcy.25 for ; Wed, 06 Nov 2013 12:41:02 -0800 (PST) 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:message-id:references:to; bh=Om+telqJ4mmtg6JU4NEx4GCEgmJhbaF06DFbAg2niP0=; b=iwWxxiBIN1OewgmD5jIJHPInBi63oEyLDE2TWiiNq9eq5AMWMayY6V3tavRztX91+0 5uHmZzJQJV/v9B1xbBpigoOcSjoYavMOsscVzg2WPPVZpgS0ctFw69UdXKw7Lg9vZM+Z beFDNA1FlyzAhOYnV2qRNSxH501mbBjIxBHqxBieBD9NCyXPSQczqACgbSwZpPr/IVV2 5EH4Gw+JWXNg8AVEIu6u3uyG4LGa96pscHMWEFeoy9ptMBjWqN2tynz+32v5xQy6sV6j eAhbhyxyjFB6MmglxXNDi92FWacPV+v5yTUdDk/lVwIENpqqDB6sMgeLvpOE1f7hYRdZ FLwg== X-Gm-Message-State: ALoCoQlWgePnZrc+QW6APvQ19SSvdD0r22q7cOfmHtSMWbMQjCMrv7YqkXrskvoF+hYaH9SF59jU X-Received: by 10.224.38.2 with SMTP id z2mr5092917qad.121.1383770461815; Wed, 06 Nov 2013 12:41:01 -0800 (PST) Received: from [192.168.128.255] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id r5sm95985qeh.1.2013.11.06.12.40.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 12:41:01 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_44DA6727-A5DB-4D05-AF41-0FF12654BF74" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> Date: Wed, 6 Nov 2013 12:40:58 -0800 Message-Id: <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1816) Cc: "stir@ietf.org List" , "Gorman, Pierce A \[NTK\]" , "Fernando Mousinho \(fmousinh\)" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:41:11 -0000 --Apple-Mail=_44DA6727-A5DB-4D05-AF41-0FF12654BF74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We=92ve considered adding some information that is not number and is not = name, but is something like =93bank=94, which might have some sort of = validation behind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey wrote: > I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification. Though = your use case of credit card validation is a useful one and you are = right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session validation. > =20 > It=92s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list. > =20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > =20 > But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about. STIR is essential but it=92s a = multi-faceted problem that may require multi-faceted solutions.. and = enhanced CNAM + being only one of them. Its not unreasonable to = discuss those. > =20 > The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. I = would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in question. > =20 > =20 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Fernando Mousinho (fmousinh) > Sent: Tuesday, November 05, 2013 6:26 PM > To: Gorman, Pierce A [NTK]; stir@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Let me rephrase it=85 it may eliminate the need for other forms of = caller identification beyond what STIR will provide, depending on the = specific use case. For example, a credit card company may choose to rely = entirely on STIR before allowing a card to be unblocked by an IVR (and = as I said earlier, many companies do it today). In other use cases, the = TN alone is not sufficient information =96 my health care provider will = want to know which member of the family is calling. > =20 > I agree that ANI is already broadly used to improve customer service = today. However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of companies. > =20 > =20 > Going on a tangent=85 perhaps this is out of scope, but there is not a = lot of discussion about called party hijacking. Couldn=92t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it=92s really them before carrying a = conversation, but wouldn=92t they want the same?=20 > =20 > =20 > From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM > To: Fernando Mousinho , "stir@ietf.org" = > Subject: RE: [stir] draft-peterson-stir-threats-00.txt > =20 > I agree with your characterization of businesses as victim of caller = ID fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center. So I don=92t agree that STIR = would =93eliminate the need for caller identification from known TNs.=94 > =20 > But perhaps I misunderstood your last sentence? > =20 > =20 > From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com]=20 > Sent: November 05, 2013 4:34 PM > To: stir@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > I would suggest we add a new attack type to section 3. More and more = companies are using the caller ID for account validation. For example, = if I call my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I=92m informed that = I don=92t need to provide any further identification because my number = is on file. Some (all?) companies that implement this type of validation = rely on SS7 today. > =20 > Ultimately, this is yet another variation of impersonation =96 but in = this case, the =93victim=94 is a business, unlike the other two = scenarios we=92ve listed so far. > =20 > Addressing this scenario would actually turn STIR into a feature, = given it would enable contact centers of all sizes to eliminate the need = for caller identification from known TNs. > =20 > =20 > =20 > From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM > To: Brian Rosen , "Peterson, Jon" = > Cc: "stir@ietf.org" , Richard Shockey = , "'DOLLY, MARTIN C'" , 'Robert = Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Jon, > =20 > Thanks for the response. The intention in #1 below is to clarify the = following sentence: > =20 > The primary attack vector is > therefore one where the attacker contrives for the calling = telephone > number in signaling to be a particular chosen number, one that the > attacker does not have the authority to call from, in order for = that > number to be rendered on the terminating side.=20 > =20 > This might be misconstrued as indicating that the objective of = spoofing is simply the rendering of a spoofed number on the receiving = display, causing mistaken conclusions that defenses might be limited to = securing the rendered information. No issues with leaving this as it=92s = a valid point. Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on CPN.=20 > =20 > So however it=92s worded, I think it=92s important to allow for both = attack objectives of a spoofed presentation at the endpoint and in = transit. =20 > =20 > Regards, > =20 > Alex > =20 > > -----Original Message----- > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > > Brian Rosen > > Sent: Tuesday, October 01, 2013 9:29 AM > > To: Peterson, Jon > > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; = Richard > > Shockey > > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > > > Don't think there is much MESSAGE. MSRP is about all we see, and = XMPP is > > more likely than that. > > > > Brian > > > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" = > > wrote: > > > > > Thanks for these notes, Alex. Some responses below. > > > > > >> Here are several comments that should feed into the IETF Peterson = draft: > > >> > > >> * Remove any assumptions that the solution cannot be in-network > > [IMO, > > >> both endpoint and in-network solutions should be facilitated] > > > > > > Agreed that both in-band and out-of-band solutions can usually be > > > implemented in either endpoints or in intermediaries of various = kinds. > > > If I see text that implies otherwise, I'll certainly change it. > > > > > >> * Add a sessionless attack scenario. A spam payload may be = carried in > > a > > >> SIP INVITE or MESSAGE, which might contain stock market advice = even > > >> in a display name field. These attacks do NOT require session > > establishment. > > >> More generally, we should be mindful of the fact that SIP is used = in > > >> telephony form more than voice session setup. > > > > > > Probably if we were going to include a sessionless attack = scenario, it > > > would be with regular text messages (whether carried on the PSTN = over > > > TCAP or with some Internet protocol, including MESSAGE) rather = than > > > with an INVITE, which typically wouldn't result in a payload being > > > immediately rendered to a user. More on this below with your = suggested > > text. > > > > > >> Here's some suggested markup: > > >> > > >> > > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction = with: > > >> > > >> The primary attack vector is > > >> therefore one where the attacker contrives for the calling = telephone > > >> number in signaling to be a particular chosen number that the > > >> attacker does not have the authority to call from. > > > > > > What you want here is to remove the implication that the number = will > > > be rendered on the terminating side? While there are some attacks > > > where that isn't significant, perhaps, I would say it is = significant > > > in the primary attack vectors that concern us. > > > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > > >> > > >> Smart devices are generally based on computers with some = degree > > >> of programmability, the capacity to access the Internet, and > > >> capabilities of rendering text, audio and/or images. This = includes > > >> smart phones, telephone applications on desktop and laptop = computers, > > >> IP private branch exchanges, and so on. > > > > > > I can add the notion that smart devices can render text, audio = and/or > > > images as you suggest. > > > > > >> 3. Add to 3.3 Attack Scenarios: > > >> > > >> Impersonation, IP-Mobile Text Message > > >> > > >> An attacker with an computer sends a high volume of SIP = MESSAGE > > >> spam message to IP-enabled smart phones using randomized calling > > >> party numbers. > > >> > > >> Countermeasure: in-band authenticated identity > > > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > > that in-band would be the right countermeasure. I am curious = though > > > whether practically speaking there is enough use of MESSAGE in = this > > > fashion that we're actually seeing high-volume spam over MESSAGE > > > today. Either way, no problem having an attack scenario of this = form in the > > document. > > > > > > Jon Peterson > > > Neustar, Inc. > > > > > >> Regards, > > >> > > >> Alex > > >> > > >>> -----Original Message----- > > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf > > >>> Of Richard Shockey > > >>> Sent: Monday, September 30, 2013 1:11 PM > > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > > >>> Cc: stir@ietf.org > > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>> > > >>> +1 > > >>> > > >>> -----Original Message----- > > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf > > >>> Of DOLLY, MARTIN C > > >>> Sent: Monday, September 30, 2013 12:58 PM > > >>> To: Robert Sparks > > >>> Cc: stir@ietf.org > > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>> > > >>> Yes, ok > > >>> > > >>> Martin Dolly > > >>> Lead Member of Technical Staff > > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > > >>> Technology > > >>> +1-609-903-3360 > > >>> md3135@att.com > > >>> > > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > > >>>> > > >>> wrote: > > >>>> > > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > > >>>>> With Hadriel comments incorporated, it is a start > > >>>> Hi Martin - > > >>>> > > >>>> Just to make sure - I think you're referring to Hadriel's = comments > > >>>> on the > > >>> problem statement document? > > >>>> I don't think Hadriel's commented directly on stir-threats yet. > > >>>> > > >>>> In any case, we _are_ talking about a starting place, not a > > >>>> finished > > >>> product. > > >>>> > > >>>> If there's no other objection, I'd like to get Jon to submit = the > > >>>> threats > > >>> document as a WG -00 as soon as it's convenient. > > >>>> > > >>>> RjS > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On > > >>>>> Behalf Of Russ Housley > > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > > >>>>> To: IETF STIR Mail List > > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>>>> > > >>>>> It has been six days, I'd like to hear from more people about = this > > >>> document. Martin asked for an additional week, so I'm sure we = will > > >>> hear from him soon. > > >>>>> > > >>>>> Russ > > >>>>> > > >>>>> > > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > > >>>>>> > > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > > >>>>>> > > >>>>>> Should the working group adopt this I-D as the starting point = for > > >>>>>> the > > >>> STIR threat docuent? > > >>>>>> > > >>>>>> Russ > > >>>>> _______________________________________________ > > >>>>> 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 > > >>> _______________________________________________ > > >>> 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 > > >> _______________________________________________ > > >> 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 > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > =20 >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_44DA6727-A5DB-4D05-AF41-0FF12654BF74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 We=92ve = considered adding some information that is not number and is not name, = but is something like =93bank=94, which might have some sort of = validation behind it.

Is that along the lines you = were thinking?

Brian
On Nov 6, = 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:

I agree with Pierce here and respectfully disagree = that STIR might eliminate the need for other forms of caller = identification.  Though your use case of credit card validation is = a useful one and you are right there are still applications that use SS7 = for things that have nothing to do with call setup. I agree with you = STIR may have more applications beyond the obvious ones of realtime = session validation.
 
It=92s = been my experience recently that there is a use case for something MORE = in the identification of the session as it is presented to the called = party. This is the CNAM + idea we are kicking around on the CNIT = list.
 
_______________________________________________
cnit mailing list
 
But your use case of a bank wanting to make sure they = could properly identify themselves to the consumer before establishing a = conversation is exactly what this process is about.  STIR is = essential but it=92s a multi-faceted problem that may require = multi-faceted solutions.. and enhanced CNAM + being only one of = them.   Its not unreasonable to discuss = those.
 
The obviously analogy is I would want = to see some real identification of a utility worker before I let them = into my house to make repairs.  I would want some validation that = the call to me to reconfirm the appointments was in fact from the = utility in question.
 
 
 
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
Let me rephrase it=85 it = may eliminate the need for other forms of caller identification beyond = what STIR will provide, depending on the specific use case. For example, = a credit card company may choose to rely entirely on STIR before = allowing a card to be unblocked by an IVR (and as I said earlier, many = companies do it today). In other use cases, the TN alone is not = sufficient information =96 my health care provider will want to know = which member of the family is = calling.
 
I agree that = ANI is already broadly used to improve customer service today. However, = it is not usually deemed as a secure enough mechanism to validate the = caller (therefore this WG!), except if you are a large organization that = can leverage things like SS7. STIR would make this type of validation = available to a broader number of = companies.
 
 
Going on a tangent=85 perhaps this is out = of scope, but there is not a lot of discussion about called party = hijacking. Couldn=92t a man-in-the-middle try to answer calls on my = behalf? If my bank is calling me, I want to make sure it=92s really them = before carrying a conversation, but wouldn=92t they want the = same? 
 
 
From: <Gorman>, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Date: Tuesday, November 5, = 2013 at 6:05 PM
To: Fernando Mousinho = <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt
 
I agree = with your characterization of businesses as victim of caller ID fraud = however contact centers also use TN as a key to improve information = available to call agents to reduce average time-per-call and increase = capacity of the call center.  So I don=92t agree that STIR would = =93eliminate the need for caller identification from known = TNs.=94
 
But = perhaps I misunderstood your last sentence?
 
 
From: Fernando Mousinho = (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
I would suggest we add a new attack type to = section 3. More and more companies are using the caller ID for account = validation. For example, if I call my credit card provider from my = office number, they ask me for identification. If I call from my home = phone number, I=92m informed that I don=92t need to provide any further = identification because my number is on file. Some (all?) companies that = implement this type of validation rely on SS7 today.
 
Ultimately, this is yet another variation = of impersonation =96 but in this case, the =93victim=94 is a business, = unlike the other two scenarios we=92ve listed so far.
 
Addressing this scenario would actually = turn STIR into a feature, given it would enable contact centers of all = sizes to eliminate the need for caller identification from known = TNs.
 
 
 
From: Alex Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, = 2013 at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, "Peterson, Jon" = <jon.peterson@neustar.biz>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, = MARTIN C'" <md3135@att.com>, = 'Robert Sparks' <rjsparks@nostrum.com>
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
Jon,
 
Thanks for the response.  The intention in #1 below is = to clarify the following sentence:
 
The primary attack vector = is
   therefore one where the attacker contrives for = the calling telephone
   number in signaling to be a particular chosen = number, one that the
   attacker does not have the authority to call = from, in order for = that
   = number to be rendered on the terminating side. 
 
This might be misconstrued as indicating that the objective = of spoofing is simply the rendering of a spoofed number on the receiving = display, causing mistaken conclusions that defenses might be limited to = securing the rendered information.  No issues with leaving this as = it=92s a valid point.  Another (increasing) motivation is to evade = network and/or endpoint defenses that may block based on = CPN. 
 
So however it=92s worded, I think it=92s important to allow = for both attack objectives of a spoofed presentation at the endpoint and = in transit.   
 
Regards,
 
Alex
 
> -----Original Message-----
> = Brian Rosen
> Sent: Tuesday, October 01, 2013 9:29 = AM
> = To: Peterson, Jon
> Cc: stir@ietf.org; Alex Bobotek; 'Robert = Sparks'; 'DOLLY, MARTIN C'; Richard
> = Shockey
> = Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
>
> Don't think there is much = MESSAGE.  MSRP is about all we see, and XMPP = is
> = more likely than that.
>
> Brian
>
> On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <jon.peterson@neustar.biz>
> = wrote:
>
> > Thanks for these notes, Alex. Some responses = below.
> = >
> = >> Here are several comments that should feed into the IETF = Peterson draft:
> >>
> >> *   Remove any = assumptions that the solution cannot be = in-network
> [IMO,
> >> both endpoint and in-network solutions should = be facilitated]
> >
> > Agreed that both in-band and out-of-band solutions = can usually be
> > implemented in either endpoints or in = intermediaries of various kinds.
> > If I see text that = implies otherwise, I'll certainly change it.
> = >
> = >> *   Add a sessionless attack scenario.  A spam = payload may be carried in
> a
> >> SIP INVITE or = MESSAGE, which might contain stock market advice = even
> = >> in a display name field.  These attacks do NOT require = session
> = establishment.
> >> More generally, we should be mindful of the = fact that SIP is used in
> >> telephony form more than = voice session setup.
> >
> > Probably if we were going to include a sessionless = attack scenario, it
> > would be with regular text messages (whether = carried on the PSTN over
> > TCAP or with some Internet = protocol, including MESSAGE) rather than
> > with an INVITE, which = typically wouldn't result in a payload being
> > immediately rendered to = a user. More on this below with your = suggested
> = text.
> = >
> = >> Here's some suggested markup:
> = >>
> = >>
> = >> 1.    Replace 2nd sentence of 2nd paragraph of = 1.0 Introduction with:
> >>
> >> The primary attack vector = is
> = >>  therefore one where the attacker contrives for the = calling telephone
> >> number in signaling to be a particular chosen = number that the
> >> attacker does not have the authority to call = from.
> = >
> = > What you want here is to remove the implication that the number = will
> = > be rendered on the terminating side? While there are some = attacks
> = > where that isn't significant, perhaps, I would say it is = significant
> > in the primary attack vectors that concern = us.
> = >
> = >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:
> = >>
> = >>     Smart devices are generally based on = computers with some degree
> >> of programmability, the = capacity to access the Internet, and
> >> capabilities of = rendering text, audio and/or images.  This = includes
> = >> smart phones, telephone applications on desktop and laptop = computers,
> >> IP private branch exchanges, and so = on.
> = >
> = > I can add the notion that smart devices can render text, audio = and/or
> = > images as you suggest.
> >
> >> 3.  Add to 3.3 = Attack Scenarios:
> >>
> >> =       Impersonation, IP-Mobile Text = Message
> = >>
> = >>        An attacker with an = computer sends a high volume of SIP MESSAGE
> >> spam message to = IP-enabled smart phones using randomized = calling
> = >> party numbers.
> >>
> >>  =      Countermeasure: in-band authenticated = identity
> = >
> = > Provided we're talking about end-to-end SIP use of MESSAGE, = agreed
> = > that in-band would be the right countermeasure. I am curious = though
> = > whether practically speaking there is enough use of MESSAGE in = this
> = > fashion that we're actually seeing high-volume spam over = MESSAGE
> = > today. Either way, no problem having an attack scenario of this = form in the
> document.
> >
> > Jon = Peterson
> = > Neustar, Inc.
> >
> >> Regards,
> = >>
> = >> Alex
> >>
> >>> -----Original = Message-----
> = >>> Of Richard Shockey
> >>> Sent: Monday, = September 30, 2013 1:11 PM
> >>> To: 'DOLLY, MARTIN C'; = 'Robert Sparks'
> >>> Cc: stir@ietf.org
> >>> Subject: Re: = [stir] draft-peterson-stir-threats-00.txt
> = >>>
> >>> +1
> = >>>
> >>> -----Original = Message-----
> = >>> Of DOLLY, MARTIN C
> >>> Sent: Monday, = September 30, 2013 12:58 PM
> >>> To: Robert = Sparks
> = >>> Cc: stir@ietf.org
> >>> Subject: Re: = [stir] draft-peterson-stir-threats-00.txt
> = >>>
> >>> Yes, ok
> = >>>
> >>> Martin Dolly
> >>> Lead Member of = Technical Staff
> >>> Core Network & Gov't/Regulatory = Standards AT&T Labs - Network
> >>> = Technology
> >>> +1-609-903-3360
> = >>>
> >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"
> >>> = wrote:
> = >>>>
> >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C = wrote:
> = >>>>> With Hadriel comments incorporated, it is a = start
> = >>>> Hi Martin -
> = >>>>
> >>>> Just to make sure - I think you're = referring to Hadriel's comments
> >>>> on = the
> = >>> problem statement document?
> >>>> I don't = think Hadriel's commented directly on stir-threats = yet.
> = >>>>
> >>>> In any case, we _are_ talking about a = starting place, not a
> >>>> finished
> >>> = product.
> = >>>>
> >>>> If there's no other objection, I'd like = to get Jon to submit the
> >>>> = threats
> = >>> document as a WG -00 as soon as it's = convenient.
> >>>>
> >>>> = RjS
> = >>>>>
> >>>>> -----Original = Message-----
> = >>>>> Behalf Of Russ Housley
> >>>>> Sent: = Thursday, September 26, 2013 4:37 PM
> >>>>> To: = IETF STIR Mail List
> >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> = >>>>>
> >>>>> It has been six days, I'd like to = hear from more people about this
> >>> document.  = Martin asked for an additional week, so I'm sure we = will
> = >>> hear from him soon.
> = >>>>>
> >>>>> Russ
> = >>>>>
> >>>>>
> >>>>>> On = Sep 20, 2013, at 5:23 PM, Russ Housley = wrote:
> = >>>>>>
> >>>>> stir = mailing list
> = >>>>
> >>>> = _______________________________________________
> >>>> stir = mailing list
> >>> = _______________________________________________
> >>> stir mailing = list
> = >>> stir@ietf.org
> = >>>
> >>> = _______________________________________________
> >>> stir mailing = list
> = >>> stir@ietf.org
> >> = _______________________________________________
> >> stir mailing = list
> = >
> = > = _______________________________________________
> > stir mailing = list
>
> = _______________________________________________
> stir mailing = list
 

This e-mail may contain Sprint = proprietary information intended for the sole use of the recipient(s). = Any use by others is prohibited. If you are not the intended recipient, = please contact the sender and delete all copies of the = message.
_____________________________= __________________
stir mailing list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir
= --Apple-Mail=_44DA6727-A5DB-4D05-AF41-0FF12654BF74-- From richard@shockey.us Wed Nov 6 13:11:13 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E4221E81B1 for ; Wed, 6 Nov 2013 13:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.171 X-Spam-Level: X-Spam-Status: No, score=-102.171 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-Crkw3g8Nb1 for ; Wed, 6 Nov 2013 13:11:04 -0800 (PST) Received: from oproxy17-pub.mail.unifiedlayer.com (oproxy17-pub.mail.unifiedlayer.com [74.220.201.171]) by ietfa.amsl.com (Postfix) with SMTP id 28C0B21E8182 for ; Wed, 6 Nov 2013 13:11:02 -0800 (PST) Received: (qmail 10928 invoked by uid 0); 6 Nov 2013 21:10:58 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy17-pub.mail.unifiedlayer.com with SMTP; 6 Nov 2013 21:10:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=077RVOZW91O/k6NGWYrHiKBcwJoqGCEi4HaXP5lJkfQ=; b=FG6YumXCMH9T8HsWWx+yCZlrQXhLgGK6pjtMdd4s7ImuZrhiZ01l3AnpBh27spkR8fTRewCcv2W9Lw1Phu7x67VsWkEW1nA8RXlVKIsXI7iJ2/CRO/nb77qP3VlZKYR2; Received: from [173.79.179.104] (port=54874 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VeANN-00030h-6h; Wed, 06 Nov 2013 14:10:57 -0700 From: "Richard Shockey" To: "'Brian Rosen'" References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> In-Reply-To: <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> Date: Wed, 6 Nov 2013 16:10:55 -0500 Message-ID: <02e301cedb34$af790790$0e6b16b0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E4_01CEDB0A.C6AC9C80" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKuxOgdsFN95Qgmj4nb3bGbN4Q20wEejKIqAhCsH9QBYcTrs5g0U4aQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: stir@ietf.org, "'Gorman, Pierce A \[NTK\]'" , cnit@ietf.org, "'Fernando Mousinho \(fmousinh\)'" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:11:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02E4_01CEDB0A.C6AC9C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit URI for a JCARD in the CALL INFO header provisioned by the calling party and ultimately signed by the responsible entity. The carrier could provision this for their mobile or hosted customers. Enterprises could do this themselves. This also has advantages in Enterprise to Enterprise UC as well where the data is derived from the Enterprise "directory" and could facilitate end to end PPX to PBX communications especially in point to point video communications. There are certainly privacy and security issues to be addressed. The Push vs Pull model. This really would be PII in the clear but then its done voluntarily. There would have to be some work around restructuring the Header and adding some parameters but it's underutilized right now and this Use Case is a perfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: ;purpose=icon, ;purpose=info From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name, but is something like "bank", which might have some sort of validation behind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey > wrote: I agree with Pierce here and respectfully disagree that STIR might eliminate the need for other forms of caller identification. Though your use case of credit card validation is a useful one and you are right there are still applications that use SS7 for things that have nothing to do with call setup. I agree with you STIR may have more applications beyond the obvious ones of realtime session validation. It's been my experience recently that there is a use case for something MORE in the identification of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identify themselves to the consumer before establishing a conversation is exactly what this process is about. STIR is essential but it's a multi-faceted problem that may require multi-faceted solutions.. and enhanced CNAM + being only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a utility worker before I let them into my house to make repairs. I would want some validation that the call to me to reconfirm the appointments was in fact from the utility in question. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it. it may eliminate the need for other forms of caller identification beyond what STIR will provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to be unblocked by an IVR (and as I said earlier, many companies do it today). In other use cases, the TN alone is not sufficient information - my health care provider will want to know which member of the family is calling. I agree that ANI is already broadly used to improve customer service today. However, it is not usually deemed as a secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things like SS7. STIR would make this type of validation available to a broader number of companies. Going on a tangent. perhaps this is out of scope, but there is not a lot of discussion about called party hijacking. Couldn't a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it's really them before carrying a conversation, but wouldn't they want the same? From: , "Pierce A [NTK]" < Pierce.Gorman@sprint.com> Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho < fmousinh@cisco.com>, " stir@ietf.org" < stir@ietf.org> Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fraud however contact centers also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the call center. So I don't agree that STIR would "eliminate the need for caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [ mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more companies are using the caller ID for account validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my home phone number, I'm informed that I don't need to provide any further identification because my number is on file. Some (all?) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this case, the "victim" is a business, unlike the other two scenarios we've listed so far. Addressing this scenario would actually turn STIR into a feature, given it would enable contact centers of all sizes to eliminate the need for caller identification from known TNs. From: Alex Bobotek < alex@bobotek.net> Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen < br@brianrosen.net>, "Peterson, Jon" < jon.peterson@neustar.biz> Cc: " stir@ietf.org" < stir@ietf.org>, Richard Shockey < richard@shockey.us>, "'DOLLY, MARTIN C'" < md3135@att.com>, 'Robert Sparks' < rjsparks@nostrum.com> Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the following sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is simply the rendering of a spoofed number on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information. No issues with leaving this as it's a valid point. Another (increasing) motivation is to evade network and/or endpoint defenses that may block based on CPN. So however it's worded, I think it's important to allow for both attack objectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" < jon.peterson@neustar.biz> > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draft: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> < rjsparks@nostrum.com> > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_02E4_01CEDB0A.C6AC9C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

URI for a JCARD in the CALL INFO header provisioned by the calling = party and ultimately signed by the responsible entity.  The carrier = could provision this for their mobile or hosted customers.  = Enterprises could do this themselves.  This also has advantages in = Enterprise to Enterprise UC as well where the data is derived from the = Enterprise “directory” and could facilitate end to end PPX = to PBX communications especially in point to point video communications. =

 

There are certainly privacy and security issues to be = addressed.  The Push vs Pull model.  This really would be PII = in the clear but then its done voluntarily.

 

There would have to be some work around restructuring the Header and = adding some parameters but it’s underutilized right now and this = Use Case is a perfectly appropriate use.

 

https:/= /tools.ietf.org/html/draft-ietf-jcardcal-jcard-06

 

Obviously it would need to be signed but we don’t need to worry = about that ..yet.

 

From 3261

 

20.9 Call-Info

 

   The Call-Info header field provides additional = information about the

   caller or callee, depending on whether it is found in a = request or

   response.  The purpose of the URI is described by = the "purpose"

   parameter.  The "icon" parameter = designates an image suitable as an

   iconic representation of the caller or callee.  The = "info" parameter

   describes the caller or callee in general, for example, = through a web

   page.  The "card" parameter provides a = business card, for example, in

   vCard [36] or LDIF [37] formats.  Additional tokens = can be registered

   using IANA and the procedures in Section = 27.

 

   Use of the Call-Info header field can pose a security = risk.  If a

   callee fetches the URIs provided by a malicious caller, = the callee

   may be at risk for displaying inappropriate or offensive = content,

   dangerous or illegal content, and so on.  = Therefore, it is

   RECOMMENDED that a UA only render the information in the = Call-Info

   header field if it can verify the authenticity of the = element that

   originated the header field and trusts that = element.  This need not

   be the peer UA; a proxy can insert this header field = into requests.

 

   Example:

 

   Call-Info: = <http://wwww.example.com/alice/photo.jpg> = ;purpose=3Dicon,

     <http://www.example.com/alice/> = ;purpose=3Dinfo

 

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, November = 06, 2013 3:41 PM
To: Richard Shockey
Cc: Fernando = Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org = List
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

We’ve = considered adding some information that is not number and is not name, = but is something like “bank”, which might have some sort of = validation behind it.

 

Is that along the lines you were = thinking?

 

Brian

On = Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:



I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification.  = Though your use case of credit card validation is a useful one and you = are right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session = validation.=

 =

It’s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list.=

 =

_______________________________________________=

cnit mailing list=

 =

But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about.  STIR is essential but = it’s a multi-faceted problem that may require multi-faceted = solutions.. and enhanced CNAM + being only one of them.   Its = not unreasonable to discuss those.=

 =

The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. =  I would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in question.=

 =

 =

 =

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 =

Let me = rephrase it… it may eliminate the need for other forms of caller = identification beyond what STIR will provide, depending on the specific = use case. For example, a credit card company may choose to rely entirely = on STIR before allowing a card to be unblocked by an IVR (and as I said = earlier, many companies do it today). In other use cases, the TN alone = is not sufficient information – my health care provider will want = to know which member of the family is calling.=

 =

I agree = that ANI is already broadly used to improve customer service today. = However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of = companies.=

 =

 =

Going on a = tangent… perhaps this is out of scope, but there is not a lot of = discussion about called party hijacking. Couldn’t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it’s really them before carrying a = conversation, but wouldn’t they want the same? =

 =

 =

From: <Gorman&= gt;, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Dat= e: Tuesday, November = 5, 2013 at 6:05 PM
To: Fernando Mousinho <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt

=

 =

I agree with your characterization of businesses as victim of caller ID = fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center.  So I don’t agree that = STIR would “eliminate the need for caller identification from = known TNs.”=

 =

But perhaps I misunderstood your last sentence?=

 =

 =

From:=  Fernando = Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt=

 =

I would = suggest we add a new attack type to section 3. More and more companies = are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I’m informed = that I don’t need to provide any further identification because my = number is on file. Some (all?) companies that implement this type of = validation rely on SS7 today.=

 =

Ultimately,= this is yet another variation of impersonation – but in this = case, the “victim” is a business, unlike the other two = scenarios we’ve listed so far.=

 =

Addressing = this scenario would actually turn STIR into a feature, given it would = enable contact centers of all sizes to eliminate the need for caller = identification from known TNs.=

 =

 =

 =

From: Alex = Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, 2013 = at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, = "Peterson, Jon" <jon.peterson@neustar.biz>
Cc:=  "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, = MARTIN C'" <md3135@att.com>, 'Robert Sparks' = <rjsparks@nostrum.com>
Subject= : Re: [stir] = draft-peterson-stir-threats-00.txt

=

 =

Jon,

 =

Thanks for = the response.  The intention in #1 below is to clarify the = following sentence:

 =

The primary attack vector = is

  = ; therefore one where the attacker contrives for the calling = telephone

  = ; number in signaling to be a particular chosen number, one that = the

  = ; attacker does not have the authority to call from, in order for = that

  = ; number to be rendered on the terminating side. 

 =

This might = be misconstrued as indicating that the objective of spoofing is simply = the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the = rendered information.  No issues with leaving this as it’s a = valid point.  Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on = CPN. 

 =

So however = it’s worded, I think it’s important to allow for both attack = objectives of a spoofed presentation at the endpoint and in = transit.   

 =

Regards,

 =

Alex

 =

> = -----Original Message-----

> Brian = Rosen

> Sent: = Tuesday, October 01, 2013 9:29 AM

> To: = Peterson, Jon

> = Cc: stir@ietf.org; Alex Bobotek; 'Robert = Sparks'; 'DOLLY, MARTIN C'; Richard

> = Shockey

> = Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

>&n= bsp;

> Don't = think there is much MESSAGE.  MSRP is about all we see, and XMPP = is

> more = likely than that.

>&n= bsp;

> = Brian

>&n= bsp;

> On = Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <jon.peterson@neustar.biz<= /span>>

> = wrote:

>&n= bsp;

> > = Thanks for these notes, Alex. Some responses = below.

> = >

> = >> Here are several comments that should feed into the IETF = Peterson draft:

> = >>

> = >> *   Remove any assumptions that the solution cannot = be in-network

> = [IMO,

> = >> both endpoint and in-network solutions should be = facilitated]

> = >

> > = Agreed that both in-band and out-of-band solutions can usually = be

> > = implemented in either endpoints or in intermediaries of various = kinds.

> > = If I see text that implies otherwise, I'll certainly change = it.

> = >

> = >> *   Add a sessionless attack scenario.  A spam = payload may be carried in

> = a

> = >> SIP INVITE or MESSAGE, which might contain stock market advice = even

> = >> in a display name field.  These attacks do NOT require = session

> = establishment.

> = >> More generally, we should be mindful of the fact that SIP is = used in

> = >> telephony form more than voice session = setup.

> = >

> > = Probably if we were going to include a sessionless attack scenario, = it

> > = would be with regular text messages (whether carried on the PSTN = over

> > = TCAP or with some Internet protocol, including MESSAGE) rather = than

> > = with an INVITE, which typically wouldn't result in a payload = being

> > = immediately rendered to a user. More on this below with your = suggested

> = text.

> = >

> = >> Here's some suggested = markup:

> = >>

> = >>

> = >> 1.    Replace 2nd sentence of 2nd paragraph of = 1.0 Introduction with:

> = >>

> = >> The primary attack vector is

> = >>  therefore one where the attacker contrives for the = calling telephone

> = >> number in signaling to be a particular chosen number that = the

> = >> attacker does not have the authority to call = from.

> = >

> > = What you want here is to remove the implication that the number = will

> > = be rendered on the terminating side? While there are some = attacks

> > = where that isn't significant, perhaps, I would say it is = significant

> > = in the primary attack vectors that concern = us.

> = >

> = >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:

> = >>

> = >>     Smart devices are generally based on = computers with some degree

> = >> of programmability, the capacity to access the Internet, = and

> = >> capabilities of rendering text, audio and/or images.  This = includes

> = >> smart phones, telephone applications on desktop and laptop = computers,

> = >> IP private branch exchanges, and so = on.

> = >

> > = I can add the notion that smart devices can render text, audio = and/or

> > = images as you suggest.

> = >

> = >> 3.  Add to 3.3 Attack = Scenarios:

> = >>

> = >>       Impersonation, IP-Mobile Text = Message

> = >>

> = >>        An attacker with an = computer sends a high volume of SIP = MESSAGE

> = >> spam message to IP-enabled smart phones using randomized = calling

> = >> party numbers.

> = >>

> = >>       Countermeasure: in-band = authenticated identity

> = >

> > = Provided we're talking about end-to-end SIP use of MESSAGE, = agreed

> > = that in-band would be the right countermeasure. I am curious = though

> > = whether practically speaking there is enough use of MESSAGE in = this

> > = fashion that we're actually seeing high-volume spam over = MESSAGE

> > = today. Either way, no problem having an attack scenario of this form in = the

> = document.

> = >

> > = Jon Peterson

> > = Neustar, Inc.

> = >

> = >> Regards,

> = >>

> = >> Alex

> = >>

> = >>> -----Original = Message-----

> = >>> Of Richard Shockey

> = >>> Sent: Monday, September 30, 2013 1:11 = PM

> = >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'

> = >>> Cc: stir@ietf.org<= o:p>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>

> = >>> +1

> = >>>

> = >>> -----Original = Message-----

> = >>> Of DOLLY, MARTIN C

> = >>> Sent: Monday, September 30, 2013 12:58 = PM

> = >>> To: Robert Sparks

> = >>> Cc: stir@ietf.org<= o:p>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>

> = >>> Yes, ok

> = >>>

> = >>> Martin Dolly

> = >>> Lead Member of Technical = Staff

> = >>> Core Network & Gov't/Regulatory Standards AT&T Labs = - Network

> = >>> Technology

> = >>> +1-609-903-3360

> = >>> md3135@att.com=

> = >>>

> = >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"

> = >>> wrote:

> = >>>>

> = >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C = wrote:

> = >>>>> With Hadriel comments incorporated, it is a = start

> = >>>> Hi Martin -

> = >>>>

> = >>>> Just to make sure - I think you're referring to = Hadriel's comments

> = >>>> on the

> = >>> problem statement = document?

> = >>>> I don't think Hadriel's commented directly on = stir-threats yet.

> = >>>>

> = >>>> In any case, we _are_ talking about a starting place, = not a

> = >>>> finished

> = >>> product.

> = >>>>

> = >>>> If there's no other objection, I'd like to get Jon to = submit the

> = >>>> threats

> = >>> document as a WG -00 as soon as it's = convenient.

> = >>>>

> = >>>> RjS

> = >>>>>

> = >>>>> -----Original = Message-----

> = >>>>> Behalf Of Russ = Housley

> = >>>>> Sent: Thursday, September 26, 2013 4:37 = PM

> = >>>>> To: IETF STIR Mail = List

> = >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>>>

> = >>>>> It has been six days, I'd like to hear from more = people about this

> = >>> document.  Martin asked for an additional week, so I'm = sure we will

> = >>> hear from him soon.

> = >>>>>

> = >>>>> Russ

> = >>>>>

> = >>>>>

> = >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley = wrote:

> = >>>>>>

> = >>>>>>

> = >>>>>> Should the working group adopt this I-D as the = starting point for

> = >>>>>> the

> = >>> STIR threat docuent?

> = >>>>>>

> = >>>>>> Russ

> = >>>>> = _______________________________________________

> = >>>>> stir mailing = list

> = >>>>> stir@ietf.org<= o:p>

> = >>>>

> = >>>> = _______________________________________________

> = >>>> stir mailing list

> = >>>> stir@ietf.org<= o:p>

> = >>> = _______________________________________________

> = >>> stir mailing list

> = >>> stir@ietf.org<= o:p>

> = >>>

> = >>> = _______________________________________________

> = >>> stir mailing list

> = >>> stir@ietf.org<= o:p>

> = >> = _______________________________________________

> = >> stir mailing list

> = >> stir@ietf.org<= o:p>

> = >

> > = _______________________________________________

> > = stir mailing list

> = > stir@ietf.org<= o:p>

>&n= bsp;

> = _______________________________________________

> stir = mailing list

> stir@ietf.org<= o:p>

=

 =

This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.=

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/= mailman/listinfo/stir

<= p class=3DMsoNormal> 

------=_NextPart_000_02E4_01CEDB0A.C6AC9C80-- From br@brianrosen.net Wed Nov 6 21:59:22 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B726711E8242 for ; Wed, 6 Nov 2013 21:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzOLVESiHe6f for ; Wed, 6 Nov 2013 21:59:18 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 927D411E8152 for ; Wed, 6 Nov 2013 21:59:15 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id j7so103274qaq.19 for ; Wed, 06 Nov 2013 21:59:15 -0800 (PST) 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:message-id:references:to; bh=ey/TNA2SAK/Mn5ekufTUDV9cc0MT+IIBe4QoctlC0RE=; b=Rm3hAVz3xMjaTRQ+SjfENlGvDeSo7pjWrspmKJnW1M/s9yCHxcGI/UvXULYgFNnk/G s4NsjwZAfWOXCQNaHfy5iXrH082CMCGjExdzZZmQJXKYGbrMttjxcZ7mKr6eWgZfJU1l njE7jqYvgTS1SQIxhK107u+3oO0bH+ElDNs98Q2eh9Ft29t4KZ7eB88gGqBcZrKhlcNX h7C/IHDwIlc9wm5rybrJiVT01dwCQA+2Xg6a4RbiDVtrRWLQFW1FRuiAclFWsg/mCKy7 jLDrJyXtDsN303ZXdERuoqJySvGmJnVZ0NsxZIpuiPO099r6iV36c29fjvq/spclIqVx 3VsA== X-Gm-Message-State: ALoCoQnhFzRtIFTc6X+6XtM1irrgVd8YsvsepsppHRcUBCEh2myjAd5wbyXb8ahWqJBktJaDSxvB X-Received: by 10.49.131.2 with SMTP id oi2mr9598159qeb.82.1383803954885; Wed, 06 Nov 2013 21:59:14 -0800 (PST) Received: from hotel-wireless-v6.meeting.ietf.org ([2001:67c:370:144:6c3f:cc98:bab6:63ed]) by mx.google.com with ESMTPSA id h2sm6552896qaf.10.2013.11.06.21.59.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 21:59:14 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_98F09337-36C1-4E17-900F-9451B7F226DE" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: <02e301cedb34$af790790$0e6b16b0$@shockey.us> Date: Wed, 6 Nov 2013 21:59:09 -0800 Message-Id: <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1816) Cc: "stir@ietf.org List" , "Gorman, Pierce A \[NTK\]" , cnit@ietf.org, "Fernando Mousinho \(fmousinh\)" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 05:59:22 -0000 --Apple-Mail=_98F09337-36C1-4E17-900F-9451B7F226DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate = the data, which it has very little basis to validate. It could get a = 3rd party to do the validation, but then it=92s putting its reputation = on the back of some hired hand validator. If the responsibility is the end user/device, then the signature has no = value. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that=92s an encoding detail. All of = SIP Is XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey wrote: > URI for a JCARD in the CALL INFO header provisioned by the calling = party and ultimately signed by the responsible entity. The carrier = could provision this for their mobile or hosted customers. Enterprises = could do this themselves. This also has advantages in Enterprise to = Enterprise UC as well where the data is derived from the Enterprise = =93directory=94 and could facilitate end to end PPX to PBX = communications especially in point to point video communications. > =20 > There are certainly privacy and security issues to be addressed. The = Push vs Pull model. This really would be PII in the clear but then its = done voluntarily. > =20 > There would have to be some work around restructuring the Header and = adding some parameters but it=92s underutilized right now and this Use = Case is a perfectly appropriate use. > =20 > https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 > =20 > Obviously it would need to be signed but we don=92t need to worry = about that ..yet. > =20 > =46rom 3261 > =20 > 20.9 Call-Info > =20 > The Call-Info header field provides additional information about = the > caller or callee, depending on whether it is found in a request or > response. The purpose of the URI is described by the "purpose" > parameter. The "icon" parameter designates an image suitable as an > iconic representation of the caller or callee. The "info" = parameter > describes the caller or callee in general, for example, through a = web > page. The "card" parameter provides a business card, for example, = in > vCard [36] or LDIF [37] formats. Additional tokens can be = registered > using IANA and the procedures in Section 27. > =20 > Use of the Call-Info header field can pose a security risk. If a > callee fetches the URIs provided by a malicious caller, the callee > may be at risk for displaying inappropriate or offensive content, > dangerous or illegal content, and so on. Therefore, it is > RECOMMENDED that a UA only render the information in the Call-Info > header field if it can verify the authenticity of the element that > originated the header field and trusts that element. This need not > be the peer UA; a proxy can insert this header field into requests. > =20 > Example: > =20 > Call-Info: ;purpose=3Dicon,= > ;purpose=3Dinfo > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, November 06, 2013 3:41 PM > To: Richard Shockey > Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; = stir@ietf.org List > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > We=92ve considered adding some information that is not number and is = not name, but is something like =93bank=94, which might have some sort = of validation behind it. > =20 > Is that along the lines you were thinking? > =20 > Brian > On Nov 6, 2013, at 5:25 AM, Richard Shockey = wrote: >=20 >=20 > I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification. Though = your use case of credit card validation is a useful one and you are = right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session validation. > =20 > It=92s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list. > =20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > =20 > But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about. STIR is essential but it=92s a = multi-faceted problem that may require multi-faceted solutions.. and = enhanced CNAM + being only one of them. Its not unreasonable to = discuss those. > =20 > The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. I = would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in question. > =20 > =20 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Fernando Mousinho (fmousinh) > Sent: Tuesday, November 05, 2013 6:26 PM > To: Gorman, Pierce A [NTK]; stir@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Let me rephrase it=85 it may eliminate the need for other forms of = caller identification beyond what STIR will provide, depending on the = specific use case. For example, a credit card company may choose to rely = entirely on STIR before allowing a card to be unblocked by an IVR (and = as I said earlier, many companies do it today). In other use cases, the = TN alone is not sufficient information =96 my health care provider will = want to know which member of the family is calling. > =20 > I agree that ANI is already broadly used to improve customer service = today. However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of companies. > =20 > =20 > Going on a tangent=85 perhaps this is out of scope, but there is not a = lot of discussion about called party hijacking. Couldn=92t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it=92s really them before carrying a = conversation, but wouldn=92t they want the same?=20 > =20 > =20 > From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM > To: Fernando Mousinho , "stir@ietf.org" = > Subject: RE: [stir] draft-peterson-stir-threats-00.txt > =20 > I agree with your characterization of businesses as victim of caller = ID fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center. So I don=92t agree that STIR = would =93eliminate the need for caller identification from known TNs.=94 > =20 > But perhaps I misunderstood your last sentence? > =20 > =20 > From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com]=20 > Sent: November 05, 2013 4:34 PM > To: stir@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > I would suggest we add a new attack type to section 3. More and more = companies are using the caller ID for account validation. For example, = if I call my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I=92m informed that = I don=92t need to provide any further identification because my number = is on file. Some (all?) companies that implement this type of validation = rely on SS7 today. > =20 > Ultimately, this is yet another variation of impersonation =96 but in = this case, the =93victim=94 is a business, unlike the other two = scenarios we=92ve listed so far. > =20 > Addressing this scenario would actually turn STIR into a feature, = given it would enable contact centers of all sizes to eliminate the need = for caller identification from known TNs. > =20 > =20 > =20 > From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM > To: Brian Rosen , "Peterson, Jon" = > Cc: "stir@ietf.org" , Richard Shockey = , "'DOLLY, MARTIN C'" , 'Robert = Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Jon, > =20 > Thanks for the response. The intention in #1 below is to clarify the = following sentence: > =20 > The primary attack vector is > therefore one where the attacker contrives for the calling = telephone > number in signaling to be a particular chosen number, one that the > attacker does not have the authority to call from, in order for = that > number to be rendered on the terminating side.=20 > =20 > This might be misconstrued as indicating that the objective of = spoofing is simply the rendering of a spoofed number on the receiving = display, causing mistaken conclusions that defenses might be limited to = securing the rendered information. No issues with leaving this as it=92s = a valid point. Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on CPN.=20 > =20 > So however it=92s worded, I think it=92s important to allow for both = attack objectives of a spoofed presentation at the endpoint and in = transit. =20 > =20 > Regards, > =20 > Alex > =20 > > -----Original Message----- > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > > Brian Rosen > > Sent: Tuesday, October 01, 2013 9:29 AM > > To: Peterson, Jon > > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; = Richard > > Shockey > > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >=20 > > Don't think there is much MESSAGE. MSRP is about all we see, and = XMPP is > > more likely than that. > >=20 > > Brian > >=20 > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" = > > wrote: > >=20 > > > Thanks for these notes, Alex. Some responses below. > > > > > >> Here are several comments that should feed into the IETF Peterson = draft: > > >> > > >> * Remove any assumptions that the solution cannot be in-network > > [IMO, > > >> both endpoint and in-network solutions should be facilitated] > > > > > > Agreed that both in-band and out-of-band solutions can usually be > > > implemented in either endpoints or in intermediaries of various = kinds. > > > If I see text that implies otherwise, I'll certainly change it. > > > > > >> * Add a sessionless attack scenario. A spam payload may be = carried in > > a > > >> SIP INVITE or MESSAGE, which might contain stock market advice = even > > >> in a display name field. These attacks do NOT require session > > establishment. > > >> More generally, we should be mindful of the fact that SIP is used = in > > >> telephony form more than voice session setup. > > > > > > Probably if we were going to include a sessionless attack = scenario, it > > > would be with regular text messages (whether carried on the PSTN = over > > > TCAP or with some Internet protocol, including MESSAGE) rather = than > > > with an INVITE, which typically wouldn't result in a payload being > > > immediately rendered to a user. More on this below with your = suggested > > text. > > > > > >> Here's some suggested markup: > > >> > > >> > > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction = with: > > >> > > >> The primary attack vector is > > >> therefore one where the attacker contrives for the calling = telephone > > >> number in signaling to be a particular chosen number that the > > >> attacker does not have the authority to call from. > > > > > > What you want here is to remove the implication that the number = will > > > be rendered on the terminating side? While there are some attacks > > > where that isn't significant, perhaps, I would say it is = significant > > > in the primary attack vectors that concern us. > > > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > > >> > > >> Smart devices are generally based on computers with some = degree > > >> of programmability, the capacity to access the Internet, and > > >> capabilities of rendering text, audio and/or images. This = includes > > >> smart phones, telephone applications on desktop and laptop = computers, > > >> IP private branch exchanges, and so on. > > > > > > I can add the notion that smart devices can render text, audio = and/or > > > images as you suggest. > > > > > >> 3. Add to 3.3 Attack Scenarios: > > >> > > >> Impersonation, IP-Mobile Text Message > > >> > > >> An attacker with an computer sends a high volume of SIP = MESSAGE > > >> spam message to IP-enabled smart phones using randomized calling > > >> party numbers. > > >> > > >> Countermeasure: in-band authenticated identity > > > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > > that in-band would be the right countermeasure. I am curious = though > > > whether practically speaking there is enough use of MESSAGE in = this > > > fashion that we're actually seeing high-volume spam over MESSAGE > > > today. Either way, no problem having an attack scenario of this = form in the > > document. > > > > > > Jon Peterson > > > Neustar, Inc. > > > > > >> Regards, > > >> > > >> Alex > > >> > > >>> -----Original Message----- > > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf > > >>> Of Richard Shockey > > >>> Sent: Monday, September 30, 2013 1:11 PM > > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > > >>> Cc: stir@ietf.org > > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>> > > >>> +1 > > >>> > > >>> -----Original Message----- > > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf > > >>> Of DOLLY, MARTIN C > > >>> Sent: Monday, September 30, 2013 12:58 PM > > >>> To: Robert Sparks > > >>> Cc: stir@ietf.org > > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>> > > >>> Yes, ok > > >>> > > >>> Martin Dolly > > >>> Lead Member of Technical Staff > > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > > >>> Technology > > >>> +1-609-903-3360 > > >>> md3135@att.com > > >>> > > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > > >>>> > > >>> wrote: > > >>>> > > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > > >>>>> With Hadriel comments incorporated, it is a start > > >>>> Hi Martin - > > >>>> > > >>>> Just to make sure - I think you're referring to Hadriel's = comments > > >>>> on the > > >>> problem statement document? > > >>>> I don't think Hadriel's commented directly on stir-threats yet. > > >>>> > > >>>> In any case, we _are_ talking about a starting place, not a > > >>>> finished > > >>> product. > > >>>> > > >>>> If there's no other objection, I'd like to get Jon to submit = the > > >>>> threats > > >>> document as a WG -00 as soon as it's convenient. > > >>>> > > >>>> RjS > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On > > >>>>> Behalf Of Russ Housley > > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > > >>>>> To: IETF STIR Mail List > > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>>>> > > >>>>> It has been six days, I'd like to hear from more people about = this > > >>> document. Martin asked for an additional week, so I'm sure we = will > > >>> hear from him soon. > > >>>>> > > >>>>> Russ > > >>>>> > > >>>>> > > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > > >>>>>> > > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > > >>>>>> > > >>>>>> Should the working group adopt this I-D as the starting point = for > > >>>>>> the > > >>> STIR threat docuent? > > >>>>>> > > >>>>>> Russ > > >>>>> _______________________________________________ > > >>>>> 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 > > >>> _______________________________________________ > > >>> 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 > > >> _______________________________________________ > > >> 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 > >=20 > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > =20 >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > =20 --Apple-Mail=_98F09337-36C1-4E17-900F-9451B7F226DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think this would be a heavy lift.

If the responsible = entity was a carrier, then it would have to validate the data, which it = has very little basis to validate.  It could get a 3rd party to do = the validation, but then it=92s putting its reputation on the back of = some hired hand validator.

If the = responsibility is the end user/device, then the signature has no = value.

I do not argue that Call-Info is = suitable,  it is.

I do question JCARD vs = xCard, but that=92s an encoding detail.  All of SIP Is XML = described by schema, not = json.

Brian

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> = wrote:

URI for a JCARD in the CALL INFO header = provisioned by the calling party and ultimately signed by the = responsible entity.  The carrier could provision this for their = mobile or hosted customers.  Enterprises could do this = themselves.  This also has advantages in Enterprise to Enterprise = UC as well where the data is derived from the Enterprise =93directory=94 = and could facilitate end to end PPX to PBX communications especially in = point to point video communications.

 

There are certainly privacy and security issues to = be addressed.  The Push vs Pull model.  This really would be = PII in the clear but then its done voluntarily.

 

There would have to be some work around = restructuring the Header and adding some parameters but it=92s = underutilized right now and this Use Case is a perfectly appropriate = use.

 

https://= tools.ietf.org/html/draft-ietf-jcardcal-jcard-06

=

 

Obviously it would need to be signed but we don=92t = need to worry about that ..yet.

 

=46rom 3261

 

20.9 Call-Info

 

   The Call-Info header field provides = additional information about the

   caller or callee, depending on = whether it is found in a request or

   response.  The purpose of the = URI is described by the "purpose"

   parameter.  The "icon" parameter = designates an image suitable as an

   iconic representation of the caller = or callee.  The "info" parameter

   describes the caller or callee in = general, for example, through a web

   page.  The "card" parameter = provides a business card, for example, in

   vCard [36] or LDIF [37] = formats.  Additional tokens can be = registered

   using IANA and the procedures in = Section 27.

 

   Use of the Call-Info header field can = pose a security risk.  If a

   callee fetches the URIs provided by a = malicious caller, the callee

   may be at risk for displaying = inappropriate or offensive content,

   dangerous or illegal content, and so = on.  Therefore, it is

   RECOMMENDED that a UA only render the = information in the Call-Info

   header field if it can verify the = authenticity of the element that

   originated the header field and = trusts that element.  This need not

   be the peer UA; a proxy can insert = this header field into requests.

 

   Example:

 

   Call-Info: <http://wwww.example.com/a= lice/photo.jpg> ;purpose=3Dicon,

     <http://www.example.com/alice/&g= t; ;purpose=3Dinfo

 

From: Brian Rosen [mailto:br@brianrosen.net] =
Sent: Wednesday, November 06, 2013 3:41 PM
To: = Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, = Pierce A [NTK]; stir@ietf.org = List
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

We=92ve = considered adding some information that is not number and is not name, = but is something like =93bank=94, which might have some sort of = validation behind it.

 

Is that along the lines you were = thinking?

 

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:



I agree with Pierce here and respectfully disagree = that STIR might eliminate the need for other forms of caller = identification.  Though your use case of credit card validation is = a useful one and you are right there are still applications that use SS7 = for things that have nothing to do with call setup. I agree with you = STIR may have more applications beyond the obvious ones of realtime = session validation.

 

It=92s been my experience recently that there is a = use case for something MORE in the identification of the session as it = is presented to the called party. This is the CNAM + idea we are kicking = around on the CNIT list.

 

_______________________________________________

cnit mailing list

From: stir-bounces@ietf.org= [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

<= p class=3D"MsoNormal"> 

Let me rephrase it=85 it may eliminate the need for other forms = of caller identification beyond what STIR will provide, depending on the = specific use case. For example, a credit card company may choose to rely = entirely on STIR before allowing a card to be unblocked by an IVR (and = as I said earlier, many companies do it today). In other use cases, the = TN alone is not sufficient information =96 my health care provider will = want to know which member of the family is calling.

 

I agree that ANI is already broadly used to improve customer = service today. However, it is not usually deemed as a secure enough = mechanism to validate the caller (therefore this WG!), except if you are = a large organization that can leverage things like SS7. STIR would make = this type of validation available to a broader number of = companies.

 

 

Going on a tangent=85 perhaps this is out of scope, but there is = not a lot of discussion about called party hijacking. Couldn=92t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it=92s really them before carrying a = conversation, but wouldn=92t they want the same? 

 

 

From: <Gorman>, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Date= : Tuesday, = November 5, 2013 at 6:05 PM
To: Fernando Mousinho = <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt

 

I agree with your characterization of businesses as = victim of caller ID fraud however contact centers also use TN as a key = to improve information available to call agents to reduce average = time-per-call and increase capacity of the call center.  So I don=92t= agree that STIR would =93eliminate the need for caller identification = from known TNs.=94

 

But perhaps I misunderstood your last = sentence?

 

 

From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

I would suggest we add a new attack type to section 3. More and = more companies are using the caller ID for account validation. For = example, if I call my credit card provider from my office number, they = ask me for identification. If I call from my home phone number, I=92m = informed that I don=92t need to provide any further identification = because my number is on file. Some (all?) companies that implement this = type of validation rely on SS7 today.

 

Ultimately, this is yet another variation of impersonation =96 = but in this case, the =93victim=94 is a business, unlike the other two = scenarios we=92ve listed so far.

 

Addressing this scenario would actually turn STIR into a = feature, given it would enable contact centers of all sizes to eliminate = the need for caller identification from known TNs.

 

 

 

From: Alex Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, = 2013 at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, "Peterson, = Jon" <jon.peterson@neustar.biz>
Cc:<= span class=3D"apple-converted-space"> "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, = MARTIN C'" <md3135@att.com>, 'Robert Sparks' = <rjsparks@nostrum.com>
Subject:=  Re: [stir] = draft-peterson-stir-threats-00.txt

 

Jon,

 

Thanks for the response.  The intention in #1 below is to = clarify the following sentence:

 

The primary attack vector = is

   therefore one where the attacker contrives for the = calling telephone

   number in signaling to be a particular chosen = number, one that the

   attacker does not have the authority to call = from, in order for = that

   number to be rendered on the terminating = side. 

 

This might be misconstrued as indicating that the objective of = spoofing is simply the rendering of a spoofed number on the receiving = display, causing mistaken conclusions that defenses might be limited to = securing the rendered information.  No issues with leaving this as = it=92s a valid point.  Another (increasing) motivation is to evade = network and/or endpoint defenses that may block based on = CPN. 

 

So however it=92s worded, I think it=92s important to allow for = both attack objectives of a spoofed presentation at the endpoint and in = transit.   

 

Regards,

 

Alex

 

> -----Original = Message-----

> Brian Rosen

> Sent: Tuesday, October 01, 2013 9:29 = AM

> To: Peterson, Jon

> Cc: stir@ietf.org; Alex Bobotek; 'Robert = Sparks'; 'DOLLY, MARTIN C'; Richard

> Shockey

> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> 

> Don't think there is much MESSAGE.  MSRP is about all = we see, and XMPP is

> more likely than that.

> 

> Brian

> 

> On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <jon.peterson@neustar.biz>

> wrote:

> 

> > Thanks for these notes, Alex. Some responses = below.

> >

> >> Here are several comments that should feed into = the IETF Peterson draft:

> >>

> >> *   Remove any assumptions that the = solution cannot be in-network

> [IMO,

> >> both endpoint and in-network solutions should be = facilitated]

> >

> > Agreed that both in-band and out-of-band solutions can = usually be

> > implemented in either endpoints or in intermediaries = of various kinds.

> > If I see text that implies otherwise, I'll certainly = change it.

> >

> >> *   Add a sessionless attack = scenario.  A spam payload may be carried = in

> a

> >> SIP INVITE or MESSAGE, which might contain stock = market advice even

> >> in a display name field.  These attacks do = NOT require session

> establishment.

> >> More generally, we should be mindful of the fact = that SIP is used in

> >> telephony form more than voice session = setup.

> >

> > Probably if we were going to include a sessionless = attack scenario, it

> > would be with regular text messages (whether carried = on the PSTN over

> > TCAP or with some Internet protocol, including = MESSAGE) rather than

> > with an INVITE, which typically wouldn't result in a = payload being

> > immediately rendered to a user. More on this below = with your suggested

> text.

> >

> >> Here's some suggested = markup:

> >>

> >>

> >> 1.    Replace 2nd sentence of 2nd = paragraph of 1.0 Introduction with:

> >>

> >> The primary attack vector = is

> >>  therefore one where the attacker contrives = for the calling telephone

> >> number in signaling to be a particular chosen = number that the

> >> attacker does not have the authority to call = from.

> >

> > What you want here is to remove the implication that = the number will

> > be rendered on the terminating side? While there are = some attacks

> > where that isn't significant, perhaps, I would say it = is significant

> > in the primary attack vectors that concern = us.

> >

> >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:

> >>

> >>     Smart devices are = generally based on computers with some = degree

> >> of programmability, the capacity to access the = Internet, and

> >> capabilities of rendering text, audio and/or = images.  This includes

> >> smart phones, telephone applications on desktop = and laptop computers,

> >> IP private branch exchanges, and so = on.

> >

> > I can add the notion that smart devices can render = text, audio and/or

> > images as you = suggest.

> >

> >> 3.  Add to 3.3 Attack = Scenarios:

> >>

> >>       Impersonation, = IP-Mobile Text Message

> >>

> >>        An attacker = with an computer sends a high volume of SIP = MESSAGE

> >> spam message to IP-enabled smart phones using = randomized calling

> >> party numbers.

> >>

> >>       Countermeasure: = in-band authenticated identity

> >

> > Provided we're talking about end-to-end SIP use of = MESSAGE, agreed

> > that in-band would be the right countermeasure. I am = curious though

> > whether practically speaking there is enough use of = MESSAGE in this

> > fashion that we're actually seeing high-volume spam = over MESSAGE

> > today. Either way, no problem having an attack = scenario of this form in the

> document.

> >

> > Jon Peterson

> > Neustar, Inc.

> >

> >> Regards,

> >>

> >> Alex

> >>

> >>> -----Original = Message-----

> >>> Of Richard = Shockey

> >>> Sent: Monday, September 30, 2013 1:11 = PM

> >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> >>>

> >>> +1

> >>>

> >>> -----Original = Message-----

> >>> Of DOLLY, MARTIN = C

> >>> Sent: Monday, September 30, 2013 12:58 = PM

> >>> To: Robert = Sparks

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> >>>

> >>> Yes, ok

> >>>

> >>> Martin = Dolly

> >>> Lead Member of Technical = Staff

> >>> Core Network & Gov't/Regulatory Standards = AT&T Labs - Network

> >>> Technology

> >>> = +1-609-903-3360

> >>> md3135@att.com<= o:p>

> >>>

> >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"

> >>> wrote:

> >>>>

> >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C = wrote:

> >>>>> With Hadriel comments incorporated, it = is a start

> >>>> Hi Martin = -

> >>>>

> >>>> Just to make sure - I think you're = referring to Hadriel's comments

> >>>> on the

> >>> problem statement = document?

> >>>> I don't think Hadriel's commented directly = on stir-threats yet.

> >>>>

> >>>> In any case, we _are_ talking about a = starting place, not a

> >>>> = finished

> >>> product.

> >>>>

> >>>> If there's no other objection, I'd like to = get Jon to submit the

> >>>> threats

> >>> document as a WG -00 as soon as it's = convenient.

> >>>>

> >>>> RjS

> >>>>>

> >>>>> -----Original = Message-----

> >>>>> Behalf Of Russ = Housley

> >>>>> Sent: Thursday, September 26, 2013 = 4:37 PM

> >>>>> To: IETF STIR Mail = List

> >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> >>>>>

> >>>>> It has been six days, I'd like to hear = from more people about this

> >>> document.  Martin asked for an additional = week, so I'm sure we will

> >>> hear from him = soon.

> >>>>>

> >>>>> = Russ

> >>>>>

> >>>>>

> >>>>>> On Sep 20, 2013, at 5:23 PM, Russ = Housley wrote:

> >>>>>>

> >>>>>>

> >>>>>> Should the working group adopt = this I-D as the starting point for

> >>>>>> = the

> >>> STIR threat = docuent?

> >>>>>>

> >>>>>> = Russ

> >>>>> = _______________________________________________

> >>>>> stir mailing = list

> >>>>> stir@ietf.org

> >>>>

> >>>> = _______________________________________________

> >>>> stir mailing = list

> >>> = _______________________________________________

> >>> stir mailing = list

> >>>

> >>> = _______________________________________________

> >>> stir mailing = list

> >> = _______________________________________________

> >> stir mailing = list

> >> stir@ietf.org

> >> https://www.ietf.org/mailm= an/listinfo/stir

> >

> > = _______________________________________________

> > stir mailing list

> 

> = _______________________________________________

> stir mailing list

 


This e-mail may contain Sprint proprietary = information intended for the sole use of the recipient(s). Any use by = others is prohibited. If you are not the intended recipient, please = contact the sender and delete all copies of the message.

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/m= ailman/listinfo/stir

 


= --Apple-Mail=_98F09337-36C1-4E17-900F-9451B7F226DE-- From Pierce.Gorman@sprint.com Thu Nov 7 06:53:58 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8B921E81BE; Thu, 7 Nov 2013 06:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqnEEvqsMDhG; Thu, 7 Nov 2013 06:53:49 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8E24C21E80B4; Thu, 7 Nov 2013 06:53:48 -0800 (PST) Received: from mail216-db8-R.bigfish.com (10.174.8.247) by DB8EHSOBE008.bigfish.com (10.174.4.71) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 14:53:47 +0000 Received: from mail216-db8 (localhost [127.0.0.1]) by mail216-db8-R.bigfish.com (Postfix) with ESMTP id 7B6F6E01AF; Thu, 7 Nov 2013 14:53:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.229.32.56; KIP:(null); UIP:(null); IPV:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zzbb2dI98dI9371Ic85fh542I1432I1447Idbb0idbf2izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068h1d68deh8275fh168198mz2fh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h1155h) Received-SPF: pass (mail216-db8: domain of sprint.com designates 144.229.32.56 as permitted sender) client-ip=144.229.32.56; envelope-from=Pierce.Gorman@sprint.com; helo=pdaasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail216-db8 (localhost.localdomain [127.0.0.1]) by mail216-db8 (MessageSwitch) id 1383836023978340_5064; Thu, 7 Nov 2013 14:53:43 +0000 (UTC) Received: from DB8EHSMHS017.bigfish.com (unknown [10.174.8.242]) by mail216-db8.bigfish.com (Postfix) with ESMTP id E965F220048; Thu, 7 Nov 2013 14:53:43 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by DB8EHSMHS017.bigfish.com (10.174.4.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 14:53:42 +0000 Received: from PLSWEH02.ad.sprint.com (plsweh02.corp.sprint.com [144.226.242.131]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA7Erc1N014796 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2013 08:53:40 -0600 Received: from pdawm10a.ad.sprint.com ([169.254.2.186]) by PLSWEH02.ad.sprint.com ([144.226.242.131]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 08:53:39 -0600 From: "Gorman, Pierce A [NTK]" To: Brian Rosen , Richard Shockey Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQHO2nc0UwzhVvA23kepk+N3A5gBjZoXQFMAgAIHxfuAAI6Z8A== Date: Thu, 7 Nov 2013 14:53:38 +0000 Message-ID: References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> In-Reply-To: <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.229.76.114] Content-Type: multipart/alternative; boundary="_000_B4C06A5710F0ED4583B3CF5E9C6B21D85515B88FPDAWM10Aadsprin_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "stir@ietf.org List" , "cnit@ietf.org" , "Fernando Mousinho \(fmousinh\)" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:53:58 -0000 --_000_B4C06A5710F0ED4583B3CF5E9C6B21D85515B88FPDAWM10Aadsprin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll admit I am not familiar with v/x/jcard encoding differences or the imp= lications of their use so I'll encourage educating me if it isn't too onero= us. I'm not sure what is the concern with a 3rd party providing "validation" th= ough. There are numerous examples of 3rd parties providing validation of i= nformation including NASDAQ, NYSE, Barron's, Moody's, and the federal reser= ve banking system to name a few. Pierce From: Brian Rosen [mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org Lis= t; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the= data, which it has very little basis to validate. It could get a 3rd part= y to do the validation, but then it's putting its reputation on the back of= some hired hand validator. If the responsibility is the end user/device, then the signature has no val= ue. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is= XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey > wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party an= d ultimately signed by the responsible entity. The carrier could provision= this for their mobile or hosted customers. Enterprises could do this them= selves. This also has advantages in Enterprise to Enterprise UC as well wh= ere the data is derived from the Enterprise "directory" and could facilitat= e end to end PPX to PBX communications especially in point to point video c= ommunications. There are certainly privacy and security issues to be addressed. The Push = vs Pull model. This really would be PII in the clear but then its done vol= untarily. There would have to be some work around restructuring the Header and adding= some parameters but it's underutilized right now and this Use Case is a pe= rfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that = ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: ;purpose=3Dicon, ;purpose=3Dinfo From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name= , but is something like "bank", which might have some sort of validation be= hind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey > wrote: I agree with Pierce here and respectfully disagree that STIR might eliminat= e the need for other forms of caller identification. Though your use case = of credit card validation is a useful one and you are right there are still= applications that use SS7 for things that have nothing to do with call set= up. I agree with you STIR may have more applications beyond the obvious one= s of realtime session validation. It's been my experience recently that there is a use case for something MOR= E in the identification of the session as it is presented to the called par= ty. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identi= fy themselves to the consumer before establishing a conversation is exactly= what this process is about. STIR is essential but it's a multi-faceted pr= oblem that may require multi-faceted solutions.. and enhanced CNAM + being = only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a = utility worker before I let them into my house to make repairs. I would wa= nt some validation that the call to me to reconfirm the appointments was in= fact from the utility in question. From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it... it may eliminate the need for other forms of caller i= dentification beyond what STIR will provide, depending on the specific use = case. For example, a credit card company may choose to rely entirely on STI= R before allowing a card to be unblocked by an IVR (and as I said earlier, = many companies do it today). In other use cases, the TN alone is not suffic= ient information - my health care provider will want to know which member o= f the family is calling. I agree that ANI is already broadly used to improve customer service today.= However, it is not usually deemed as a secure enough mechanism to validate= the caller (therefore this WG!), except if you are a large organization th= at can leverage things like SS7. STIR would make this type of validation av= ailable to a broader number of companies. Going on a tangent... perhaps this is out of scope, but there is not a lot = of discussion about called party hijacking. Couldn't a man-in-the-middle tr= y to answer calls on my behalf? If my bank is calling me, I want to make su= re it's really them before carrying a conversation, but wouldn't they want = the same? From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho >, "sti= r@ietf.org" > Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fra= ud however contact centers also use TN as a key to improve information avai= lable to call agents to reduce average time-per-call and increase capacity = of the call center. So I don't agree that STIR would "eliminate the need f= or caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more compan= ies are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for identificati= on. If I call from my home phone number, I'm informed that I don't need to = provide any further identification because my number is on file. Some (all?= ) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this ca= se, the "victim" is a business, unlike the other two scenarios we've listed= so far. Addressing this scenario would actually turn STIR into a feature, given it = would enable contact centers of all sizes to eliminate the need for caller = identification from known TNs. From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen >, "Peterson, J= on" > Cc: "stir@ietf.org" >, Richard Shockey >, "'DO= LLY, MARTIN C'" >, 'Robert Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the follo= wing sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is = simply the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the rendere= d information. No issues with leaving this as it's a valid point. Another= (increasing) motivation is to evade network and/or endpoint defenses that = may block based on CPN. So however it's worded, I think it's important to allow for both attack obj= ectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bo= unces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; '= DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" > > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draf= t: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried = in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in= the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> > > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [mailto:s= tir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_B4C06A5710F0ED4583B3CF5E9C6B21D85515B88FPDAWM10Aadsprin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll admit I am not= familiar with v/x/jcard encoding differences or the implications of their = use so I’ll encourage educating me if it isn’t too onerous.

 

I’m not sure what i= s the concern with a 3rd party providing “validation”= ; though.  There are numerous examples of 3rd parties provi= ding validation of information including NASDAQ, NYSE, Barron’s, Moody= 217;s, and the federal reserve banking system to name a few.

 

Pierce

 

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: November 06, 2013 11:59 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.= org List; cnit@ietf.org
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

I think this would be a heavy lift.

 

If the responsible entity was a carrier, then it wou= ld have to validate the data, which it has very little basis to validate. &= nbsp;It could get a 3rd party to do the validation, but then it’s put= ting its reputation on the back of some hired hand validator.

 

If the responsibility is the end user/device, then t= he signature has no value.

 

I do not argue that Call-Info is suitable,  it = is.

 

I do question JCARD vs xCard, but that’s an en= coding detail.  All of SIP Is XML described by schema, not json.

 

Brian

 

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> wrote:



URI for a JCARD in the = CALL INFO header provisioned by the calling party and ultimately signed by = the responsible entity.  The carrier could provision this for their mobile or hosted customers.  Enterprises could do this them= selves.  This also has advantages in Enterprise to Enterprise UC as we= ll where the data is derived from the Enterprise “directory” an= d could facilitate end to end PPX to PBX communications especially in point to point video communications.

 

There are certainly pri= vacy and security issues to be addressed.  The Push vs Pull model.&nbs= p; This really would be PII in the clear but then its done voluntarily.

 

There would have to be = some work around restructuring the Header and adding some parameters but it= ’s underutilized right now and this Use Case is a perfectly appropriate use.

 

https://tools.ietf.org/html/d= raft-ietf-jcardcal-jcard-06

 

Obviously it would need= to be signed but we don’t need to worry about that ..yet.

 

From 3261

 

20.9 Call-Info

 

   The Call-I= nfo header field provides additional information about the

   caller or = callee, depending on whether it is found in a request or

   response.&= nbsp; The purpose of the URI is described by the "purpose"=

   parameter.=   The "icon" parameter designates an image suitable as an

   iconic rep= resentation of the caller or callee.  The "info" parameter

   describes = the caller or callee in general, for example, through a web

   page. = ; The "card" parameter provides a business card, for example, in<= /span>

   vCard [36]= or LDIF [37] formats.  Additional tokens can be registered

   using IANA= and the procedures in Section 27.

 

   Use of the= Call-Info header field can pose a security risk.  If a

   callee fet= ches the URIs provided by a malicious caller, the callee

   may be at = risk for displaying inappropriate or offensive content,

   dangerous = or illegal content, and so on.  Therefore, it is

   RECOMMENDE= D that a UA only render the information in the Call-Info

   header fie= ld if it can verify the authenticity of the element that

   originated= the header field and trusts that element.  This need not

   be the pee= r UA; a proxy can insert this header field into requests.

 

   Example:

 

   Call-Info:= <http://wwww.exampl= e.com/alice/photo.jpg> ;purpose=3Dicon,

    = ; <http://www.example.com/alic= e/> ;purpose=3Dinfo

 

From: Bria= n Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, November 06, 2013 3:41 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

We’ve considered adding some information that = is not number and is not name, but is something like “bank”, wh= ich might have some sort of validation behind it.

 

Is that along the lines you were thinking?

 

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> wrote:




I agree with Pierce her= e and respectfully disagree that STIR might eliminate the need for other fo= rms of caller identification.  Though your use case of credit card validation is a useful one and you are right there are still applicat= ions that use SS7 for things that have nothing to do with call setup. I agr= ee with you STIR may have more applications beyond the obvious ones of real= time session validation.

 

It’s been my expe= rience recently that there is a use case for something MORE in the identifi= cation of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list.=

 

_______________________= ________________________

cnit mailing list

 

But your use case of a = bank wanting to make sure they could properly identify themselves to the co= nsumer before establishing a conversation is exactly what this process is about.  STIR is essential but it’s a multi-face= ted problem that may require multi-faceted solutions.. and enhanced CNAM &#= 43; being only one of them.   Its not unreasonable to discuss tho= se.

 

The obviously analogy i= s I would want to see some real identification of a utility worker before I= let them into my house to make repairs.  I would want some validation that the call to me to reconfirm the appointments was in fact f= rom the utility in question.

 

 

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org= ] On Behalf Of Fernando Mousinho (fmousinh)=
Sent: Tuesday, Nov= ember 05, 2013 6:26 PM
To: Gorman, Pierce= A [NTK]; stir@ietf.org
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

Let me rephrase it… it may elimi= nate the need for other forms of caller identification beyond what STIR wil= l provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a = card to be unblocked by an IVR (and as I said earlier, many companies do it= today). In other use cases, the TN alone is not sufficient information = 211; my health care provider will want to know which member of the family is calling.

 

I agree that ANI is already broadly us= ed to improve customer service today. However, it is not usually deemed as = a secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things= like SS7. STIR would make this type of validation available to a broader n= umber of companies.

 

 

Going on a tangent… perhaps this= is out of scope, but there is not a lot of discussion about called party h= ijacking. Couldn’t a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it’s really= them before carrying a conversation, but wouldn’t they want the same= ? 

 

 

From: <Gorman>, "Pierce = A [NTK]" <Pierce.Gorman@sprint.com>
Date: Tuesday, Nov= ember 5, 2013 at 6:05 PM
To: Fernando Mousi= nho <fmousinh@cisco.com>, "= stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir= ] draft-peterson-stir-threats-00.txt

 

I agree with your charact= erization of businesses as victim of caller ID fraud however contact center= s also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of th= e call center.  So I don’t agree that STIR would “eliminat= e the need for caller identification from known TNs.”

 

But perhaps I misundersto= od your last sentence?

 

 

From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05,= 2013 4:34 PM
To: stir@ietf.org Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

I would suggest we add a new attack ty= pe to section 3. More and more companies are using the caller ID for accoun= t validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my h= ome phone number, I’m informed that I don’t need to provide any= further identification because my number is on file. Some (all?) companies= that implement this type of validation rely on SS7 today.

 

Ultimately, this is yet another variat= ion of impersonation – but in this case, the “victim” is = a business, unlike the other two scenarios we’ve listed so far.

 

Addressing this scenario would actuall= y turn STIR into a feature, given it would enable contact centers of all si= zes to eliminate the need for caller identification from known TNs.

 

 

 

From: Alex Bobotek <alex@bobotek.net>
Date: Tuesday, Oct= ober 1, 2013 at 12:51 PM
To: Brian Rosen &l= t;br@bri= anrosen.net>, "Peterson, Jon" <jon.peterson@neust= ar.biz>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey <richard@shockey.us>, "'DOLLY, MARTIN C'" <md3135@att.com>, 'Robert Sparks' <= rjspa= rks@nostrum.com>
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

Jon,

 

Thanks for the response.  The int= ention in #1 below is to clarify the following sentence:

 

The primary <= /span>attack vector is

   therefore one where the a= ttacker contrives for the calling telephone

   number in signaling to be= a particular chosen number, one that the

   attacker does not have th= e authority to call from, in order for that

   number to be rendered = on the terminating side. 

 

This might be misconstrued as indicati= ng that the objective of spoofing is simply the rendering of a spoofed numb= er on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information.  = ;No issues with leaving this as it’s a valid point.  Another (in= creasing) motivation is to evade network and/or endpoint defenses that may = block based on CPN. 

 

So however it’s worded, I think = it’s important to allow for both attack objectives of a spoofed prese= ntation at the endpoint and in transit.   

 

Regards,

 

Alex

 

> -----Original Message-----=

> Brian Rosen

> Sent: Tuesday, October 01, 2013 9= :29 AM

> To: Peterson, Jon

> Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard

> Shockey

> Subject: Re: [stir] draft-peterso= n-stir-threats-00.txt

> 

> Don't think there is much MESSAGE= .  MSRP is about all we see, and XMPP is

> more likely than that.

> 

> Brian

> 

> On Oct 1, 2013, at 12:24 PM, &quo= t;Peterson, Jon" <jon.peterson@neustar.biz<= /span>>

> wrote:

> 

> > Thanks for these notes, Alex= . Some responses below.

> >

> >> Here are several comment= s that should feed into the IETF Peterson draft:

> >>

> >> *   Remove any= assumptions that the solution cannot be in-network

> [IMO,

> >> both endpoint and in-net= work solutions should be facilitated]

> >

> > Agreed that both in-band and= out-of-band solutions can usually be

> > implemented in either endpoi= nts or in intermediaries of various kinds.

> > If I see text that implies o= therwise, I'll certainly change it.

> >

> >> *   Add a sess= ionless attack scenario.  A spam payload may be carried in

> a

> >> SIP INVITE or MESSAGE, w= hich might contain stock market advice even

> >> in a display name field.=   These attacks do NOT require session

> establishment.

> >> More generally, we shoul= d be mindful of the fact that SIP is used in

> >> telephony form more than= voice session setup.

> >

> > Probably if we were going to= include a sessionless attack scenario, it

> > would be with regular text m= essages (whether carried on the PSTN over

> > TCAP or with some Internet p= rotocol, including MESSAGE) rather than

> > with an INVITE, which typica= lly wouldn't result in a payload being

> > immediately rendered to a us= er. More on this below with your suggested

> text.

> >

> >> Here's some suggested ma= rkup:

> >>

> >>

> >> 1.    Rep= lace 2nd sentence of 2nd paragraph of 1.0 Introduction with:

> >>

> >> The primary attack vecto= r is

> >>  therefore one wher= e the attacker contrives for the calling telephone

> >> number in signaling to b= e a particular chosen number that the

> >> attacker does not have t= he authority to call from.

> >

> > What you want here is to rem= ove the implication that the number will

> > be rendered on the terminati= ng side? While there are some attacks

> > where that isn't significant= , perhaps, I would say it is significant

> > in the primary attack vector= s that concern us.

> >

> >> 2.  Replace 3rd par= agraph of 2.1 Endpoints with:

> >>

> >>     = Smart devices are generally based on computers with some degree

> >> of programmability, the = capacity to access the Internet, and

> >> capabilities of renderin= g text, audio and/or images.  This includes

> >> smart phones, telephone = applications on desktop and laptop computers,

> >> IP private branch exchan= ges, and so on.

> >

> > I can add the notion that sm= art devices can render text, audio and/or

> > images as you suggest.

> >

> >> 3.  Add to 3.3 Atta= ck Scenarios:

> >>

> >>     =   Impersonation, IP-Mobile Text Message

> >>

> >>     =    An attacker with an computer sends a high volume of SIP MESSAG= E

> >> spam message to IP-enabl= ed smart phones using randomized calling

> >> party numbers.

> >>

> >>     =   Countermeasure: in-band authenticated identity

> >

> > Provided we're talking about= end-to-end SIP use of MESSAGE, agreed

> > that in-band would be the ri= ght countermeasure. I am curious though

> > whether practically speaking= there is enough use of MESSAGE in this

> > fashion that we're actually = seeing high-volume spam over MESSAGE

> > today. Either way, no proble= m having an attack scenario of this form in the

> document.

> >

> > Jon Peterson

> > Neustar, Inc.

> >

> >> Regards,

> >>

> >> Alex

> >>

> >>> -----Original Messag= e-----

> >>> Of Richard Shockey

> >>> Sent: Monday, Septem= ber 30, 2013 1:11 PM

> >>> To: 'DOLLY, MARTIN C= '; 'Robert Sparks'

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> >>>

> >>> +1

> >>>

> >>> -----Original Messag= e-----

> >>> Of DOLLY, MARTIN C

> >>> Sent: Monday, Septem= ber 30, 2013 12:58 PM

> >>> To: Robert Sparks

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> >>>

> >>> Yes, ok

> >>>

> >>> Martin Dolly<= /p>

> >>> Lead Member of Techn= ical Staff

> >>> Core Network & G= ov't/Regulatory Standards AT&T Labs - Network

> >>> Technology

> >>> +1-609-903-3360<= /span>

> >>>

> >>>> On Sep 30, 2013,= at 12:47 PM, "Robert Sparks"

> >>> wrote:

> >>>>

> >>>>> On 9/26/13 3= :42 PM, DOLLY, MARTIN C wrote:

> >>>>> With Hadriel= comments incorporated, it is a start

> >>>> Hi Martin -

> >>>>

> >>>> Just to make sur= e - I think you're referring to Hadriel's comments

> >>>> on the

> >>> problem statement do= cument?

> >>>> I don't think Ha= driel's commented directly on stir-threats yet.

> >>>>

> >>>> In any case, we = _are_ talking about a starting place, not a

> >>>> finished<= /p>

> >>> product.

> >>>>

> >>>> If there's no ot= her objection, I'd like to get Jon to submit the

> >>>> threats

> >>> document as a WG -00= as soon as it's convenient.

> >>>>

> >>>> RjS

> >>>>>

> >>>>> -----Origina= l Message-----

> >>>>> From: stir-bounc= es@ietf.org [<= a href=3D"mailto:stir-bounces@ietf.org">mailto:stir-bounces@ietf.org] On

> >>>>> Behalf Of Ru= ss Housley

> >>>>> Sent: Thursd= ay, September 26, 2013 4:37 PM

> >>>>> To: IETF STI= R Mail List

> >>>>> Subject: Re:= [stir] draft-peterson-stir-threats-00.txt

> >>>>>

> >>>>> It has been = six days, I'd like to hear from more people about this

> >>> document.  Mart= in asked for an additional week, so I'm sure we will

> >>> hear from him soon.<= /span>

> >>>>>

> >>>>> Russ<= /p>

> >>>>>

> >>>>>

> >>>>>> On Sep 2= 0, 2013, at 5:23 PM, Russ Housley wrote:

> >>>>>>

> >>>>>>

> >>>>>> Should t= he working group adopt this I-D as the starting point for

> >>>>>> the

> >>> STIR threat docuent?=

> >>>>>>

> >>>>>> Russ

> >>>>> ____________= ___________________________________

> >>>>> stir mailing= list

> >>>>> stir@ietf.org

> >>>>

> >>>> ________________= _______________________________

> >>>> stir mailing lis= t

> >>>> stir@ietf.org

> >>> ____________________= ___________________________

> >>> stir mailing list

> >>> stir@ietf.org=

> >>>

> >>> ____________________= ___________________________

> >>> stir mailing list

> >>> stir@ietf.org=

> >> ________________________= _______________________

> >> stir mailing list=

> >

> > ____________________________= ___________________

> > stir mailing list

> 

> _________________________________= ______________

> stir mailing list

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

_____________________________________= __________
stir mailing list
stir@ietf.org
https://www.ietf.org= /mailman/listinfo/stir

 

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_B4C06A5710F0ED4583B3CF5E9C6B21D85515B88FPDAWM10Aadsprin_-- From Henning.Schulzrinne@fcc.gov Thu Nov 7 07:00:32 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3954821E8221; Thu, 7 Nov 2013 07:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiLWRWSSoCH2; Thu, 7 Nov 2013 07:00:20 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC3921E81D6; Thu, 7 Nov 2013 07:00:18 -0800 (PST) Message-ID: From: Henning Schulzrinne To: "'Gorman, Pierce A [NTK]'" , Brian Rosen , Richard Shockey Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQHO28lBm7MQs/E/Y0C8yrTGiGFz45oZ21rg Date: Thu, 7 Nov 2013 15:00:16 +0000 References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FC237B6p2pxmb13fccnetw_" MIME-Version: 1.0 Cc: "stir@ietf.org List" , "Fernando Mousinho \(fmousinh\)" , "cnit@ietf.org" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:00:32 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FC237B6p2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a thought experiment, Kumiko Ono and I had published a draft http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 to allow third parties to validate property information. If the validating = party (e.g., a bank regulator) is willing to sign a certificate, similar in= spirit to the framed gold-leaf diplomas in your dentist's office or, more = lowly, to the health departments rating in a restaurant window, and it can = be tied to a phone number, this shouldn't be too hard. It's a bit harder if the certifying authority (regulator, Realtor board, lo= cal bar association, ...) is not involved. Henning From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gor= man, Pierce A [NTK] Sent: Thursday, November 07, 2013 9:54 AM To: Brian Rosen; Richard Shockey Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I'll admit I am not familiar with v/x/jcard encoding differences or the imp= lications of their use so I'll encourage educating me if it isn't too onero= us. I'm not sure what is the concern with a 3rd party providing "validation" th= ough. There are numerous examples of 3rd parties providing validation of i= nformation including NASDAQ, NYSE, Barron's, Moody's, and the federal reser= ve banking system to name a few. Pierce From: Brian Rosen [mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the= data, which it has very little basis to validate. It could get a 3rd part= y to do the validation, but then it's putting its reputation on the back of= some hired hand validator. If the responsibility is the end user/device, then the signature has no val= ue. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is= XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey > wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party an= d ultimately signed by the responsible entity. The carrier could provision= this for their mobile or hosted customers. Enterprises could do this them= selves. This also has advantages in Enterprise to Enterprise UC as well wh= ere the data is derived from the Enterprise "directory" and could facilitat= e end to end PPX to PBX communications especially in point to point video c= ommunications. There are certainly privacy and security issues to be addressed. The Push = vs Pull model. This really would be PII in the clear but then its done vol= untarily. There would have to be some work around restructuring the Header and adding= some parameters but it's underutilized right now and this Use Case is a pe= rfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that = ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: ;purpose=3Dicon, ;purpose=3Dinfo From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name= , but is something like "bank", which might have some sort of validation be= hind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey > wrote: I agree with Pierce here and respectfully disagree that STIR might eliminat= e the need for other forms of caller identification. Though your use case = of credit card validation is a useful one and you are right there are still= applications that use SS7 for things that have nothing to do with call set= up. I agree with you STIR may have more applications beyond the obvious one= s of realtime session validation. It's been my experience recently that there is a use case for something MOR= E in the identification of the session as it is presented to the called par= ty. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identi= fy themselves to the consumer before establishing a conversation is exactly= what this process is about. STIR is essential but it's a multi-faceted pr= oblem that may require multi-faceted solutions.. and enhanced CNAM + being = only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a = utility worker before I let them into my house to make repairs. I would wa= nt some validation that the call to me to reconfirm the appointments was in= fact from the utility in question. From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it... it may eliminate the need for other forms of caller i= dentification beyond what STIR will provide, depending on the specific use = case. For example, a credit card company may choose to rely entirely on STI= R before allowing a card to be unblocked by an IVR (and as I said earlier, = many companies do it today). In other use cases, the TN alone is not suffic= ient information - my health care provider will want to know which member o= f the family is calling. I agree that ANI is already broadly used to improve customer service today.= However, it is not usually deemed as a secure enough mechanism to validate= the caller (therefore this WG!), except if you are a large organization th= at can leverage things like SS7. STIR would make this type of validation av= ailable to a broader number of companies. Going on a tangent... perhaps this is out of scope, but there is not a lot = of discussion about called party hijacking. Couldn't a man-in-the-middle tr= y to answer calls on my behalf? If my bank is calling me, I want to make su= re it's really them before carrying a conversation, but wouldn't they want = the same? From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho >, "sti= r@ietf.org" > Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fra= ud however contact centers also use TN as a key to improve information avai= lable to call agents to reduce average time-per-call and increase capacity = of the call center. So I don't agree that STIR would "eliminate the need f= or caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more compan= ies are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for identificati= on. If I call from my home phone number, I'm informed that I don't need to = provide any further identification because my number is on file. Some (all?= ) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this ca= se, the "victim" is a business, unlike the other two scenarios we've listed= so far. Addressing this scenario would actually turn STIR into a feature, given it = would enable contact centers of all sizes to eliminate the need for caller = identification from known TNs. From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen >, "Peterson, J= on" > Cc: "stir@ietf.org" >, Richard Shockey >, "'DO= LLY, MARTIN C'" >, 'Robert Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the follo= wing sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is = simply the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the rendere= d information. No issues with leaving this as it's a valid point. Another= (increasing) motivation is to evade network and/or endpoint defenses that = may block based on CPN. So however it's worded, I think it's important to allow for both attack obj= ectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bo= unces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; '= DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" > > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draf= t: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried = in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in= the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> > > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [mailto:s= tir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_E6A16181E5FD2F46B962315BB05962D01FC237B6p2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a thought experiment, = Kumiko Ono and I had published a draft

 <= /p>

http://tools.ietf.org/htm= l/draft-ono-dispatch-attribute-validation-00

 <= /p>

to allow third parties to= validate property information. If the validating party (e.g., a bank regul= ator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist’s office or, more l= owly, to the health departments rating in a restaurant window, and it can b= e tied to a phone number, this shouldn’t be too hard.

 <= /p>

It’s a bit harder i= f the certifying authority (regulator, Realtor board, local bar association= , …) is not involved.

 <= /p>

Henning

 <= /p>

From: cnit-bou= nces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gorman, Pierce A [NTK]
Sent: Thursday, November 07, 2013 9:54 AM
To: Brian Rosen; Richard Shockey
Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh)<= br> Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

 

I’ll admit I am not f= amiliar with v/x/jcard encoding differences or the implications of their us= e so I’ll encourage educating me if it isn’t too onerous.

 

I’m not sure what is = the concern with a 3rd party providing “validation” = though.  There are numerous examples of 3rd parties providi= ng validation of information including NASDAQ, NYSE, Barron’s, Moody’s, and = the federal reserve banking system to name a few.

 

Pierce

 

From: Brian Ro= sen [mailto:br@brianrosen.net]
Sent: November 06, 2013 11:59 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org<= br> Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

I think this would be a heavy lift.

 

If the responsible entity was a carrier, then it wou= ld have to validate the data, which it has very little basis to validate. &= nbsp;It could get a 3rd party to do the validation, but then it’s put= ting its reputation on the back of some hired hand validator.

 

If the responsibility is the end user/device, then t= he signature has no value.

 

I do not argue that Call-Info is suitable,  it = is.

 

I do question JCARD vs xCard, but that’s an en= coding detail.  All of SIP Is XML described by schema, not json.<= /o:p>

 

Brian

 

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> wrote:

 

URI for a JCARD in the CA= LL INFO header provisioned by the calling party and ultimately signed by th= e responsible entity.  The carrier could provision this for their mobile or hosted customers.  Enterprises could do this them= selves.  This also has advantages in Enterprise to Enterprise UC as we= ll where the data is derived from the Enterprise “directory” an= d could facilitate end to end PPX to PBX communications especially in point to point video communications.

 <= /p>

There are certainly priva= cy and security issues to be addressed.  The Push vs Pull model. = This really would be PII in the clear but then its done voluntarily.

 <= /p>

There would have to be so= me work around restructuring the Header and adding some parameters but it&#= 8217;s underutilized right now and this Use Case is a perfectly appropriate use.

 <= /p>

https://tools.ietf.org/html/dra= ft-ietf-jcardcal-jcard-06

 <= /p>

Obviously it would need t= o be signed but we don’t need to worry about that ..yet.

 <= /p>

From 3261

 <= /p>

20.9 Call-Info

 <= /p>

   The Call-Inf= o header field provides additional information about the<= /p>

   caller or ca= llee, depending on whether it is found in a request or

   response.&nb= sp; The purpose of the URI is described by the "purpose"

   parameter.&n= bsp; The "icon" parameter designates an image suitable as an

   iconic repre= sentation of the caller or callee.  The "info" parameter

   describes th= e caller or callee in general, for example, through a web=

   page.  = The "card" parameter provides a business card, for example, in

   vCard [36] o= r LDIF [37] formats.  Additional tokens can be registered<= /o:p>

   using IANA a= nd the procedures in Section 27.

 <= /p>

   Use of the C= all-Info header field can pose a security risk.  If a

   callee fetch= es the URIs provided by a malicious caller, the callee

   may be at ri= sk for displaying inappropriate or offensive content,

   dangerous or= illegal content, and so on.  Therefore, it is

   RECOMMENDED = that a UA only render the information in the Call-Info

   header field= if it can verify the authenticity of the element that

   originated t= he header field and trusts that element.  This need not

   be the peer = UA; a proxy can insert this header field into requests.

 <= /p>

   Example:

 <= /p>

   Call-Info: &= lt;http://wwww.example.= com/alice/photo.jpg> ;purpose=3Dicon,

     = <http://www.example.com/alice/= > ;purpose=3Dinfo

 <= /p>

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, November 06, 2013 3:41 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

We’ve considered adding some information that = is not number and is not name, but is something like “bank”, wh= ich might have some sort of validation behind it.

 

Is that along the lines you were thinking?

 

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> wrote:



I agree with Pierce here = and respectfully disagree that STIR might eliminate the need for other form= s of caller identification.  Though your use case of credit card validation is a useful one and you are right there are still applicat= ions that use SS7 for things that have nothing to do with call setup. I agr= ee with you STIR may have more applications beyond the obvious ones of real= time session validation.

 <= /p>

It’s been my experi= ence recently that there is a use case for something MORE in the identifica= tion of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list.=

 <= /p>

_________________________= ______________________

cnit mailing list<= o:p>

cnit@ietf.org<= /o:p>

 <= /p>

But your use case of a ba= nk wanting to make sure they could properly identify themselves to the cons= umer before establishing a conversation is exactly what this process is about.  STIR is essential but it’s a multi-face= ted problem that may require multi-faceted solutions.. and enhanced CNAM &#= 43; being only one of them.   Its not unreasonable to discuss tho= se.

 <= /p>

The obviously analogy is = I would want to see some real identification of a utility worker before I l= et them into my house to make repairs.  I would want some validation that the call to me to reconfirm the appointments was in fact f= rom the utility in question.

 <= /p>

 <= /p>

 <= /p>

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org= ] On Behalf Of Fernando Mousinho (fmousinh)=
Sent: Tuesday, Nov= ember 05, 2013 6:26 PM
To: Gorman, Pierce= A [NTK]; stir@ietf.org
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

Let me rephrase it… it may elimin= ate the need for other forms of caller identification beyond what STIR will= provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to= be unblocked by an IVR (and as I said earlier, many companies do it today)= . In other use cases, the TN alone is not sufficient information – my= health care provider will want to know which member of the family is calling.

 

I agree that ANI is already broadly use= d to improve customer service today. However, it is not usually deemed as a= secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things= like SS7. STIR would make this type of validation available to a broader n= umber of companies.

 

 

Going on a tangent… perhaps this = is out of scope, but there is not a lot of discussion about called party hi= jacking. Couldn’t a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it’s really th= em before carrying a conversation, but wouldn’t they want the same?&n= bsp;

 

 

From: <Gorman>, "Pierce A = [NTK]" <Pierce.Gorman@sprint.com>
Date: Tuesday, Nov= ember 5, 2013 at 6:05 PM
To: Fernando Mousi= nho <fmousinh@cisco.com>, "= stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir= ] draft-peterson-stir-threats-00.txt

 

I agree with your character= ization of businesses as victim of caller ID fraud however contact centers = also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the c= all center.  So I don’t agree that STIR would “eliminate t= he need for caller identification from known TNs.”<= /p>

 

But perhaps I misunderstood= your last sentence?

 

 

From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05,= 2013 4:34 PM
To: stir@ietf.org Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

I would suggest we add a new attack typ= e to section 3. More and more companies are using the caller ID for account= validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my h= ome phone number, I’m informed that I don’t need to provide any= further identification because my number is on file. Some (all?) companies= that implement this type of validation rely on SS7 today.

 

Ultimately, this is yet another variati= on of impersonation – but in this case, the “victim” is a= business, unlike the other two scenarios we’ve listed so far.=

 

Addressing this scenario would actually= turn STIR into a feature, given it would enable contact centers of all siz= es to eliminate the need for caller identification from known TNs.

 

 

 

From: Alex Bobotek <alex@bobotek.net= >
Date: Tuesday, Oct= ober 1, 2013 at 12:51 PM
To: Brian Rosen &l= t;br@bri= anrosen.net>, "Peterson, Jon" <jon.peterson@neust= ar.biz>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey <richard@shockey.us>, "'DOLLY, MARTIN C'" <md3135@att.com>, 'Robert Sparks' <= rjspa= rks@nostrum.com>
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

Jon,

 

Thanks for the response.  The inte= ntion in #1 below is to clarify the following sentence:

 

The primary attack vector is

   therefore one where the at= tacker contrives for the calling telephone

   number in signaling to be = a particular chosen number, one that the

   attacker does not have the= authority to call from, = in order for that

   number to be rendered o= n the terminating side. 

 

This might be misconstrued as indicatin= g that the objective of spoofing is simply the rendering of a spoofed numbe= r on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information.  = ;No issues with leaving this as it’s a valid point.  Another (in= creasing) motivation is to evade network and/or endpoint defenses that may = block based on CPN. 

 

So however it’s worded, I think i= t’s important to allow for both attack objectives of a spoofed presen= tation at the endpoint and in transit.   

 

Regards,

 

Alex

 

> -----Original Message-----<= o:p>

> Brian Rosen

> Sent: Tuesday, October 01, 2013 9:= 29 AM

> To: Peterson, Jon

> Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard

> Shockey

> Subject: Re: [stir] draft-peterson= -stir-threats-00.txt

> 

> Don't think there is much MESSAGE.=   MSRP is about all we see, and XMPP is

> more likely than that.=

> 

> Brian

> 

> On Oct 1, 2013, at 12:24 PM, "= ;Peterson, Jon" <jon.peterson@neustar.biz>

> wrote:

> 

> > Thanks for these notes, Alex.= Some responses below.

> >

> >> Here are several comments= that should feed into the IETF Peterson draft:

> >>

> >> *   Remove any = assumptions that the solution cannot be in-network

> [IMO,

> >> both endpoint and in-netw= ork solutions should be facilitated]

> >

> > Agreed that both in-band and = out-of-band solutions can usually be

> > implemented in either endpoin= ts or in intermediaries of various kinds.

> > If I see text that implies ot= herwise, I'll certainly change it.

> >

> >> *   Add a sessi= onless attack scenario.  A spam payload may be carried in<= /o:p>

> a

> >> SIP INVITE or MESSAGE, wh= ich might contain stock market advice even

> >> in a display name field.&= nbsp; These attacks do NOT require session

> establishment.

> >> More generally, we should= be mindful of the fact that SIP is used in

> >> telephony form more than = voice session setup.

> >

> > Probably if we were going to = include a sessionless attack scenario, it

> > would be with regular text me= ssages (whether carried on the PSTN over

> > TCAP or with some Internet pr= otocol, including MESSAGE) rather than

> > with an INVITE, which typical= ly wouldn't result in a payload being

> > immediately rendered to a use= r. More on this below with your suggested

> text.

> >

> >> Here's some suggested mar= kup:

> >>

> >>

> >> 1.    Repl= ace 2nd sentence of 2nd paragraph of 1.0 Introduction with:

> >>

> >> The primary attack vector= is

> >>  therefore one where= the attacker contrives for the calling telephone

> >> number in signaling to be= a particular chosen number that the

> >> attacker does not have th= e authority to call from.

> >

> > What you want here is to remo= ve the implication that the number will

> > be rendered on the terminatin= g side? While there are some attacks

> > where that isn't significant,= perhaps, I would say it is significant

> > in the primary attack vectors= that concern us.

> >

> >> 2.  Replace 3rd para= graph of 2.1 Endpoints with:

> >>

> >>     S= mart devices are generally based on computers with some degree<= /o:p>

> >> of programmability, the c= apacity to access the Internet, and

> >> capabilities of rendering= text, audio and/or images.  This includes

> >> smart phones, telephone a= pplications on desktop and laptop computers,

> >> IP private branch exchang= es, and so on.

> >

> > I can add the notion that sma= rt devices can render text, audio and/or

> > images as you suggest.=

> >

> >> 3.  Add to 3.3 Attac= k Scenarios:

> >>

> >>     &= nbsp; Impersonation, IP-Mobile Text Message

> >>

> >>     &= nbsp;  An attacker with an computer sends a high volume of SIP MESSAGE=

> >> spam message to IP-enable= d smart phones using randomized calling

> >> party numbers.

> >>

> >>     &= nbsp; Countermeasure: in-band authenticated identity

> >

> > Provided we're talking about = end-to-end SIP use of MESSAGE, agreed

> > that in-band would be the rig= ht countermeasure. I am curious though

> > whether practically speaking = there is enough use of MESSAGE in this

> > fashion that we're actually s= eeing high-volume spam over MESSAGE

> > today. Either way, no problem= having an attack scenario of this form in the

> document.

> >

> > Jon Peterson

> > Neustar, Inc.

> >

> >> Regards,

> >>

> >> Alex

> >>

> >>> -----Original Message= -----

> >>> Of Richard Shockey

> >>> Sent: Monday, Septemb= er 30, 2013 1:11 PM

> >>> To: 'DOLLY, MARTIN C'= ; 'Robert Sparks'

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] d= raft-peterson-stir-threats-00.txt

> >>>

> >>> +1

> >>>

> >>> -----Original Message= -----

> >>> Of DOLLY, MARTIN C

> >>> Sent: Monday, Septemb= er 30, 2013 12:58 PM

> >>> To: Robert Sparks

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] d= raft-peterson-stir-threats-00.txt

> >>>

> >>> Yes, ok

> >>>

> >>> Martin Dolly

> >>> Lead Member of Techni= cal Staff

> >>> Core Network & Go= v't/Regulatory Standards AT&T Labs - Network

> >>> Technology

> >>> +1-609-903-3360

> >>> md3135@att.com=

> >>>

> >>>> On Sep 30, 2013, = at 12:47 PM, "Robert Sparks"

> >>> wrote:

> >>>>=

> >>>>> On 9/26/13 3:= 42 PM, DOLLY, MARTIN C wrote:

> >>>>> With Hadriel = comments incorporated, it is a start

> >>>> Hi Martin -

> >>>>=

> >>>> Just to make sure= - I think you're referring to Hadriel's comments

> >>>> on the

> >>> problem statement doc= ument?

> >>>> I don't think Had= riel's commented directly on stir-threats yet.

> >>>>=

> >>>> In any case, we _= are_ talking about a starting place, not a

> >>>> finished

> >>> product.<= /o:p>

> >>>>=

> >>>> If there's no oth= er objection, I'd like to get Jon to submit the

> >>>> threats

> >>> document as a WG -00 = as soon as it's convenient.

> >>>>=

> >>>> RjS

> >>>>>

> >>>>> -----Original= Message-----

> >>>>> Behalf Of Rus= s Housley

> >>>>> Sent: Thursda= y, September 26, 2013 4:37 PM

> >>>>> To: IETF STIR= Mail List

> >>>>> Subject: Re: = [stir] draft-peterson-stir-threats-00.txt

> >>>>>

> >>>>> It has been s= ix days, I'd like to hear from more people about this

> >>> document.  Marti= n asked for an additional week, so I'm sure we will

> >>> hear from him soon.

> >>>>>

> >>>>> Russ

> >>>>>

> >>>>>

> >>>>>> On Sep 20= , 2013, at 5:23 PM, Russ Housley wrote:

> >>>>>>

> >>>>>>

> >>>>>> Should th= e working group adopt this I-D as the starting point for<= /p>

> >>>>>> the

> >>> STIR threat docuent?<= /span>

> >>>>>>

> >>>>>> Russ

> >>>>> _____________= __________________________________

> >>>>> stir mailing = list

> >>>>> stir@ietf.org

> >>>>=

> >>>> _________________= ______________________________

> >>>> stir mailing list=

> >>>> stir@ietf.org

> >>> _____________________= __________________________

> >>> stir mailing list

> >>> stir@ietf.org<= o:p>

> >>>

> >>> _____________________= __________________________

> >>> stir mailing list

> >>> stir@ietf.org<= o:p>

> >> _________________________= ______________________

> >> stir mailing list<= o:p>

> >

> > _____________________________= __________________

> > stir mailing list=

> 

> __________________________________= _____________

> stir mailing list

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

______________________________________= _________
stir mailing list
stir@ietf.org
https://www.ietf.org= /mailman/listinfo/stir

 

 

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

--_000_E6A16181E5FD2F46B962315BB05962D01FC237B6p2pxmb13fccnetw_-- From richard@shockey.us Thu Nov 7 07:16:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D77E21E82A3 for ; Thu, 7 Nov 2013 07:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.126 X-Spam-Level: X-Spam-Status: No, score=-101.126 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTZ8w4uy-DS0 for ; Thu, 7 Nov 2013 07:16:35 -0800 (PST) Received: from alt-proxy8.mail.unifiedlayer.com (unknown [74.220.207.38]) by ietfa.amsl.com (Postfix) with SMTP id A521221E829D for ; Thu, 7 Nov 2013 07:16:13 -0800 (PST) Received: (qmail 3000 invoked by uid 0); 7 Nov 2013 15:16:12 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy19.mail.unifiedlayer.com with SMTP; 7 Nov 2013 15:16:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=liotkh2XOns4mvgLxv6NWxpzUlrIRR1S4rgFKPoxIHc=; b=X+T0lw4KDdk0NeLZDdS1+PnTiqMg3Tm1kc1oU5ETeDWVcBVYjkpGp2trTr+cXEXAU6r59EVAWbJvC0dZtCGhtX1cTrHSpegmxrKH43t1TYYbRyy8Y/9xNsO0rQLcCi7J; Received: from [173.79.179.104] (port=49527 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VeRJb-0006jA-C1; Thu, 07 Nov 2013 08:16:12 -0700 From: "Richard Shockey" To: "'Brian Rosen'" References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> In-Reply-To: <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> Date: Thu, 7 Nov 2013 10:16:09 -0500 Message-ID: <00f401cedbcc$4a7e3700$df7aa500$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F5_01CEDBA2.61B77140" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQKuxOgdsFN95Qgmj4nb3bGbN4Q20wEejKIqAhCsH9QBYcTrswHCXLsVAZF++gqYGuRbMA== X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: stir@ietf.org, "'Gorman, Pierce A \[NTK\]'" , "'Fernando Mousinho \(fmousinh\)'" , cnit@ietf.org Subject: Re: [stir] [cnit] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:16:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F5_01CEDBA2.61B77140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Like CNAM is so accurate today. ?? When certain companies get the data from scanning phone books that are not even printed anymore? The carrier has the billing relationship. As you well know that is where the data comes from now but it is not granular. The carrier permits the customer to create the record(s). What are you trying to validate? The Accuracy of the data? . In any event none of that is our problem. We make the tools. Someone else worries about policy. You are making this way too complicated thus defeating the basic use case. Well from time to time I've discovered I'm not a big fan of the end to end principal. It just doesn't work for every use case. This is a carrier service or in certain cases hosted. Much like I'm convinced the out of band solution in STIR is total fantasy and like VIPR will almost never actually be used in practice. As for encoding I mentioned JCARD since there seems to be a faction in the IETF that is anti-XML From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, November 07, 2013 12:59 AM To: Richard Shockey Cc: stir@ietf.org List; Gorman, Pierce A [NTK]; cnit@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the data, which it has very little basis to validate. It could get a 3rd party to do the validation, but then it's putting its reputation on the back of some hired hand validator. If the responsibility is the end user/device, then the signature has no value. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey > wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party and ultimately signed by the responsible entity. The carrier could provision this for their mobile or hosted customers. Enterprises could do this themselves. This also has advantages in Enterprise to Enterprise UC as well where the data is derived from the Enterprise "directory" and could facilitate end to end PPX to PBX communications especially in point to point video communications. There are certainly privacy and security issues to be addressed. The Push vs Pull model. This really would be PII in the clear but then its done voluntarily. There would have to be some work around restructuring the Header and adding some parameters but it's underutilized right now and this Use Case is a perfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: ;purpose=icon, ;purpose=info From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name, but is something like "bank", which might have some sort of validation behind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey > wrote: I agree with Pierce here and respectfully disagree that STIR might eliminate the need for other forms of caller identification. Though your use case of credit card validation is a useful one and you are right there are still applications that use SS7 for things that have nothing to do with call setup. I agree with you STIR may have more applications beyond the obvious ones of realtime session validation. It's been my experience recently that there is a use case for something MORE in the identification of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identify themselves to the consumer before establishing a conversation is exactly what this process is about. STIR is essential but it's a multi-faceted problem that may require multi-faceted solutions.. and enhanced CNAM + being only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a utility worker before I let them into my house to make repairs. I would want some validation that the call to me to reconfirm the appointments was in fact from the utility in question. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it. it may eliminate the need for other forms of caller identification beyond what STIR will provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to be unblocked by an IVR (and as I said earlier, many companies do it today). In other use cases, the TN alone is not sufficient information - my health care provider will want to know which member of the family is calling. I agree that ANI is already broadly used to improve customer service today. However, it is not usually deemed as a secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things like SS7. STIR would make this type of validation available to a broader number of companies. Going on a tangent. perhaps this is out of scope, but there is not a lot of discussion about called party hijacking. Couldn't a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it's really them before carrying a conversation, but wouldn't they want the same? From: , "Pierce A [NTK]" < Pierce.Gorman@sprint.com> Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho < fmousinh@cisco.com>, " stir@ietf.org" < stir@ietf.org> Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fraud however contact centers also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the call center. So I don't agree that STIR would "eliminate the need for caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [ mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more companies are using the caller ID for account validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my home phone number, I'm informed that I don't need to provide any further identification because my number is on file. Some (all?) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this case, the "victim" is a business, unlike the other two scenarios we've listed so far. Addressing this scenario would actually turn STIR into a feature, given it would enable contact centers of all sizes to eliminate the need for caller identification from known TNs. From: Alex Bobotek < alex@bobotek.net> Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen < br@brianrosen.net>, "Peterson, Jon" < jon.peterson@neustar.biz> Cc: " stir@ietf.org" < stir@ietf.org>, Richard Shockey < richard@shockey.us>, "'DOLLY, MARTIN C'" < md3135@att.com>, 'Robert Sparks' < rjsparks@nostrum.com> Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the following sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is simply the rendering of a spoofed number on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information. No issues with leaving this as it's a valid point. Another (increasing) motivation is to evade network and/or endpoint defenses that may block based on CPN. So however it's worded, I think it's important to allow for both attack objectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" < jon.peterson@neustar.biz> > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draft: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> < rjsparks@nostrum.com> > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00F5_01CEDBA2.61B77140 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Like CNAM is so accurate today… ??  When certain companies = get the data from scanning phone books that are not even printed = anymore?

 

The carrier has the billing relationship. As you well know that is = where the data comes from now but it is not granular.  =

 

The carrier permits the customer to create the record(s). What are = you trying to validate? The Accuracy of the data?  … In any = event none of that is our problem.   We make the tools. = Someone else worries about policy.

 

You are making this way too complicated thus defeating the basic use = case.  

 

Well from time to time I’ve discovered I’m not a big fan = of the end to end principal.  It just doesn’t work for every = use case.  This is a carrier service or in certain cases = hosted.

 

Much like I’m convinced the out of band solution in STIR is = total fantasy and like VIPR will almost never actually be used in = practice.

 

As for encoding I mentioned JCARD since there seems to be a faction = in the IETF that is anti-XML

 

From: = cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of = Brian Rosen
Sent: Thursday, November 07, 2013 12:59 = AM
To: Richard Shockey
Cc: stir@ietf.org List; = Gorman, Pierce A [NTK]; cnit@ietf.org; Fernando Mousinho = (fmousinh)
Subject: Re: [cnit] [stir] = draft-peterson-stir-threats-00.txt

 

I think this = would be a heavy lift.

 

If the responsible entity was a carrier, then it would = have to validate the data, which it has very little basis to validate. =  It could get a 3rd party to do the validation, but then it’s = putting its reputation on the back of some hired hand = validator.

 

If the responsibility is the end user/device, then the = signature has no value.

 

I = do not argue that Call-Info is suitable,  it = is.

 

I = do question JCARD vs xCard, but that’s an encoding detail. =  All of SIP Is XML described by schema, not = json.

 

Brian

 

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> = wrote:



URI for a JCARD in the CALL INFO header provisioned by the calling = party and ultimately signed by the responsible entity.  The carrier = could provision this for their mobile or hosted customers.  = Enterprises could do this themselves.  This also has advantages in = Enterprise to Enterprise UC as well where the data is derived from the = Enterprise “directory” and could facilitate end to end PPX = to PBX communications especially in point to point video communications. =

 

There are certainly privacy and security issues to be = addressed.  The Push vs Pull model.  This really would be PII = in the clear but then its done voluntarily.

 

There would have to be some work around restructuring the Header and = adding some parameters but it’s underutilized right now and this = Use Case is a perfectly appropriate use.

 

https:/= /tools.ietf.org/html/draft-ietf-jcardcal-jcard-06

 

Obviously it would need to be signed but we don’t need to worry = about that ..yet.

 

From 3261

 

20.9 Call-Info

 

   The Call-Info header field provides additional = information about the

   caller or callee, depending on whether it is found in a = request or

   response.  The purpose of the URI is described by = the "purpose"

   parameter.  The "icon" parameter = designates an image suitable as an

   iconic representation of the caller or callee.  The = "info" parameter

   describes the caller or callee in general, for example, = through a web

   page.  The "card" parameter provides a = business card, for example, in

   vCard [36] or LDIF [37] formats.  Additional tokens = can be registered

   using IANA and the procedures in Section = 27.

 

   Use of the Call-Info header field can pose a security = risk.  If a

   callee fetches the URIs provided by a malicious caller, = the callee

   may be at risk for displaying inappropriate or offensive = content,

   dangerous or illegal content, and so on.  = Therefore, it is

   RECOMMENDED that a UA only render the information in the = Call-Info

   header field if it can verify the authenticity of the = element that

   originated the header field and trusts that = element.  This need not

   be the peer UA; a proxy can insert this header field = into requests.

 

   Example:

 

   Call-Info: <http://wwww.example.com/= alice/photo.jpg> ;purpose=3Dicon,

     <http://www.example.com/alice/&= gt; ;purpose=3Dinfo

 

From: Brian = Rosen [mailto:br@brianrosen.net] =
Sent: Wednesday, November 06, 2013 3:41 PM
To: = Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, = Pierce A [NTK]; stir@ietf.org = List
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

We’ve = considered adding some information that is not number and is not name, = but is something like “bank”, which might have some sort of = validation behind it.

 

Is that along the lines you were = thinking?

 

Brian

On = Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:




I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification.  = Though your use case of credit card validation is a useful one and you = are right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session = validation.

 

It’s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list.

 

_______________________________________________

<= /div>

cnit mailing list

cnit@ietf.org

 

But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about.  STIR is essential but = it’s a multi-faceted problem that may require multi-faceted = solutions.. and enhanced CNAM + being only one of them.   Its = not unreasonable to discuss those.

 

The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. =  I would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in = question.

 

 

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

 

Let me = rephrase it… it may eliminate the need for other forms of caller = identification beyond what STIR will provide, depending on the specific = use case. For example, a credit card company may choose to rely entirely = on STIR before allowing a card to be unblocked by an IVR (and as I said = earlier, many companies do it today). In other use cases, the TN alone = is not sufficient information – my health care provider will want = to know which member of the family is = calling.

 

I agree = that ANI is already broadly used to improve customer service today. = However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of = companies.

 

 

Going on a = tangent… perhaps this is out of scope, but there is not a lot of = discussion about called party hijacking. Couldn’t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it’s really them before carrying a = conversation, but wouldn’t they want the = same? 

 

 

From: <Gorman&= gt;, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Dat= e: Tuesday, November = 5, 2013 at 6:05 PM
To: Fernando Mousinho <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt

 

I agree with your characterization of businesses as victim of caller ID = fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center.  So I don’t agree that = STIR would “eliminate the need for caller identification from = known TNs.”

 

But perhaps I misunderstood your last = sentence?

 

 

From:=  Fernando = Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

 

I would = suggest we add a new attack type to section 3. More and more companies = are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I’m informed = that I don’t need to provide any further identification because my = number is on file. Some (all?) companies that implement this type of = validation rely on SS7 today.

 

Ultimately,= this is yet another variation of impersonation – but in this = case, the “victim” is a business, unlike the other two = scenarios we’ve listed so far.

 

Addressing = this scenario would actually turn STIR into a feature, given it would = enable contact centers of all sizes to eliminate the need for caller = identification from known TNs.

 

 

 

From: Alex = Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, 2013 = at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, = "Peterson, Jon" <jon.peterson@neustar.biz>
Cc:=  "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, = MARTIN C'" <md3135@att.com>, 'Robert Sparks' = <rjsparks@nostrum.com>
Subject= : Re: [stir] = draft-peterson-stir-threats-00.txt

 

Jon,=

 

Thanks for = the response.  The intention in #1 below is to clarify the = following sentence:

 

The primary attack vector = is

  = ; therefore one where the attacker contrives for the calling = telephone

  = ; number in signaling to be a particular chosen number, one that = the

  = ; attacker does not have the authority to call from, in order for = that

  = ; number to be rendered on the terminating side. 

 

This might = be misconstrued as indicating that the objective of spoofing is simply = the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the = rendered information.  No issues with leaving this as it’s a = valid point.  Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on = CPN. 

 

So however = it’s worded, I think it’s important to allow for both attack = objectives of a spoofed presentation at the endpoint and in = transit.   

 

Regards,

 

Alex=

 

> = -----Original Message-----

> Brian = Rosen

> Sent: = Tuesday, October 01, 2013 9:29 AM

> To: = Peterson, Jon

> = Cc: stir@ietf.org; Alex Bobotek; 'Robert = Sparks'; 'DOLLY, MARTIN C'; Richard

> = Shockey

> = Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> <= /span>

> Don't = think there is much MESSAGE.  MSRP is about all we see, and XMPP = is

> more = likely than that.

> <= /span>

> = Brian

> <= /span>

> On = Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <jon.peterson@neustar.biz<= /span>>

> = wrote:

> <= /span>

> > = Thanks for these notes, Alex. Some responses = below.

> = >

> = >> Here are several comments that should feed into the IETF = Peterson draft:

> = >>

> = >> *   Remove any assumptions that the solution cannot = be in-network

> = [IMO,

> = >> both endpoint and in-network solutions should be = facilitated]

> = >

> > = Agreed that both in-band and out-of-band solutions can usually = be

> > = implemented in either endpoints or in intermediaries of various = kinds.

> > = If I see text that implies otherwise, I'll certainly change = it.

> = >

> = >> *   Add a sessionless attack scenario.  A spam = payload may be carried in

> = a

> = >> SIP INVITE or MESSAGE, which might contain stock market advice = even

> = >> in a display name field.  These attacks do NOT require = session

> = establishment.

> = >> More generally, we should be mindful of the fact that SIP is = used in

> = >> telephony form more than voice session = setup.

> = >

> > = Probably if we were going to include a sessionless attack scenario, = it

> > = would be with regular text messages (whether carried on the PSTN = over

> > = TCAP or with some Internet protocol, including MESSAGE) rather = than

> > = with an INVITE, which typically wouldn't result in a payload = being

> > = immediately rendered to a user. More on this below with your = suggested

> = text.

> = >

> = >> Here's some suggested = markup:

> = >>

> = >>

> = >> 1.    Replace 2nd sentence of 2nd paragraph of = 1.0 Introduction with:

> = >>

> = >> The primary attack vector is

> = >>  therefore one where the attacker contrives for the = calling telephone

> = >> number in signaling to be a particular chosen number that = the

> = >> attacker does not have the authority to call = from.

> = >

> > = What you want here is to remove the implication that the number = will

> > = be rendered on the terminating side? While there are some = attacks

> > = where that isn't significant, perhaps, I would say it is = significant

> > = in the primary attack vectors that concern = us.

> = >

> = >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:

> = >>

> = >>     Smart devices are generally based on = computers with some degree

> = >> of programmability, the capacity to access the Internet, = and

> = >> capabilities of rendering text, audio and/or images.  This = includes

> = >> smart phones, telephone applications on desktop and laptop = computers,

> = >> IP private branch exchanges, and so = on.

> = >

> > = I can add the notion that smart devices can render text, audio = and/or

> > = images as you suggest.

> = >

> = >> 3.  Add to 3.3 Attack = Scenarios:

> = >>

> = >>       Impersonation, IP-Mobile Text = Message

> = >>

> = >>        An attacker with an = computer sends a high volume of SIP = MESSAGE

> = >> spam message to IP-enabled smart phones using randomized = calling

> = >> party numbers.

> = >>

> = >>       Countermeasure: in-band = authenticated identity

> = >

> > = Provided we're talking about end-to-end SIP use of MESSAGE, = agreed

> > = that in-band would be the right countermeasure. I am curious = though

> > = whether practically speaking there is enough use of MESSAGE in = this

> > = fashion that we're actually seeing high-volume spam over = MESSAGE

> > = today. Either way, no problem having an attack scenario of this form in = the

> = document.

> = >

> > = Jon Peterson

> > = Neustar, Inc.

> = >

> = >> Regards,

> = >>

> = >> Alex

> = >>

> = >>> -----Original = Message-----

> = >>> Of Richard Shockey

> = >>> Sent: Monday, September 30, 2013 1:11 = PM

> = >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'

> = >>> Cc: stir@ietf.org<= /span>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>

> = >>> +1

> = >>>

> = >>> -----Original = Message-----

> = >>> Of DOLLY, MARTIN C

> = >>> Sent: Monday, September 30, 2013 12:58 = PM

> = >>> To: Robert Sparks

> = >>> Cc: stir@ietf.org<= /span>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>

> = >>> Yes, ok

> = >>>

> = >>> Martin Dolly

> = >>> Lead Member of Technical = Staff

> = >>> Core Network & Gov't/Regulatory Standards AT&T Labs = - Network

> = >>> Technology

> = >>> +1-609-903-3360

> = >>> md3135@att.com=

> = >>>

> = >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"

> = >>> wrote:

> = >>>>

> = >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C = wrote:

> = >>>>> With Hadriel comments incorporated, it is a = start

> = >>>> Hi Martin -

> = >>>>

> = >>>> Just to make sure - I think you're referring to = Hadriel's comments

> = >>>> on the

> = >>> problem statement = document?

> = >>>> I don't think Hadriel's commented directly on = stir-threats yet.

> = >>>>

> = >>>> In any case, we _are_ talking about a starting place, = not a

> = >>>> finished

> = >>> product.

> = >>>>

> = >>>> If there's no other objection, I'd like to get Jon to = submit the

> = >>>> threats

> = >>> document as a WG -00 as soon as it's = convenient.

> = >>>>

> = >>>> RjS

> = >>>>>

> = >>>>> -----Original = Message-----

> = >>>>> Behalf Of Russ = Housley

> = >>>>> Sent: Thursday, September 26, 2013 4:37 = PM

> = >>>>> To: IETF STIR Mail = List

> = >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>>>

> = >>>>> It has been six days, I'd like to hear from more = people about this

> = >>> document.  Martin asked for an additional week, so I'm = sure we will

> = >>> hear from him soon.

> = >>>>>

> = >>>>> Russ

> = >>>>>

> = >>>>>

> = >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley = wrote:

> = >>>>>>

> = >>>>>>

> = >>>>>> Should the working group adopt this I-D as the = starting point for

> = >>>>>> the

> = >>> STIR threat docuent?

> = >>>>>>

> = >>>>>> Russ

> = >>>>> = _______________________________________________

> = >>>>> stir mailing = list

> = >>>>> stir@ietf.org<= /span>

> = >>>>

> = >>>> = _______________________________________________

> = >>>> stir mailing list

> = >>>> stir@ietf.org<= /span>

> = >>> = _______________________________________________

> = >>> stir mailing list

> = >>> stir@ietf.org<= /span>

> = >>>

> = >>> = _______________________________________________

> = >>> stir mailing list

> = >>> stir@ietf.org<= /span>

> = >> = _______________________________________________

> = >> stir mailing list

> = >> stir@ietf.org<= /span>

> = >

> > = _______________________________________________

> > = stir mailing list

> = > stir@ietf.org<= /span>

> <= /span>

> = _______________________________________________

> stir = mailing list

> stir@ietf.org<= /span>

=

 

This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/= mailman/listinfo/stir

 

 

------=_NextPart_000_00F5_01CEDBA2.61B77140-- From michael.hammer@yaanatech.com Thu Nov 7 07:28:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654D711E8102; Thu, 7 Nov 2013 07:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETYR+X7c2T53; Thu, 7 Nov 2013 07:28:31 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id F223C21F85EC; Thu, 7 Nov 2013 07:28:29 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 7 Nov 2013 07:28:29 -0800 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "Pierce.Gorman@sprint.com" , "br@brianrosen.net" , "richard@shockey.us" Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQIJuyR31NLy1lMhJkGcqWArv1sc1QINOqbRAr/2giEC0l///wF434JzmR/4cmCAAD+vQIABiMQAgAABSwCAABcWAIA3YVcAgAAInoCAAAXVgIAA6nqAgAB5wgCAAAhegIAAk5aAgACVVgCAAAHaAP//gKww Date: Thu, 7 Nov 2013 15:28:28 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEF7D86@sc9-ex2k10mb1.corp.yaanatech.com> References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.142] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005D_01CEDBA4.18350350" MIME-Version: 1.0 Cc: "stir@ietf.org" , "cnit@ietf.org" , "fmousinh@cisco.com" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:28:41 -0000 ------=_NextPart_000_005D_01CEDBA4.18350350 Content-Type: multipart/alternative; boundary="----=_NextPart_001_005E_01CEDBA4.18350350" ------=_NextPart_001_005E_01CEDBA4.18350350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So, would you trust a certificate from the City of Reston, Virginia police department? (Hint: you can find Reston on a map, but there is no City of Reston. The only police are Fairfax County.) My concern is that one you dilute or disperse authority, it becomes a free-for-all again, and anybody's guess. Mike From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, November 07, 2013 10:00 AM To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey Cc: stir@ietf.org List; Fernando Mousinho (fmousinh); cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt As a thought experiment, Kumiko Ono and I had published a draft http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 to allow third parties to validate property information. If the validating party (e.g., a bank regulator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist's office or, more lowly, to the health departments rating in a restaurant window, and it can be tied to a phone number, this shouldn't be too hard. It's a bit harder if the certifying authority (regulator, Realtor board, local bar association, .) is not involved. Henning From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gorman, Pierce A [NTK] Sent: Thursday, November 07, 2013 9:54 AM To: Brian Rosen; Richard Shockey Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I'll admit I am not familiar with v/x/jcard encoding differences or the implications of their use so I'll encourage educating me if it isn't too onerous. I'm not sure what is the concern with a 3rd party providing "validation" though. There are numerous examples of 3rd parties providing validation of information including NASDAQ, NYSE, Barron's, Moody's, and the federal reserve banking system to name a few. Pierce From: Brian Rosen [mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the data, which it has very little basis to validate. It could get a 3rd party to do the validation, but then it's putting its reputation on the back of some hired hand validator. If the responsibility is the end user/device, then the signature has no value. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party and ultimately signed by the responsible entity. The carrier could provision this for their mobile or hosted customers. Enterprises could do this themselves. This also has advantages in Enterprise to Enterprise UC as well where the data is derived from the Enterprise "directory" and could facilitate end to end PPX to PBX communications especially in point to point video communications. There are certainly privacy and security issues to be addressed. The Push vs Pull model. This really would be PII in the clear but then its done voluntarily. There would have to be some work around restructuring the Header and adding some parameters but it's underutilized right now and this Use Case is a perfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: ;purpose=icon, ;purpose=info From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name, but is something like "bank", which might have some sort of validation behind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey wrote: I agree with Pierce here and respectfully disagree that STIR might eliminate the need for other forms of caller identification. Though your use case of credit card validation is a useful one and you are right there are still applications that use SS7 for things that have nothing to do with call setup. I agree with you STIR may have more applications beyond the obvious ones of realtime session validation. It's been my experience recently that there is a use case for something MORE in the identification of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identify themselves to the consumer before establishing a conversation is exactly what this process is about. STIR is essential but it's a multi-faceted problem that may require multi-faceted solutions.. and enhanced CNAM + being only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a utility worker before I let them into my house to make repairs. I would want some validation that the call to me to reconfirm the appointments was in fact from the utility in question. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it. it may eliminate the need for other forms of caller identification beyond what STIR will provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to be unblocked by an IVR (and as I said earlier, many companies do it today). In other use cases, the TN alone is not sufficient information - my health care provider will want to know which member of the family is calling. I agree that ANI is already broadly used to improve customer service today. However, it is not usually deemed as a secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things like SS7. STIR would make this type of validation available to a broader number of companies. Going on a tangent. perhaps this is out of scope, but there is not a lot of discussion about called party hijacking. Couldn't a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it's really them before carrying a conversation, but wouldn't they want the same? From: , "Pierce A [NTK]" < Pierce.Gorman@sprint.com> Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho < fmousinh@cisco.com>, " stir@ietf.org" < stir@ietf.org> Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fraud however contact centers also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the call center. So I don't agree that STIR would "eliminate the need for caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [ mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more companies are using the caller ID for account validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my home phone number, I'm informed that I don't need to provide any further identification because my number is on file. Some (all?) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this case, the "victim" is a business, unlike the other two scenarios we've listed so far. Addressing this scenario would actually turn STIR into a feature, given it would enable contact centers of all sizes to eliminate the need for caller identification from known TNs. From: Alex Bobotek < alex@bobotek.net> Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen < br@brianrosen.net>, "Peterson, Jon" < jon.peterson@neustar.biz> Cc: " stir@ietf.org" < stir@ietf.org>, Richard Shockey < richard@shockey.us>, "'DOLLY, MARTIN C'" < md3135@att.com>, 'Robert Sparks' < rjsparks@nostrum.com> Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the following sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is simply the rendering of a spoofed number on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information. No issues with leaving this as it's a valid point. Another (increasing) motivation is to evade network and/or endpoint defenses that may block based on CPN. So however it's worded, I think it's important to allow for both attack objectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" < jon.peterson@neustar.biz> > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draft: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> < rjsparks@nostrum.com> > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. ------=_NextPart_001_005E_01CEDBA4.18350350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So, would you trust a certificate from the City of Reston, Virginia = police department?

 

(Hint:  you can find Reston on a map, but there is no City of = Reston. 

  The only police are Fairfax = County.)

 

My concern is that one you dilute or disperse authority, it becomes a = free-for-all again, and anybody’s guess.

 

Mike

 

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Henning Schulzrinne
Sent: Thursday, November 07, 2013 = 10:00 AM
To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard = Shockey
Cc: stir@ietf.org List; Fernando Mousinho (fmousinh); = cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

As a thought experiment, Kumiko Ono and I had published a draft =

 

http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-= 00

 

to allow third parties to validate property information. If the = validating party (e.g., a bank regulator) is willing to sign a = certificate, similar in spirit to the framed gold-leaf diplomas in your = dentist’s office or, more lowly, to the health departments rating = in a restaurant window, and it can be tied to a phone number, this = shouldn’t be too hard.

 

It’s a bit harder if the certifying authority (regulator, = Realtor board, local bar association, …) is not = involved.

 

Henning

 

From:= = cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.= org] On Behalf Of Gorman, Pierce A [NTK]
Sent: = Thursday, November 07, 2013 9:54 AM
To: Brian Rosen; Richard = Shockey
Cc: stir@ietf.org = List; cnit@ietf.org; Fernando = Mousinho (fmousinh)
Subject: Re: [cnit] [stir] = draft-peterson-stir-threats-00.txt

 

I’ll admit I am not familiar with v/x/jcard encoding differences = or the implications of their use so I’ll encourage educating me if = it isn’t too onerous.

 

I’m not sure what is the concern with a 3rd party = providing “validation” though.  There are numerous = examples of 3rd parties providing validation of information = including NASDAQ, NYSE, Barron’s, Moody’s, and the federal = reserve banking system to name a few.

 

P= ierce

 

From:= = Brian Rosen [mailto:br@brianrosen.net] =
Sent: November 06, 2013 11:59 PM
To: Richard = Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A = [NTK]; stir@ietf.org List; cnit@ietf.org
Subject: Re: = [stir] = draft-peterson-stir-threats-00.txt

 

I think this = would be a heavy lift.

 

If the responsible entity was a carrier, then it would = have to validate the data, which it has very little basis to validate. =  It could get a 3rd party to do the validation, but then it’s = putting its reputation on the back of some hired hand = validator.

 

If the responsibility is the end user/device, then the = signature has no value.

 

I = do not argue that Call-Info is suitable,  it = is.

 

I = do question JCARD vs xCard, but that’s an encoding detail. =  All of SIP Is XML described by schema, not = json.

 

Brian

 

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> = wrote:

 

URI for a JCARD in the CALL INFO header provisioned by the calling = party and ultimately signed by the responsible entity.  The carrier = could provision this for their mobile or hosted customers.  = Enterprises could do this themselves.  This also has advantages in = Enterprise to Enterprise UC as well where the data is derived from the = Enterprise “directory” and could facilitate end to end PPX = to PBX communications especially in point to point video communications. =

 

There are certainly privacy and security issues to be = addressed.  The Push vs Pull model.  This really would be PII = in the clear but then its done voluntarily.

 

There would have to be some work around restructuring the Header and = adding some parameters but it’s underutilized right now and this = Use Case is a perfectly appropriate use.

 

https:/= /tools.ietf.org/html/draft-ietf-jcardcal-jcard-06

 

Obviously it would need to be signed but we don’t need to worry = about that ..yet.

 

From 3261

 

20.9 Call-Info

 

   The Call-Info header field provides additional = information about the

   caller or callee, depending on whether it is found in a = request or

   response.  The purpose of the URI is described by = the "purpose"

   parameter.  The "icon" parameter = designates an image suitable as an

   iconic representation of the caller or callee.  The = "info" parameter

   describes the caller or callee in general, for example, = through a web

   page.  The "card" parameter provides a = business card, for example, in

   vCard [36] or LDIF [37] formats.  Additional tokens = can be registered

   using IANA and the procedures in Section = 27.

 

   Use of the Call-Info header field can pose a security = risk.  If a

   callee fetches the URIs provided by a malicious caller, = the callee

   may be at risk for displaying inappropriate or offensive = content,

   dangerous or illegal content, and so on.  = Therefore, it is

   RECOMMENDED that a UA only render the information in the = Call-Info

   header field if it can verify the authenticity of the = element that

   originated the header field and trusts that = element.  This need not

   be the peer UA; a proxy can insert this header field = into requests.

 

   Example:

 

   Call-Info: <http://wwww.example.com/= alice/photo.jpg> ;purpose=3Dicon,

     <http://www.example.com/alice/&= gt; ;purpose=3Dinfo

 

From: Brian = Rosen [mailto:br@brianrosen.net] =
Sent: Wednesday, November 06, 2013 3:41 PM
To: = Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, = Pierce A [NTK]; stir@ietf.org = List
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

We’ve = considered adding some information that is not number and is not name, = but is something like “bank”, which might have some sort of = validation behind it.

 

Is that along the lines you were = thinking?

 

Brian

On = Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:

 

I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification.  = Though your use case of credit card validation is a useful one and you = are right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session = validation.

 

It’s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list.

 

_______________________________________________

<= /div>

cnit mailing list

cnit@ietf.org

 

But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about.  STIR is essential but = it’s a multi-faceted problem that may require multi-faceted = solutions.. and enhanced CNAM + being only one of them.   Its = not unreasonable to discuss those.

 

The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. =  I would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in = question.

 

 

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

 

Let me = rephrase it… it may eliminate the need for other forms of caller = identification beyond what STIR will provide, depending on the specific = use case. For example, a credit card company may choose to rely entirely = on STIR before allowing a card to be unblocked by an IVR (and as I said = earlier, many companies do it today). In other use cases, the TN alone = is not sufficient information – my health care provider will want = to know which member of the family is = calling.

 

I agree = that ANI is already broadly used to improve customer service today. = However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of = companies.

 

 

Going on a = tangent… perhaps this is out of scope, but there is not a lot of = discussion about called party hijacking. Couldn’t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it’s really them before carrying a = conversation, but wouldn’t they want the = same? 

 

 

From: <Gorman&= gt;, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Dat= e: Tuesday, November = 5, 2013 at 6:05 PM
To: Fernando Mousinho <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt

 

I agree with your characterization of businesses as victim of caller ID = fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center.  So I don’t agree that = STIR would “eliminate the need for caller identification from = known TNs.”

 

But perhaps I misunderstood your last = sentence?

 

 

From:=  Fernando = Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

 

I would = suggest we add a new attack type to section 3. More and more companies = are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I’m informed = that I don’t need to provide any further identification because my = number is on file. Some (all?) companies that implement this type of = validation rely on SS7 today.

 

Ultimately,= this is yet another variation of impersonation – but in this = case, the “victim” is a business, unlike the other two = scenarios we’ve listed so far.

 

Addressing = this scenario would actually turn STIR into a feature, given it would = enable contact centers of all sizes to eliminate the need for caller = identification from known TNs.

 

 

 

From: Alex = Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, 2013 = at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, = "Peterson, Jon" <jon.peterson@neustar.biz>
Cc:=  "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, = MARTIN C'" <md3135@att.com>, 'Robert Sparks' = <rjsparks@nostrum.com>
Subject= : Re: [stir] = draft-peterson-stir-threats-00.txt

 

Jon,=

 

Thanks for = the response.  The intention in #1 below is to clarify the = following sentence:

 

The primary attack vector = is

  = ; therefore one where the attacker contrives for the calling = telephone

  = ; number in signaling to be a particular chosen number, one that = the

  = ; attacker does not have the authority to call from, in order for = that

  = ; number to be rendered on the terminating side. 

 

This might = be misconstrued as indicating that the objective of spoofing is simply = the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the = rendered information.  No issues with leaving this as it’s a = valid point.  Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on = CPN. 

 

So however = it’s worded, I think it’s important to allow for both attack = objectives of a spoofed presentation at the endpoint and in = transit.   

 

Regards,

 

Alex=

 

> = -----Original Message-----

> Brian = Rosen

> Sent: = Tuesday, October 01, 2013 9:29 AM

> To: = Peterson, Jon

> = Cc: stir@ietf.org; Alex Bobotek; 'Robert = Sparks'; 'DOLLY, MARTIN C'; Richard

> = Shockey

> = Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> <= /span>

> Don't = think there is much MESSAGE.  MSRP is about all we see, and XMPP = is

> more = likely than that.

> <= /span>

> = Brian

> <= /span>

> On = Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <jon.peterson@neustar.biz<= /span>>

> = wrote:

> <= /span>

> > = Thanks for these notes, Alex. Some responses = below.

> = >

> = >> Here are several comments that should feed into the IETF = Peterson draft:

> = >>

> = >> *   Remove any assumptions that the solution cannot = be in-network

> = [IMO,

> = >> both endpoint and in-network solutions should be = facilitated]

> = >

> > = Agreed that both in-band and out-of-band solutions can usually = be

> > = implemented in either endpoints or in intermediaries of various = kinds.

> > = If I see text that implies otherwise, I'll certainly change = it.

> = >

> = >> *   Add a sessionless attack scenario.  A spam = payload may be carried in

> = a

> = >> SIP INVITE or MESSAGE, which might contain stock market advice = even

> = >> in a display name field.  These attacks do NOT require = session

> = establishment.

> = >> More generally, we should be mindful of the fact that SIP is = used in

> = >> telephony form more than voice session = setup.

> = >

> > = Probably if we were going to include a sessionless attack scenario, = it

> > = would be with regular text messages (whether carried on the PSTN = over

> > = TCAP or with some Internet protocol, including MESSAGE) rather = than

> > = with an INVITE, which typically wouldn't result in a payload = being

> > = immediately rendered to a user. More on this below with your = suggested

> = text.

> = >

> = >> Here's some suggested = markup:

> = >>

> = >>

> = >> 1.    Replace 2nd sentence of 2nd paragraph of = 1.0 Introduction with:

> = >>

> = >> The primary attack vector is

> = >>  therefore one where the attacker contrives for the = calling telephone

> = >> number in signaling to be a particular chosen number that = the

> = >> attacker does not have the authority to call = from.

> = >

> > = What you want here is to remove the implication that the number = will

> > = be rendered on the terminating side? While there are some = attacks

> > = where that isn't significant, perhaps, I would say it is = significant

> > = in the primary attack vectors that concern = us.

> = >

> = >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:

> = >>

> = >>     Smart devices are generally based on = computers with some degree

> = >> of programmability, the capacity to access the Internet, = and

> = >> capabilities of rendering text, audio and/or images.  This = includes

> = >> smart phones, telephone applications on desktop and laptop = computers,

> = >> IP private branch exchanges, and so = on.

> = >

> > = I can add the notion that smart devices can render text, audio = and/or

> > = images as you suggest.

> = >

> = >> 3.  Add to 3.3 Attack = Scenarios:

> = >>

> = >>       Impersonation, IP-Mobile Text = Message

> = >>

> = >>        An attacker with an = computer sends a high volume of SIP = MESSAGE

> = >> spam message to IP-enabled smart phones using randomized = calling

> = >> party numbers.

> = >>

> = >>       Countermeasure: in-band = authenticated identity

> = >

> > = Provided we're talking about end-to-end SIP use of MESSAGE, = agreed

> > = that in-band would be the right countermeasure. I am curious = though

> > = whether practically speaking there is enough use of MESSAGE in = this

> > = fashion that we're actually seeing high-volume spam over = MESSAGE

> > = today. Either way, no problem having an attack scenario of this form in = the

> = document.

> = >

> > = Jon Peterson

> > = Neustar, Inc.

> = >

> = >> Regards,

> = >>

> = >> Alex

> = >>

> = >>> -----Original = Message-----

> = >>> Of Richard Shockey

> = >>> Sent: Monday, September 30, 2013 1:11 = PM

> = >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'

> = >>> Cc: stir@ietf.org<= /span>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>

> = >>> +1

> = >>>

> = >>> -----Original = Message-----

> = >>> Of DOLLY, MARTIN C

> = >>> Sent: Monday, September 30, 2013 12:58 = PM

> = >>> To: Robert Sparks

> = >>> Cc: stir@ietf.org<= /span>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>

> = >>> Yes, ok

> = >>>

> = >>> Martin Dolly

> = >>> Lead Member of Technical = Staff

> = >>> Core Network & Gov't/Regulatory Standards AT&T Labs = - Network

> = >>> Technology

> = >>> +1-609-903-3360

> = >>> md3135@att.com=

> = >>>

> = >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"

> = >>> wrote:

> = >>>>

> = >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C = wrote:

> = >>>>> With Hadriel comments incorporated, it is a = start

> = >>>> Hi Martin -

> = >>>>

> = >>>> Just to make sure - I think you're referring to = Hadriel's comments

> = >>>> on the

> = >>> problem statement = document?

> = >>>> I don't think Hadriel's commented directly on = stir-threats yet.

> = >>>>

> = >>>> In any case, we _are_ talking about a starting place, = not a

> = >>>> finished

> = >>> product.

> = >>>>

> = >>>> If there's no other objection, I'd like to get Jon to = submit the

> = >>>> threats

> = >>> document as a WG -00 as soon as it's = convenient.

> = >>>>

> = >>>> RjS

> = >>>>>

> = >>>>> -----Original = Message-----

> = >>>>> Behalf Of Russ = Housley

> = >>>>> Sent: Thursday, September 26, 2013 4:37 = PM

> = >>>>> To: IETF STIR Mail = List

> = >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

> = >>>>>

> = >>>>> It has been six days, I'd like to hear from more = people about this

> = >>> document.  Martin asked for an additional week, so I'm = sure we will

> = >>> hear from him soon.

> = >>>>>

> = >>>>> Russ

> = >>>>>

> = >>>>>

> = >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley = wrote:

> = >>>>>>

> = >>>>>>

> = >>>>>> Should the working group adopt this I-D as the = starting point for

> = >>>>>> the

> = >>> STIR threat docuent?

> = >>>>>>

> = >>>>>> Russ

> = >>>>> = _______________________________________________

> = >>>>> stir mailing = list

> = >>>>> stir@ietf.org<= /span>

> = >>>>

> = >>>> = _______________________________________________

> = >>>> stir mailing list

> = >>>> stir@ietf.org<= /span>

> = >>> = _______________________________________________

> = >>> stir mailing list

> = >>> stir@ietf.org<= /span>

> = >>>

> = >>> = _______________________________________________

> = >>> stir mailing list

> = >>> stir@ietf.org<= /span>

> = >> = _______________________________________________

> = >> stir mailing list

> = >> stir@ietf.org<= /span>

> = >

> > = _______________________________________________

> > = stir mailing list

> = > stir@ietf.org<= /span>

> <= /span>

> = _______________________________________________

> stir = mailing list

> stir@ietf.org<= /span>

=

 

This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/= mailman/listinfo/stir

 

 

 

This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

------=_NextPart_001_005E_01CEDBA4.18350350-- ------=_NextPart_000_005D_01CEDBA4.18350350 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEw NzE1MjgyNlowIwYJKoZIhvcNAQkEMRYEFKT/8WFR/+6OQtOJsmBs2PDwFq8eMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEALOpe1qIe0vPORyuhSRDUeA3fwMGp4DyoQCCUqo7H nwoz6CF7PJhSE9P8wAKpouA7WjN540583+xbdtryXQyJBksX5K1DZKraRYvRg2+BGHEVzXD+M5h5 6o1hEbE5kCB6Y45Ejd1pRWuQuX5iiRy8R2YKMh+rqM584tsP2WH9HhhUGkSueTXH3DJDiSuL7fMW UVD50PxrMc1zHUvtddwY5ghlAISesH3uPO8gOnqwXjDFAPzlCcgAygS3pAYwGxPJ5zqARQ298k5k S07r6oZ71HY/IzreNp9GjBZDYVAEhRuOvigCWlk+T7BZ5ueNGLVB1Y7xA4ayRuVgXK0/YhXcHAAA AAAAAA== ------=_NextPart_000_005D_01CEDBA4.18350350-- From Henning.Schulzrinne@fcc.gov Thu Nov 7 08:13:04 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4973421E8149; Thu, 7 Nov 2013 08:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUEpi18hgPfK; Thu, 7 Nov 2013 08:12:53 -0800 (PST) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD1A21E80DF; Thu, 7 Nov 2013 08:12:51 -0800 (PST) Message-ID: From: Henning Schulzrinne To: 'Michael Hammer' , "Pierce.Gorman@sprint.com" , "br@brianrosen.net" , "richard@shockey.us" Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQHO28lBm7MQs/E/Y0C8yrTGiGFz45oZ21rggABc6AD//7YS0A== Date: Thu, 7 Nov 2013 16:12:50 +0000 References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7D86@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEF7D86@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FC238EEp2pxmb13fccnetw_" MIME-Version: 1.0 Cc: "stir@ietf.org" , "cnit@ietf.org" , "fmousinh@cisco.com" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:13:05 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FC238EEp2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, that's a problem, but as long as the number of categories is small, yo= u can build UIs that only render information that's appropriate to the decl= aration. For practical reasons, I think the number of useful categories is = likely going to be fairly limited: - Financial institution (FDIC and a few others) - Health care (each health care facility has a gov't number) - Charity (501c3, state registered) - Contractor (state-licensed) - Public safety organization (police, fire) - Lawyer (bar association) - Local, state and federal government (.gov in the US) I suspect that list encompasses a large fraction of the fraudulent (imperso= nation) calls. For all of the above, at least within a country, it's pretty= clear who can attest to the membership. Yes, this requires some UI work or= some server logic, but these categories and the organizations don't change= all that often - in most cases, the certifying entities have probably been= the same for the past 50+ years. I'm not as worried about figuring out whe= ther the beautician, mortician or florist is licensed and properly identifi= ed, although I'm sure we can all come up with potential fraud stories. From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 10:28 AM To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; richa= rd@shockey.us Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, would you trust a certificate from the City of Reston, Virginia police = department? (Hint: you can find Reston on a map, but there is no City of Reston. The only police are Fairfax County.) My concern is that one you dilute or disperse authority, it becomes a free-= for-all again, and anybody's guess. Mike From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, November 07, 2013 10:00 AM To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey Cc: stir@ietf.org List; Fernando Mousinho (fmousinh);= cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt As a thought experiment, Kumiko Ono and I had published a draft http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 to allow third parties to validate property information. If the validating = party (e.g., a bank regulator) is willing to sign a certificate, similar in= spirit to the framed gold-leaf diplomas in your dentist's office or, more = lowly, to the health departments rating in a restaurant window, and it can = be tied to a phone number, this shouldn't be too hard. It's a bit harder if the certifying authority (regulator, Realtor board, lo= cal bar association, ...) is not involved. Henning From: cnit-bounces@ietf.org [mailto:cnit-boun= ces@ietf.org] On Behalf Of Gorman, P= ierce A [NTK] Sent: Thursday, November 07, 2013 9:54 AM To: Brian Rosen; Richard Shockey Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I'll admit I am not familiar with v/x/jcard encoding differences or the imp= lications of their use so I'll encourage educating me if it isn't too onero= us. I'm not sure what is the concern with a 3rd party providing "validation" th= ough. There are numerous examples of 3rd parties providing validation of i= nformation including NASDAQ, NYSE, Barron's, Moody's, and the federal reser= ve banking system to name a few. Pierce From: Brian Rosen [mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the= data, which it has very little basis to validate. It could get a 3rd part= y to do the validation, but then it's putting its reputation on the back of= some hired hand validator. If the responsibility is the end user/device, then the signature has no val= ue. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is= XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey > wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party an= d ultimately signed by the responsible entity. The carrier could provision= this for their mobile or hosted customers. Enterprises could do this them= selves. This also has advantages in Enterprise to Enterprise UC as well wh= ere the data is derived from the Enterprise "directory" and could facilitat= e end to end PPX to PBX communications especially in point to point video c= ommunications. There are certainly privacy and security issues to be addressed. The Push = vs Pull model. This really would be PII in the clear but then its done vol= untarily. There would have to be some work around restructuring the Header and adding= some parameters but it's underutilized right now and this Use Case is a pe= rfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that = ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: ;purpose=3Dicon, ;purpose=3Dinfo From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name= , but is something like "bank", which might have some sort of validation be= hind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey > wrote: I agree with Pierce here and respectfully disagree that STIR might eliminat= e the need for other forms of caller identification. Though your use case = of credit card validation is a useful one and you are right there are still= applications that use SS7 for things that have nothing to do with call set= up. I agree with you STIR may have more applications beyond the obvious one= s of realtime session validation. It's been my experience recently that there is a use case for something MOR= E in the identification of the session as it is presented to the called par= ty. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identi= fy themselves to the consumer before establishing a conversation is exactly= what this process is about. STIR is essential but it's a multi-faceted pr= oblem that may require multi-faceted solutions.. and enhanced CNAM + being = only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a = utility worker before I let them into my house to make repairs. I would wa= nt some validation that the call to me to reconfirm the appointments was in= fact from the utility in question. From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it... it may eliminate the need for other forms of caller i= dentification beyond what STIR will provide, depending on the specific use = case. For example, a credit card company may choose to rely entirely on STI= R before allowing a card to be unblocked by an IVR (and as I said earlier, = many companies do it today). In other use cases, the TN alone is not suffic= ient information - my health care provider will want to know which member o= f the family is calling. I agree that ANI is already broadly used to improve customer service today.= However, it is not usually deemed as a secure enough mechanism to validate= the caller (therefore this WG!), except if you are a large organization th= at can leverage things like SS7. STIR would make this type of validation av= ailable to a broader number of companies. Going on a tangent... perhaps this is out of scope, but there is not a lot = of discussion about called party hijacking. Couldn't a man-in-the-middle tr= y to answer calls on my behalf? If my bank is calling me, I want to make su= re it's really them before carrying a conversation, but wouldn't they want = the same? From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho >, "sti= r@ietf.org" > Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fra= ud however contact centers also use TN as a key to improve information avai= lable to call agents to reduce average time-per-call and increase capacity = of the call center. So I don't agree that STIR would "eliminate the need f= or caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more compan= ies are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for identificati= on. If I call from my home phone number, I'm informed that I don't need to = provide any further identification because my number is on file. Some (all?= ) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this ca= se, the "victim" is a business, unlike the other two scenarios we've listed= so far. Addressing this scenario would actually turn STIR into a feature, given it = would enable contact centers of all sizes to eliminate the need for caller = identification from known TNs. From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen >, "Peterson, J= on" > Cc: "stir@ietf.org" >, Richard Shockey >, "'DO= LLY, MARTIN C'" >, 'Robert Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the follo= wing sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is = simply the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the rendere= d information. No issues with leaving this as it's a valid point. Another= (increasing) motivation is to evade network and/or endpoint defenses that = may block based on CPN. So however it's worded, I think it's important to allow for both attack obj= ectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bo= unces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; '= DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" > > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draf= t: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried = in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in= the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> > > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [mailto:s= tir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_E6A16181E5FD2F46B962315BB05962D01FC238EEp2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, that’s a probl= em, but as long as the number of categories is small, you can build UIs tha= t only render information that’s appropriate to the declaration. For practical reasons, I think the number of useful categories is likely g= oing to be fairly limited:

- =          Financial institu= tion (FDIC and a few others)

- =          Health care (each= health care facility has a gov’t number)

- =          Charity (501c3, s= tate registered)

- =          Contractor (state= -licensed)

- =          Public safety org= anization (police, fire)

- =          Lawyer (bar assoc= iation)

- =          Local, state and = federal government (.gov in the US)

 <= /p>

I suspect that list encom= passes a large fraction of the fraudulent (impersonation) calls. For all of= the above, at least within a country, it’s pretty clear who can attest to the membership. Yes, this requires some UI work or some = server logic, but these categories and the organizations don’t change= all that often – in most cases, the certifying entities have probabl= y been the same for the past 50+ years. I’m not as worried about figuring out whether the beautician, mortician or flo= rist is licensed and properly identified, although I’m sure we can al= l come up with potential fraud stories.

 <= /p>

From: Michael = Hammer [mailto:michael.hammer@yaanatech.com]
Sent: Thursday, November 07, 2013 10:28 AM
To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net= ; richard@shockey.us
Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

 

So, would you trust a cer= tificate from the City of Reston, Virginia police department?

 <= /p>

(Hint:  you can find= Reston on a map, but there is no City of Reston. 

  The only poli= ce are Fairfax County.)

 <= /p>

My concern is that one yo= u dilute or disperse authority, it becomes a free-for-all again, and anybod= y’s guess.

 <= /p>

Mike

 <= /p>

 <= /p>

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Thursday, November 07, 2013 10:00 AM
To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey
Cc: stir@ietf.org List; Fernand= o Mousinho (fmousinh); cnit@ietf.org
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

As a thought experiment, = Kumiko Ono and I had published a draft

 <= /p>

http://tools.ietf.= org/html/draft-ono-dispatch-attribute-validation-00

 <= /p>

to allow third parties to= validate property information. If the validating party (e.g., a bank regul= ator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist’s office or, more l= owly, to the health departments rating in a restaurant window, and it can b= e tied to a phone number, this shouldn’t be too hard.

 <= /p>

It’s a bit harder i= f the certifying authority (regulator, Realtor board, local bar association= , …) is not involved.

 <= /p>

Henning

 <= /p>

From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gorman, Pierce A [NT= K]
Sent: Thursday, November 07, 2013 9:54 AM
To: Brian Rosen; Richard Shockey
Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh)
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

 

I’ll admit I am not f= amiliar with v/x/jcard encoding differences or the implications of their us= e so I’ll encourage educating me if it isn’t too onerous.

 

I’m not sure what is = the concern with a 3rd party providing “validation” = though.  There are numerous examples of 3rd parties providi= ng validation of information including NASDAQ, NYSE, Barron’s, Moody’s, and = the federal reserve banking system to name a few.

 

Pierce

 

From: Brian Ro= sen [mailto:br@brianrosen.net]
Sent: November 06, 2013 11:59 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org<= br> Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

I think this would be a heavy lift.

 

If the responsible entity was a carrier, then it wou= ld have to validate the data, which it has very little basis to validate. &= nbsp;It could get a 3rd party to do the validation, but then it’s put= ting its reputation on the back of some hired hand validator.

 

If the responsibility is the end user/device, then t= he signature has no value.

 

I do not argue that Call-Info is suitable,  it = is.

 

I do question JCARD vs xCard, but that’s an en= coding detail.  All of SIP Is XML described by schema, not json.<= /o:p>

 

Brian

 

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> wrote:

 

URI for a JCARD in the CA= LL INFO header provisioned by the calling party and ultimately signed by th= e responsible entity.  The carrier could provision this for their mobile or hosted customers.  Enterprises could do this them= selves.  This also has advantages in Enterprise to Enterprise UC as we= ll where the data is derived from the Enterprise “directory” an= d could facilitate end to end PPX to PBX communications especially in point to point video communications.

 <= /p>

There are certainly priva= cy and security issues to be addressed.  The Push vs Pull model. = This really would be PII in the clear but then its done voluntarily.

 <= /p>

There would have to be so= me work around restructuring the Header and adding some parameters but it&#= 8217;s underutilized right now and this Use Case is a perfectly appropriate use.

 <= /p>

https://tools.ietf.org/html/dra= ft-ietf-jcardcal-jcard-06

 <= /p>

Obviously it would need t= o be signed but we don’t need to worry about that ..yet.

 <= /p>

From 3261

 <= /p>

20.9 Call-Info

 <= /p>

   The Call-Inf= o header field provides additional information about the<= /p>

   caller or ca= llee, depending on whether it is found in a request or

   response.&nb= sp; The purpose of the URI is described by the "purpose"

   parameter.&n= bsp; The "icon" parameter designates an image suitable as an

   iconic repre= sentation of the caller or callee.  The "info" parameter

   describes th= e caller or callee in general, for example, through a web=

   page.  = The "card" parameter provides a business card, for example, in

   vCard [36] o= r LDIF [37] formats.  Additional tokens can be registered<= /o:p>

   using IANA a= nd the procedures in Section 27.

 <= /p>

   Use of the C= all-Info header field can pose a security risk.  If a

   callee fetch= es the URIs provided by a malicious caller, the callee

   may be at ri= sk for displaying inappropriate or offensive content,

   dangerous or= illegal content, and so on.  Therefore, it is

   RECOMMENDED = that a UA only render the information in the Call-Info

   header field= if it can verify the authenticity of the element that

   originated t= he header field and trusts that element.  This need not

   be the peer = UA; a proxy can insert this header field into requests.

 <= /p>

   Example:

 <= /p>

   Call-Info: &= lt;http://wwww.example.= com/alice/photo.jpg> ;purpose=3Dicon,

     = <http://www.example.com/alice/= > ;purpose=3Dinfo

 <= /p>

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, November 06, 2013 3:41 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

We’ve considered adding some information that = is not number and is not name, but is something like “bank”, wh= ich might have some sort of validation behind it.

 

Is that along the lines you were thinking?

 

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> wrote:

 

I agree with Pierce here = and respectfully disagree that STIR might eliminate the need for other form= s of caller identification.  Though your use case of credit card validation is a useful one and you are right there are still applicat= ions that use SS7 for things that have nothing to do with call setup. I agr= ee with you STIR may have more applications beyond the obvious ones of real= time session validation.

 <= /p>

It’s been my experi= ence recently that there is a use case for something MORE in the identifica= tion of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list.=

 <= /p>

_________________________= ______________________

cnit mailing list<= o:p>

cnit@ietf.org<= /o:p>

 <= /p>

But your use case of a ba= nk wanting to make sure they could properly identify themselves to the cons= umer before establishing a conversation is exactly what this process is about.  STIR is essential but it’s a multi-face= ted problem that may require multi-faceted solutions.. and enhanced CNAM &#= 43; being only one of them.   Its not unreasonable to discuss tho= se.

 <= /p>

The obviously analogy is = I would want to see some real identification of a utility worker before I l= et them into my house to make repairs.  I would want some validation that the call to me to reconfirm the appointments was in fact f= rom the utility in question.

 <= /p>

 <= /p>

 <= /p>

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org= ] On Behalf Of Fernando Mousinho (fmousinh)=
Sent: Tuesday, Nov= ember 05, 2013 6:26 PM
To: Gorman, Pierce= A [NTK]; stir@ietf.org
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

Let me rephrase it… it may elimin= ate the need for other forms of caller identification beyond what STIR will= provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to= be unblocked by an IVR (and as I said earlier, many companies do it today)= . In other use cases, the TN alone is not sufficient information – my= health care provider will want to know which member of the family is calling.

 

I agree that ANI is already broadly use= d to improve customer service today. However, it is not usually deemed as a= secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things= like SS7. STIR would make this type of validation available to a broader n= umber of companies.

 

 

Going on a tangent… perhaps this = is out of scope, but there is not a lot of discussion about called party hi= jacking. Couldn’t a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it’s really th= em before carrying a conversation, but wouldn’t they want the same?&n= bsp;

 

 

From: <Gorman>, "Pierce A = [NTK]" <Pierce.Gorman@sprint.com>
Date: Tuesday, Nov= ember 5, 2013 at 6:05 PM
To: Fernando Mousi= nho <fmousinh@cisco.com>, "= stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir= ] draft-peterson-stir-threats-00.txt

 

I agree with your character= ization of businesses as victim of caller ID fraud however contact centers = also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the c= all center.  So I don’t agree that STIR would “eliminate t= he need for caller identification from known TNs.”<= /p>

 

But perhaps I misunderstood= your last sentence?

 

 

From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05,= 2013 4:34 PM
To: stir@ietf.org Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

I would suggest we add a new attack typ= e to section 3. More and more companies are using the caller ID for account= validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my h= ome phone number, I’m informed that I don’t need to provide any= further identification because my number is on file. Some (all?) companies= that implement this type of validation rely on SS7 today.

 

Ultimately, this is yet another variati= on of impersonation – but in this case, the “victim” is a= business, unlike the other two scenarios we’ve listed so far.=

 

Addressing this scenario would actually= turn STIR into a feature, given it would enable contact centers of all siz= es to eliminate the need for caller identification from known TNs.

 

 

 

From: Alex Bobotek <alex@bobotek.net= >
Date: Tuesday, Oct= ober 1, 2013 at 12:51 PM
To: Brian Rosen &l= t;br@bri= anrosen.net>, "Peterson, Jon" <jon.peterson@neust= ar.biz>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey <richard@shockey.us>, "'DOLLY, MARTIN C'" <md3135@att.com>, 'Robert Sparks' <= rjspa= rks@nostrum.com>
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

Jon,

 

Thanks for the response.  The inte= ntion in #1 below is to clarify the following sentence:

 

The primary attack vector is

   therefore one where the at= tacker contrives for the calling telephone

   number in signaling to be = a particular chosen number, one that the

   attacker does not have the= authority to call from, = in order for that

   number to be rendered o= n the terminating side. 

 

This might be misconstrued as indicatin= g that the objective of spoofing is simply the rendering of a spoofed numbe= r on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information.  = ;No issues with leaving this as it’s a valid point.  Another (in= creasing) motivation is to evade network and/or endpoint defenses that may = block based on CPN. 

 

So however it’s worded, I think i= t’s important to allow for both attack objectives of a spoofed presen= tation at the endpoint and in transit.   

 

Regards,

 

Alex

 

> -----Original Message-----<= o:p>

> Brian Rosen

> Sent: Tuesday, October 01, 2013 9:= 29 AM

> To: Peterson, Jon

> Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard

> Shockey

> Subject: Re: [stir] draft-peterson= -stir-threats-00.txt

> 

> Don't think there is much MESSAGE.=   MSRP is about all we see, and XMPP is

> more likely than that.=

> 

> Brian

> 

> On Oct 1, 2013, at 12:24 PM, "= ;Peterson, Jon" <jon.peterson@neustar.biz>

> wrote:

> 

> > Thanks for these notes, Alex.= Some responses below.

> >

> >> Here are several comments= that should feed into the IETF Peterson draft:

> >>

> >> *   Remove any = assumptions that the solution cannot be in-network

> [IMO,

> >> both endpoint and in-netw= ork solutions should be facilitated]

> >

> > Agreed that both in-band and = out-of-band solutions can usually be

> > implemented in either endpoin= ts or in intermediaries of various kinds.

> > If I see text that implies ot= herwise, I'll certainly change it.

> >

> >> *   Add a sessi= onless attack scenario.  A spam payload may be carried in<= /o:p>

> a

> >> SIP INVITE or MESSAGE, wh= ich might contain stock market advice even

> >> in a display name field.&= nbsp; These attacks do NOT require session

> establishment.

> >> More generally, we should= be mindful of the fact that SIP is used in

> >> telephony form more than = voice session setup.

> >

> > Probably if we were going to = include a sessionless attack scenario, it

> > would be with regular text me= ssages (whether carried on the PSTN over

> > TCAP or with some Internet pr= otocol, including MESSAGE) rather than

> > with an INVITE, which typical= ly wouldn't result in a payload being

> > immediately rendered to a use= r. More on this below with your suggested

> text.

> >

> >> Here's some suggested mar= kup:

> >>

> >>

> >> 1.    Repl= ace 2nd sentence of 2nd paragraph of 1.0 Introduction with:

> >>

> >> The primary attack vector= is

> >>  therefore one where= the attacker contrives for the calling telephone

> >> number in signaling to be= a particular chosen number that the

> >> attacker does not have th= e authority to call from.

> >

> > What you want here is to remo= ve the implication that the number will

> > be rendered on the terminatin= g side? While there are some attacks

> > where that isn't significant,= perhaps, I would say it is significant

> > in the primary attack vectors= that concern us.

> >

> >> 2.  Replace 3rd para= graph of 2.1 Endpoints with:

> >>

> >>     S= mart devices are generally based on computers with some degree<= /o:p>

> >> of programmability, the c= apacity to access the Internet, and

> >> capabilities of rendering= text, audio and/or images.  This includes

> >> smart phones, telephone a= pplications on desktop and laptop computers,

> >> IP private branch exchang= es, and so on.

> >

> > I can add the notion that sma= rt devices can render text, audio and/or

> > images as you suggest.=

> >

> >> 3.  Add to 3.3 Attac= k Scenarios:

> >>

> >>     &= nbsp; Impersonation, IP-Mobile Text Message

> >>

> >>     &= nbsp;  An attacker with an computer sends a high volume of SIP MESSAGE=

> >> spam message to IP-enable= d smart phones using randomized calling

> >> party numbers.

> >>

> >>     &= nbsp; Countermeasure: in-band authenticated identity

> >

> > Provided we're talking about = end-to-end SIP use of MESSAGE, agreed

> > that in-band would be the rig= ht countermeasure. I am curious though

> > whether practically speaking = there is enough use of MESSAGE in this

> > fashion that we're actually s= eeing high-volume spam over MESSAGE

> > today. Either way, no problem= having an attack scenario of this form in the

> document.

> >

> > Jon Peterson

> > Neustar, Inc.

> >

> >> Regards,

> >>

> >> Alex

> >>

> >>> -----Original Message= -----

> >>> Of Richard Shockey

> >>> Sent: Monday, Septemb= er 30, 2013 1:11 PM

> >>> To: 'DOLLY, MARTIN C'= ; 'Robert Sparks'

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] d= raft-peterson-stir-threats-00.txt

> >>>

> >>> +1

> >>>

> >>> -----Original Message= -----

> >>> Of DOLLY, MARTIN C

> >>> Sent: Monday, Septemb= er 30, 2013 12:58 PM

> >>> To: Robert Sparks

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] d= raft-peterson-stir-threats-00.txt

> >>>

> >>> Yes, ok

> >>>

> >>> Martin Dolly

> >>> Lead Member of Techni= cal Staff

> >>> Core Network & Go= v't/Regulatory Standards AT&T Labs - Network

> >>> Technology

> >>> +1-609-903-3360

> >>> md3135@att.com=

> >>>

> >>>> On Sep 30, 2013, = at 12:47 PM, "Robert Sparks"

> >>> wrote:

> >>>>=

> >>>>> On 9/26/13 3:= 42 PM, DOLLY, MARTIN C wrote:

> >>>>> With Hadriel = comments incorporated, it is a start

> >>>> Hi Martin -

> >>>>=

> >>>> Just to make sure= - I think you're referring to Hadriel's comments

> >>>> on the

> >>> problem statement doc= ument?

> >>>> I don't think Had= riel's commented directly on stir-threats yet.

> >>>>=

> >>>> In any case, we _= are_ talking about a starting place, not a

> >>>> finished

> >>> product.<= /o:p>

> >>>>=

> >>>> If there's no oth= er objection, I'd like to get Jon to submit the

> >>>> threats

> >>> document as a WG -00 = as soon as it's convenient.

> >>>>=

> >>>> RjS

> >>>>>

> >>>>> -----Original= Message-----

> >>>>> Behalf Of Rus= s Housley

> >>>>> Sent: Thursda= y, September 26, 2013 4:37 PM

> >>>>> To: IETF STIR= Mail List

> >>>>> Subject: Re: = [stir] draft-peterson-stir-threats-00.txt

> >>>>>

> >>>>> It has been s= ix days, I'd like to hear from more people about this

> >>> document.  Marti= n asked for an additional week, so I'm sure we will

> >>> hear from him soon.

> >>>>>

> >>>>> Russ

> >>>>>

> >>>>>

> >>>>>> On Sep 20= , 2013, at 5:23 PM, Russ Housley wrote:

> >>>>>>

> >>>>>>

> >>>>>> Should th= e working group adopt this I-D as the starting point for<= /p>

> >>>>>> the

> >>> STIR threat docuent?<= /span>

> >>>>>>

> >>>>>> Russ

> >>>>> _____________= __________________________________

> >>>>> stir mailing = list

> >>>>> stir@ietf.org

> >>>>=

> >>>> _________________= ______________________________

> >>>> stir mailing list=

> >>>> stir@ietf.org

> >>> _____________________= __________________________

> >>> stir mailing list

> >>> stir@ietf.org<= o:p>

> >>>

> >>> _____________________= __________________________

> >>> stir mailing list

> >>> stir@ietf.org<= o:p>

> >> _________________________= ______________________

> >> stir mailing list<= o:p>

> >

> > _____________________________= __________________

> > stir mailing list=

> 

> __________________________________= _____________

> stir mailing list

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

______________________________________= _________
stir mailing list
stir@ietf.org
https://www.ietf.org= /mailman/listinfo/stir

 

 

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

--_000_E6A16181E5FD2F46B962315BB05962D01FC238EEp2pxmb13fccnetw_-- From br@brianrosen.net Thu Nov 7 09:03:40 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A260121E811D for ; Thu, 7 Nov 2013 09:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuOhNVHfTfQt for ; Thu, 7 Nov 2013 09:03:36 -0800 (PST) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id A36DF21E813F for ; Thu, 7 Nov 2013 09:03:33 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id mz13so350681bkb.30 for ; Thu, 07 Nov 2013 09:03:32 -0800 (PST) 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:message-id:references:to; bh=xWxicylaqmEADPx0YtR3rsytnyhoEa4/BE1Xf6EluJ8=; b=crp69X/nrDzxviOxNxmkA6HkhjR8IF499aiwxpF5W1hMRM3SPFxge3XOuGlQ5pyNAb Jc79v7DpPahRLrjZZAlvGl1VNhnCHA7O2cmwZ6hrC0IkTsL0+N/DyXp8y66x7OCbI8pw geB5Iid7WKkqKbWX3fe1QIm1Nu6NnhgfvjPFdGQEMyaAECd5ppLf88/CJaaM/tG2yAgD J86inOt3sU7VEPKWvpWY8IO/yLs09o0xa7tT7lB1hNaW5mnpzWp8qNwVsvXE0CXFIVog KF20AqFQmshiqKTtvf5S+aKBUIc32HYpFJbVcUBiFJSOsVIjTvcSCdDJ6m++kaxxF7rA THeg== X-Gm-Message-State: ALoCoQkWDEgfGEzegh2cCZMUpaEgGFolIgaesElQ0wqkgfh2fjlML943/XA2wUvwRKcVOA7voK+n X-Received: by 10.204.170.72 with SMTP id c8mr14760bkz.168.1383843812679; Thu, 07 Nov 2013 09:03:32 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:9d97:144b:5e61:753]) by mx.google.com with ESMTPSA id b7sm3004958bkg.1.2013.11.07.09.03.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 09:03:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_002AC86A-B46F-4492-AFD3-8423E16D53ED" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: Date: Thu, 7 Nov 2013 09:03:22 -0800 Message-Id: <6A94C6CF-69F6-42D9-9A6C-32361A0A4755@brianrosen.net> References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7D86@sc9-ex2k10mb1.corp.yaanatech.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1816) Cc: "cnit@ietf.org" , Richard Shockey , "stir@ietf.org" , "Pierce.Gorman@sprint.com" , Michael Hammer , "fmousinh@cisco.com" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:03:40 -0000 --Apple-Mail=_002AC86A-B46F-4492-AFD3-8423E16D53ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Right. I believe we can do this pretty easily. We probably could have = a 100 categories that would have similar authorities, and there are = classifications maintained by folks like Dun Bradstreet that can go even = farther. What I think would be substantially harder is to validate an entire = V/X/J card. How is a validator to know your nickname is Fluffy? Name, = phone number and, if a business, a classification, yes, we can do that. = Content of a business card - very hard. Brian On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne = wrote: > Yes, that=92s a problem, but as long as the number of categories is = small, you can build UIs that only render information that=92s = appropriate to the declaration. For practical reasons, I think the = number of useful categories is likely going to be fairly limited: > - Financial institution (FDIC and a few others) > - Health care (each health care facility has a gov=92t = number) > - Charity (501c3, state registered) > - Contractor (state-licensed) > - Public safety organization (police, fire) > - Lawyer (bar association) > - Local, state and federal government (.gov in the US) > =20 > I suspect that list encompasses a large fraction of the fraudulent = (impersonation) calls. For all of the above, at least within a country, = it=92s pretty clear who can attest to the membership. Yes, this requires = some UI work or some server logic, but these categories and the = organizations don=92t change all that often =96 in most cases, the = certifying entities have probably been the same for the past 50+ years. = I=92m not as worried about figuring out whether the beautician, = mortician or florist is licensed and properly identified, although I=92m = sure we can all come up with potential fraud stories. > =20 > From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 > Sent: Thursday, November 07, 2013 10:28 AM > To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; = richard@shockey.us > Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org > Subject: RE: [stir] draft-peterson-stir-threats-00.txt > =20 > So, would you trust a certificate from the City of Reston, Virginia = police department? > =20 > (Hint: you can find Reston on a map, but there is no City of Reston.=20= > The only police are Fairfax County.) > =20 > My concern is that one you dilute or disperse authority, it becomes a = free-for-all again, and anybody=92s guess. > =20 > Mike > =20 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Henning Schulzrinne > Sent: Thursday, November 07, 2013 10:00 AM > To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey > Cc: stir@ietf.org List; Fernando Mousinho (fmousinh); cnit@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > As a thought experiment, Kumiko Ono and I had published a draft > =20 > http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 > =20 > to allow third parties to validate property information. If the = validating party (e.g., a bank regulator) is willing to sign a = certificate, similar in spirit to the framed gold-leaf diplomas in your = dentist=92s office or, more lowly, to the health departments rating in a = restaurant window, and it can be tied to a phone number, this shouldn=92t = be too hard. > =20 > It=92s a bit harder if the certifying authority (regulator, Realtor = board, local bar association, =85) is not involved. > =20 > Henning > =20 > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf = Of Gorman, Pierce A [NTK] > Sent: Thursday, November 07, 2013 9:54 AM > To: Brian Rosen; Richard Shockey > Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) > Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt > =20 > I=92ll admit I am not familiar with v/x/jcard encoding differences or = the implications of their use so I=92ll encourage educating me if it = isn=92t too onerous. > =20 > I=92m not sure what is the concern with a 3rd party providing = =93validation=94 though. There are numerous examples of 3rd parties = providing validation of information including NASDAQ, NYSE, Barron=92s, = Moody=92s, and the federal reserve banking system to name a few. > =20 > Pierce > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: November 06, 2013 11:59 PM > To: Richard Shockey > Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; = stir@ietf.org List; cnit@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > I think this would be a heavy lift. > =20 > If the responsible entity was a carrier, then it would have to = validate the data, which it has very little basis to validate. It could = get a 3rd party to do the validation, but then it=92s putting its = reputation on the back of some hired hand validator. > =20 > If the responsibility is the end user/device, then the signature has = no value. > =20 > I do not argue that Call-Info is suitable, it is. > =20 > I do question JCARD vs xCard, but that=92s an encoding detail. All of = SIP Is XML described by schema, not json. > =20 > Brian > =20 > On Nov 6, 2013, at 1:10 PM, Richard Shockey = wrote: > =20 >=20 > URI for a JCARD in the CALL INFO header provisioned by the calling = party and ultimately signed by the responsible entity. The carrier = could provision this for their mobile or hosted customers. Enterprises = could do this themselves. This also has advantages in Enterprise to = Enterprise UC as well where the data is derived from the Enterprise = =93directory=94 and could facilitate end to end PPX to PBX = communications especially in point to point video communications. > =20 > There are certainly privacy and security issues to be addressed. The = Push vs Pull model. This really would be PII in the clear but then its = done voluntarily. > =20 > There would have to be some work around restructuring the Header and = adding some parameters but it=92s underutilized right now and this Use = Case is a perfectly appropriate use. > =20 > https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 > =20 > Obviously it would need to be signed but we don=92t need to worry = about that ..yet. > =20 > =46rom 3261 > =20 > 20.9 Call-Info > =20 > The Call-Info header field provides additional information about = the > caller or callee, depending on whether it is found in a request or > response. The purpose of the URI is described by the "purpose" > parameter. The "icon" parameter designates an image suitable as an > iconic representation of the caller or callee. The "info" = parameter > describes the caller or callee in general, for example, through a = web > page. The "card" parameter provides a business card, for example, = in > vCard [36] or LDIF [37] formats. Additional tokens can be = registered > using IANA and the procedures in Section 27. > =20 > Use of the Call-Info header field can pose a security risk. If a > callee fetches the URIs provided by a malicious caller, the callee > may be at risk for displaying inappropriate or offensive content, > dangerous or illegal content, and so on. Therefore, it is > RECOMMENDED that a UA only render the information in the Call-Info > header field if it can verify the authenticity of the element that > originated the header field and trusts that element. This need not > be the peer UA; a proxy can insert this header field into requests. > =20 > Example: > =20 > Call-Info: ;purpose=3Dicon,= > ;purpose=3Dinfo > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, November 06, 2013 3:41 PM > To: Richard Shockey > Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; = stir@ietf.org List > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > We=92ve considered adding some information that is not number and is = not name, but is something like =93bank=94, which might have some sort = of validation behind it. > =20 > Is that along the lines you were thinking? > =20 > Brian > On Nov 6, 2013, at 5:25 AM, Richard Shockey = wrote: > =20 >=20 > I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification. Though = your use case of credit card validation is a useful one and you are = right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session validation. > =20 > It=92s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list. > =20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > =20 > But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about. STIR is essential but it=92s a = multi-faceted problem that may require multi-faceted solutions.. and = enhanced CNAM + being only one of them. Its not unreasonable to = discuss those. > =20 > The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. I = would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in question. > =20 > =20 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Fernando Mousinho (fmousinh) > Sent: Tuesday, November 05, 2013 6:26 PM > To: Gorman, Pierce A [NTK]; stir@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Let me rephrase it=85 it may eliminate the need for other forms of = caller identification beyond what STIR will provide, depending on the = specific use case. For example, a credit card company may choose to rely = entirely on STIR before allowing a card to be unblocked by an IVR (and = as I said earlier, many companies do it today). In other use cases, the = TN alone is not sufficient information =96 my health care provider will = want to know which member of the family is calling. > =20 > I agree that ANI is already broadly used to improve customer service = today. However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of companies. > =20 > =20 > Going on a tangent=85 perhaps this is out of scope, but there is not a = lot of discussion about called party hijacking. Couldn=92t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it=92s really them before carrying a = conversation, but wouldn=92t they want the same?=20 > =20 > =20 > From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM > To: Fernando Mousinho , "stir@ietf.org" = > Subject: RE: [stir] draft-peterson-stir-threats-00.txt > =20 > I agree with your characterization of businesses as victim of caller = ID fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center. So I don=92t agree that STIR = would =93eliminate the need for caller identification from known TNs.=94 > =20 > But perhaps I misunderstood your last sentence? > =20 > =20 > From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com]=20 > Sent: November 05, 2013 4:34 PM > To: stir@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > I would suggest we add a new attack type to section 3. More and more = companies are using the caller ID for account validation. For example, = if I call my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I=92m informed that = I don=92t need to provide any further identification because my number = is on file. Some (all?) companies that implement this type of validation = rely on SS7 today. > =20 > Ultimately, this is yet another variation of impersonation =96 but in = this case, the =93victim=94 is a business, unlike the other two = scenarios we=92ve listed so far. > =20 > Addressing this scenario would actually turn STIR into a feature, = given it would enable contact centers of all sizes to eliminate the need = for caller identification from known TNs. > =20 > =20 > =20 > From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM > To: Brian Rosen , "Peterson, Jon" = > Cc: "stir@ietf.org" , Richard Shockey = , "'DOLLY, MARTIN C'" , 'Robert = Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Jon, > =20 > Thanks for the response. The intention in #1 below is to clarify the = following sentence: > =20 > The primary attack vector is > therefore one where the attacker contrives for the calling = telephone > number in signaling to be a particular chosen number, one that the > attacker does not have the authority to call from, in order for = that > number to be rendered on the terminating side.=20 > =20 > This might be misconstrued as indicating that the objective of = spoofing is simply the rendering of a spoofed number on the receiving = display, causing mistaken conclusions that defenses might be limited to = securing the rendered information. No issues with leaving this as it=92s = a valid point. Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on CPN.=20 > =20 > So however it=92s worded, I think it=92s important to allow for both = attack objectives of a spoofed presentation at the endpoint and in = transit. =20 > =20 > Regards, > =20 > Alex > =20 > > -----Original Message----- > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > > Brian Rosen > > Sent: Tuesday, October 01, 2013 9:29 AM > > To: Peterson, Jon > > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; = Richard > > Shockey > > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >=20 > > Don't think there is much MESSAGE. MSRP is about all we see, and = XMPP is > > more likely than that. > >=20 > > Brian > >=20 > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" = > > wrote: > >=20 > > > Thanks for these notes, Alex. Some responses below. > > > > > >> Here are several comments that should feed into the IETF Peterson = draft: > > >> > > >> * Remove any assumptions that the solution cannot be in-network > > [IMO, > > >> both endpoint and in-network solutions should be facilitated] > > > > > > Agreed that both in-band and out-of-band solutions can usually be > > > implemented in either endpoints or in intermediaries of various = kinds. > > > If I see text that implies otherwise, I'll certainly change it. > > > > > >> * Add a sessionless attack scenario. A spam payload may be = carried in > > a > > >> SIP INVITE or MESSAGE, which might contain stock market advice = even > > >> in a display name field. These attacks do NOT require session > > establishment. > > >> More generally, we should be mindful of the fact that SIP is used = in > > >> telephony form more than voice session setup. > > > > > > Probably if we were going to include a sessionless attack = scenario, it > > > would be with regular text messages (whether carried on the PSTN = over > > > TCAP or with some Internet protocol, including MESSAGE) rather = than > > > with an INVITE, which typically wouldn't result in a payload being > > > immediately rendered to a user. More on this below with your = suggested > > text. > > > > > >> Here's some suggested markup: > > >> > > >> > > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction = with: > > >> > > >> The primary attack vector is > > >> therefore one where the attacker contrives for the calling = telephone > > >> number in signaling to be a particular chosen number that the > > >> attacker does not have the authority to call from. > > > > > > What you want here is to remove the implication that the number = will > > > be rendered on the terminating side? While there are some attacks > > > where that isn't significant, perhaps, I would say it is = significant > > > in the primary attack vectors that concern us. > > > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > > >> > > >> Smart devices are generally based on computers with some = degree > > >> of programmability, the capacity to access the Internet, and > > >> capabilities of rendering text, audio and/or images. This = includes > > >> smart phones, telephone applications on desktop and laptop = computers, > > >> IP private branch exchanges, and so on. > > > > > > I can add the notion that smart devices can render text, audio = and/or > > > images as you suggest. > > > > > >> 3. Add to 3.3 Attack Scenarios: > > >> > > >> Impersonation, IP-Mobile Text Message > > >> > > >> An attacker with an computer sends a high volume of SIP = MESSAGE > > >> spam message to IP-enabled smart phones using randomized calling > > >> party numbers. > > >> > > >> Countermeasure: in-band authenticated identity > > > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > > that in-band would be the right countermeasure. I am curious = though > > > whether practically speaking there is enough use of MESSAGE in = this > > > fashion that we're actually seeing high-volume spam over MESSAGE > > > today. Either way, no problem having an attack scenario of this = form in the > > document. > > > > > > Jon Peterson > > > Neustar, Inc. > > > > > >> Regards, > > >> > > >> Alex > > >> > > >>> -----Original Message----- > > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf > > >>> Of Richard Shockey > > >>> Sent: Monday, September 30, 2013 1:11 PM > > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > > >>> Cc: stir@ietf.org > > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>> > > >>> +1 > > >>> > > >>> -----Original Message----- > > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf > > >>> Of DOLLY, MARTIN C > > >>> Sent: Monday, September 30, 2013 12:58 PM > > >>> To: Robert Sparks > > >>> Cc: stir@ietf.org > > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>> > > >>> Yes, ok > > >>> > > >>> Martin Dolly > > >>> Lead Member of Technical Staff > > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > > >>> Technology > > >>> +1-609-903-3360 > > >>> md3135@att.com > > >>> > > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > > >>>> > > >>> wrote: > > >>>> > > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > > >>>>> With Hadriel comments incorporated, it is a start > > >>>> Hi Martin - > > >>>> > > >>>> Just to make sure - I think you're referring to Hadriel's = comments > > >>>> on the > > >>> problem statement document? > > >>>> I don't think Hadriel's commented directly on stir-threats yet. > > >>>> > > >>>> In any case, we _are_ talking about a starting place, not a > > >>>> finished > > >>> product. > > >>>> > > >>>> If there's no other objection, I'd like to get Jon to submit = the > > >>>> threats > > >>> document as a WG -00 as soon as it's convenient. > > >>>> > > >>>> RjS > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On > > >>>>> Behalf Of Russ Housley > > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > > >>>>> To: IETF STIR Mail List > > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>>>> > > >>>>> It has been six days, I'd like to hear from more people about = this > > >>> document. Martin asked for an additional week, so I'm sure we = will > > >>> hear from him soon. > > >>>>> > > >>>>> Russ > > >>>>> > > >>>>> > > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > > >>>>>> > > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > > >>>>>> > > >>>>>> Should the working group adopt this I-D as the starting point = for > > >>>>>> the > > >>> STIR threat docuent? > > >>>>>> > > >>>>>> Russ > > >>>>> _______________________________________________ > > >>>>> 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 > > >>> _______________________________________________ > > >>> 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 > > >> _______________________________________________ > > >> 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 > >=20 > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > =20 >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > =20 > =20 > =20 >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. --Apple-Mail=_002AC86A-B46F-4492-AFD3-8423E16D53ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Right. =  I believe we can do this pretty easily.  We probably could = have a 100 categories that would have similar authorities, and there are = classifications maintained by folks like Dun Bradstreet that can go even = farther.

What I think would be substantially harder = is to validate an entire V/X/J card.  How is a validator to know = your nickname is Fluffy?  Name, phone number and, if a business, a = classification, yes, we can do that.  Content of a business card - = very = hard.

Brian


On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Yes, that=92s a problem, but as long as the number of = categories is small, you can build UIs that only render information = that=92s appropriate to the declaration. For practical reasons, I think = the number of useful categories is likely going to be fairly = limited:
-          Financial institution (FDIC and a few = others)
-          Health care (each health care facility has a gov=92t = number)
-          Charity (501c3, state = registered)
-          Contractor = (state-licensed)
-          Public safety organization (police, = fire)
-          Lawyer (bar association)
-          Local, state and federal government (.gov in the = US)
 
I suspect that list encompasses a large fraction of = the fraudulent (impersonation) calls. For all of the above, at least = within a country, it=92s pretty clear who can attest to the membership. = Yes, this requires some UI work or some server logic, but these = categories and the organizations don=92t change all that often =96 in = most cases, the certifying entities have probably been the same for the = past 50+ years. I=92m not as worried about figuring out whether the = beautician, mortician or florist is licensed and properly identified, = although I=92m sure we can all come up with potential fraud = stories.
 
From: Michael Hammer [mailto:michael.hammer@yaanate= ch.com] 
Sent: Thursday, November 07, 2013 = 10:28 AM
To: Henning Schulzrinne; Pierce.Gorman@sprint.com; = br@brianrosen.net; richard@shockey.us
Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt
 
So, would you trust a certificate from the City of = Reston, Virginia police department?
 
(Hint:  you can find = Reston on a map, but there is no City of = Reston. 
  The only police are Fairfax = County.)
 
My concern is that one you dilute or disperse = authority, it becomes a free-for-all again, and anybody=92s = guess.
 
Mike
 
 
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Thursday, November 07, 2013 = 10:00 AM
To: 'Gorman, Pierce A [NTK]'; = Brian Rosen; Richard Shockey
Cc: stir@ietf.org List; Fernando Mousinho = (fmousinh); cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
As a thought experiment, Kumiko Ono and I had = published a draft
 
 
to allow third parties to validate property = information. If the validating party (e.g., a bank regulator) is willing = to sign a certificate, similar in spirit to the framed gold-leaf = diplomas in your dentist=92s office or, more lowly, to the health = departments rating in a restaurant window, and it can be tied to a phone = number, this shouldn=92t be too hard.
 
It=92s a bit harder if = the certifying authority (regulator, Realtor board, local bar = association, =85) is not involved.
 
Henning
 
From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gorman, Pierce A = [NTK]
Sent: Thursday, November 07, 2013 = 9:54 AM
To: Brian Rosen; Richard = Shockey
Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho = (fmousinh)
Subject: Re: [cnit] [stir] = draft-peterson-stir-threats-00.txt
 
I=92ll admit I am not familiar with v/x/jcard = encoding differences or the implications of their use so I=92ll = encourage educating me if it isn=92t too = onerous.
 
I=92m not sure what is the concern with a 3rd party providing = =93validation=94 though.  There are numerous examples of = 3rd parties = providing validation of information including NASDAQ, NYSE, Barron=92s, = Moody=92s, and the federal reserve banking system to name a = few.
 
Pierce
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: November 06, 2013 11:59 = PM
To: Richard= Shockey
Cc: Fernando Mousinho = (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
I = think this would be a heavy lift.
 
If the responsible entity was a carrier, then it = would have to validate the data, which it has very little basis to = validate.  It could get a 3rd party to do the validation, but then = it=92s putting its reputation on the back of some hired hand = validator.
 
If = the responsibility is the end user/device, then the signature has no = value.
 
I do = not argue that Call-Info is suitable,  it = is.
 
I do = question JCARD vs xCard, but that=92s an encoding detail.  All of = SIP Is XML described by schema, not = json.
 
Brian
 
On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> = wrote:

 

URI for a JCARD in the CALL INFO header provisioned = by the calling party and ultimately signed by the responsible entity. =  The carrier could provision this for their mobile or hosted = customers.  Enterprises could do this themselves.  This also = has advantages in Enterprise to Enterprise UC as well where the data is = derived from the Enterprise =93directory=94 and could facilitate end to = end PPX to PBX communications especially in point to point video = communications.
 
There are certainly privacy and = security issues to be addressed.  The Push vs Pull model.  = This really would be PII in the clear but then its done = voluntarily.
 
There would have to be some work = around restructuring the Header and adding some parameters but it=92s = underutilized right now and this Use Case is a perfectly appropriate = use.
 
 
Obviously it would need to be signed but we don=92t = need to worry about that ..yet.
 
=46rom 3261
 
20.9 Call-Info
 
   The Call-Info header field provides = additional information about the
   caller or = callee, depending on whether it is found in a request = or
   response.  The purpose of the URI = is described by the "purpose"
   parameter.  The = "icon" parameter designates an image suitable as = an
   iconic representation of the caller or = callee.  The "info" parameter
   describes = the caller or callee in general, for example, through a = web
   page.  The "card" parameter = provides a business card, for example, in
   vCard [36] = or LDIF [37] formats.  Additional tokens can be = registered
   using IANA and the procedures in Section = 27.
 
   Use of the Call-Info = header field can pose a security risk.  If = a
   callee fetches the URIs provided by a = malicious caller, the callee
   may be at risk for = displaying inappropriate or offensive = content,
   dangerous or illegal content, and so = on.  Therefore, it is
   RECOMMENDED that a UA = only render the information in the Call-Info
   header field = if it can verify the authenticity of the element = that
   originated the header field and trusts = that element.  This need not
   be the peer = UA; a proxy can insert this header field into = requests.
 
   = Example:
 
   Call-Info: <http://wwww.example.com/alice/photo.jpg> = ;purpose=3Dicon,
     <http://www.example.com/alice/> = ;purpose=3Dinfo
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Wednesday, November 06, = 2013 3:41 PM
To: Richard = Shockey
Cc: Fernando Mousinho = (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
We=92ve= considered adding some information that is not number and is not name, = but is something like =93bank=94, which might have some sort of = validation behind it.
 
Is = that along the lines you were thinking?
 
Brian
On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:

 

I agree with Pierce here and respectfully disagree = that STIR might eliminate the need for other forms of caller = identification.  Though your use case of credit card validation is = a useful one and you are right there are still applications that use SS7 = for things that have nothing to do with call setup. I agree with you = STIR may have more applications beyond the obvious ones of realtime = session validation.
 
It=92s been my experience recently = that there is a use case for something MORE in the identification of the = session as it is presented to the called party. This is the CNAM + idea = we are kicking around on the CNIT = list.
 
_______________________________________________
cnit mailing = list
 
But your use case of a bank = wanting to make sure they could properly identify themselves to the = consumer before establishing a conversation is exactly what this process = is about.  STIR is essential but it=92s a multi-faceted problem = that may require multi-faceted solutions.. and enhanced CNAM + being = only one of them.   Its not unreasonable to discuss = those.
 
The obviously analogy is = I would want to see some real identification of a utility worker before = I let them into my house to make repairs.  I would want some = validation that the call to me to reconfirm the appointments was in fact = from the utility in question.
 
 
 
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A = [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
Let me rephrase it=85 it may eliminate the need = for other forms of caller identification beyond what STIR will provide, = depending on the specific use case. For example, a credit card company = may choose to rely entirely on STIR before allowing a card to be = unblocked by an IVR (and as I said earlier, many companies do it today). = In other use cases, the TN alone is not sufficient information =96 my = health care provider will want to know which member of the family is = calling.
 
I agree that ANI is already broadly used to = improve customer service today. However, it is not usually deemed as a = secure enough mechanism to validate the caller (therefore this WG!), = except if you are a large organization that can leverage things like = SS7. STIR would make this type of validation available to a broader = number of companies.
 
 
Going on a tangent=85 perhaps this is out of = scope, but there is not a lot of discussion about called party = hijacking. Couldn=92t a man-in-the-middle try to answer calls on my = behalf? If my bank is calling me, I want to make sure it=92s really them = before carrying a conversation, but wouldn=92t they want the = same? 
 
 
From: <Gorman>, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Date: Tuesday, November 5, = 2013 at 6:05 PM
To: Fernando Mousinho = <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt
 
I agree with your characterization = of businesses as victim of caller ID fraud however contact centers also = use TN as a key to improve information available to call agents to = reduce average time-per-call and increase capacity of the call = center.  So I don=92t agree that STIR would =93eliminate the need = for caller identification from known = TNs.=94
 
But perhaps I misunderstood your last = sentence?
 
 
From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
I would suggest we add a new attack type to = section 3. More and more companies are using the caller ID for account = validation. For example, if I call my credit card provider from my = office number, they ask me for identification. If I call from my home = phone number, I=92m informed that I don=92t need to provide any further = identification because my number is on file. Some (all?) companies that = implement this type of validation rely on SS7 = today.
 
Ultimately, this is yet another variation of = impersonation =96 but in this case, the =93victim=94 is a business, = unlike the other two scenarios we=92ve listed so = far.
 
Addressing this scenario would actually turn STIR = into a feature, given it would enable contact centers of all sizes to = eliminate the need for caller identification from known = TNs.
 
 
 
From: Alex = Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, = 2013 at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, MARTIN C'" <md3135@att.com>, 'Robert Sparks' <rjsparks@nostrum.com>
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
Jon,
 
Thanks for the response.  The intention in #1 = below is to clarify the following = sentence:
 
The primary attack vector = is
   therefore one where the attacker contrives for = the calling telephone
   number in signaling to be a = particular chosen number, one that = the
   attacker does not have the authority to call = from, in order for = that
   number to be rendered on the terminating = side. 
 
This might be misconstrued as indicating that the = objective of spoofing is simply the rendering of a spoofed number on the = receiving display, causing mistaken conclusions that defenses might be = limited to securing the rendered information.  No issues with = leaving this as it=92s a valid point.  Another (increasing) = motivation is to evade network and/or endpoint defenses that may block = based on CPN. 
 
So however it=92s worded, I think it=92s important = to allow for both attack objectives of a spoofed presentation at the = endpoint and in transit.  =  
 
Regards,
 
Alex
 
> -----Original = Message-----
> Brian = Rosen
> Sent: = Tuesday, October 01, 2013 9:29 AM
> To: Peterson, = Jon
> = Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, = MARTIN C'; Richard
> Shockey
> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> 
> Don't think there is much MESSAGE.  MSRP = is about all we see, and XMPP is
> more likely than = that.
> 
> Brian
> 
> On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" = <jon.peterson@neustar.biz>
> = wrote:
> 
> > Thanks for these notes, Alex. Some = responses below.
> >
> >> Here are several comments that = should feed into the IETF Peterson = draft:
> = >>
> = >> *   Remove any assumptions that the solution cannot = be in-network
> [IMO,
> >> both endpoint and in-network = solutions should be facilitated]
> >
> > Agreed that both in-band and out-of-band = solutions can usually be
> > implemented in either endpoints or in = intermediaries of various kinds.
> > If I see text that implies otherwise, = I'll certainly change it.
> >
> >> *   Add a sessionless = attack scenario.  A spam payload may be carried = in
> = a
> = >> SIP INVITE or MESSAGE, which might contain stock market advice = even
> = >> in a display name field.  These attacks do NOT require = session
> = establishment.
> >> More generally, we should be mindful of the = fact that SIP is used in
> >> telephony form more than voice = session setup.
> >
> > Probably if we were going to include a = sessionless attack scenario, it
> > would be with regular text messages = (whether carried on the PSTN over
> > TCAP or with some Internet protocol, = including MESSAGE) rather than
> > with an INVITE, which typically wouldn't = result in a payload being
> > immediately rendered to a user. More on = this below with your suggested
> text.
> >
> >> Here's some suggested = markup:
> = >>
> = >>
> = >> 1.    Replace 2nd sentence of 2nd paragraph of = 1.0 Introduction with:
> = >>
> = >> The primary attack vector = is
> = >>  therefore one where the attacker contrives for the = calling telephone
> >> number in signaling to be a particular chosen = number that the
> >> attacker does not have the authority to call = from.
> = >
> > = What you want here is to remove the implication that the number = will
> > = be rendered on the terminating side? While there are some = attacks
> > = where that isn't significant, perhaps, I would say it is = significant
> > in the primary attack vectors that concern = us.
> = >
> = >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:
> = >>
> = >>     Smart devices are generally based on = computers with some degree
> >> of programmability, the capacity to = access the Internet, and
> >> capabilities of rendering text, = audio and/or images.  This = includes
> = >> smart phones, telephone applications on desktop and laptop = computers,
> >> IP private branch exchanges, and so = on.
> = >
> > I = can add the notion that smart devices can render text, audio = and/or
> > = images as you suggest.
> >
> >> 3.  Add to 3.3 Attack = Scenarios:
> >>
> >>       = Impersonation, IP-Mobile Text = Message
> = >>
> = >>        An attacker with an = computer sends a high volume of SIP = MESSAGE
> = >> spam message to IP-enabled smart phones using randomized = calling
> = >> party numbers.
> = >>
> = >>       Countermeasure: in-band = authenticated identity
> >
> > Provided we're talking about end-to-end = SIP use of MESSAGE, agreed
> > that in-band would be the right = countermeasure. I am curious = though
> > = whether practically speaking there is enough use of MESSAGE in = this
> > = fashion that we're actually seeing high-volume spam over = MESSAGE
> > = today. Either way, no problem having an attack scenario of this form in = the
> = document.
> >
> > Jon = Peterson
> > = Neustar, Inc.
> >
> >> = Regards,
> = >>
> = >> Alex
> >>
> >>> -----Original = Message-----
> = >>> Of Richard Shockey
> >>> Sent: Monday, September 30, 2013 = 1:11 PM
> = >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'
> = >>> Cc: stir@ietf.org
> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> = >>>
> >>> +1
> = >>>
> >>> -----Original = Message-----
> = >>> Of DOLLY, MARTIN C
> >>> Sent: Monday, September 30, 2013 = 12:58 PM
> = >>> To: Robert Sparks
> >>> Cc: stir@ietf.org
> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> = >>>
> >>> Yes, = ok
> = >>>
> >>> Martin = Dolly
> = >>> Lead Member of Technical = Staff
> = >>> Core Network & Gov't/Regulatory Standards AT&T Labs = - Network
> >>> = Technology
> >>> = +1-609-903-3360
> = >>>
> >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"
> >>> = wrote:
> = >>>>
> >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN = C wrote:
> = >>>>> With Hadriel comments incorporated, it is a = start
> = >>>> Hi Martin -
> = >>>>
> >>>> Just to make sure - I think you're = referring to Hadriel's comments
> >>>> on = the
> = >>> problem statement = document?
> >>>> I don't think Hadriel's commented = directly on stir-threats yet.
> = >>>>
> >>>> In any case, we _are_ talking about a = starting place, not a
> >>>> = finished
> = >>> product.
> = >>>>
> >>>> If there's no other objection, I'd = like to get Jon to submit the
> >>>> = threats
> = >>> document as a WG -00 as soon as it's = convenient.
> = >>>>
> >>>> = RjS
> = >>>>>
> >>>>> -----Original = Message-----
> = >>>>> Behalf Of Russ = Housley
> = >>>>> Sent: Thursday, September 26, 2013 4:37 = PM
> = >>>>> To: IETF STIR Mail = List
> = >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> = >>>>>
> >>>>> It has been six days, = I'd like to hear from more people about = this
> = >>> document.  Martin asked for an additional week, so I'm = sure we will
> >>> hear from him = soon.
> = >>>>>
> >>>>> = Russ
> = >>>>>
> = >>>>>
> >>>>>> On Sep 20, 2013, at = 5:23 PM, Russ Housley wrote:
> = >>>>>>
> = >>>>
> >>>> = _______________________________________________
> >>>> stir mailing = list
> = >>>> stir@ietf.org
> >>> = _______________________________________________
> >>> stir mailing = list
> = >>> stir@ietf.org
> = >>>
> >>> = _______________________________________________
> >>> stir mailing = list
> = >>> stir@ietf.org
> >> = _______________________________________________
> >> stir mailing = list
> = >
> > = _______________________________________________
> > stir mailing = list
> 
> = _______________________________________________
> stir mailing = list
 

This e-mail may contain Sprint proprietary = information intended for the sole use of the recipient(s). Any use by = others is prohibited. If you are not the intended recipient, please = contact the sender and delete all copies of the = message.
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir
 
 
 

This e-mail may contain Sprint proprietary information = intended for the sole use of the recipient(s). Any use by others is = prohibited. If you are not the intended recipient, please contact the = sender and delete all copies of the = message.

= --Apple-Mail=_002AC86A-B46F-4492-AFD3-8423E16D53ED-- From Henning.Schulzrinne@fcc.gov Thu Nov 7 09:09:44 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D2B21F9DBD; Thu, 7 Nov 2013 09:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eri3t-+KrLW8; Thu, 7 Nov 2013 09:09:32 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 74B4621E81F6; Thu, 7 Nov 2013 09:09:18 -0800 (PST) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQHO28lBm7MQs/E/Y0C8yrTGiGFz45oZ21rggABc6AD//7YS0IAAZHIA//+swSA= Date: Thu, 7 Nov 2013 17:09:17 +0000 References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7D86@sc9-ex2k10mb1.corp.yaanatech.com> <6A94C6CF-69F6-42D9-9A6C-32361A0A4755@brianrosen.net> In-Reply-To: <6A94C6CF-69F6-42D9-9A6C-32361A0A4755@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FC23A6Fp2pxmb13fccnetw_" MIME-Version: 1.0 Cc: "cnit@ietf.org" , Richard Shockey , "stir@ietf.org" , "Pierce.Gorman@sprint.com" , Michael Hammer , "fmousinh@cisco.com" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:09:44 -0000 X-List-Received-Date: Thu, 07 Nov 2013 17:09:44 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FC23A6Fp2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For businesses, the incorporation record contains the address, but that may= well be Delaware. The carrier generally knows the correct service address for landline (and t= he billing address for most cell calls), for obvious reasons. I agree that names are hard and should probably be left to the originator i= n many cases. It's much more helpful if the caller ID says "John Smith, ABC= Bank" or "Wire department", even if the carrier has no idea whether that's= really John Smith or that particular department calling. (It's helpful to = the callee because they may recognize John Smith as their financial advisor= , for example.) From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Bri= an Rosen Sent: Thursday, November 07, 2013 12:03 PM To: Henning Schulzrinne Cc: cnit@ietf.org; Richard Shockey; stir@ietf.org; Pierce.Gorman@sprint.com= ; Michael Hammer; fmousinh@cisco.com Subject: Re: [stir] draft-peterson-stir-threats-00.txt Right. I believe we can do this pretty easily. We probably could have a 1= 00 categories that would have similar authorities, and there are classifica= tions maintained by folks like Dun Bradstreet that can go even farther. What I think would be substantially harder is to validate an entire V/X/J c= ard. How is a validator to know your nickname is Fluffy? Name, phone numb= er and, if a business, a classification, yes, we can do that. Content of a= business card - very hard. Brian On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne > wrote: Yes, that's a problem, but as long as the number of categories is small, yo= u can build UIs that only render information that's appropriate to the decl= aration. For practical reasons, I think the number of useful categories is = likely going to be fairly limited: - Financial institution (FDIC and a few others) - Health care (each health care facility has a gov't number) - Charity (501c3, state registered) - Contractor (state-licensed) - Public safety organization (police, fire) - Lawyer (bar association) - Local, state and federal government (.gov in the US) I suspect that list encompasses a large fraction of the fraudulent (imperso= nation) calls. For all of the above, at least within a country, it's pretty= clear who can attest to the membership. Yes, this requires some UI work or= some server logic, but these categories and the organizations don't change= all that often - in most cases, the certifying entities have probably been= the same for the past 50+ years. I'm not as worried about figuring out whe= ther the beautician, mortician or florist is licensed and properly identifi= ed, although I'm sure we can all come up with potential fraud stories. From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 10:28 AM To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; richard@shockey.us Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, would you trust a certificate from the City of Reston, Virginia police = department? (Hint: you can find Reston on a map, but there is no City of Reston. The only police are Fairfax County.) My concern is that one you dilute or disperse authority, it becomes a free-= for-all again, and anybody's guess. Mike From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, November 07, 2013 10:00 AM To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey Cc: stir@ietf.org List; Fernando Mousinho (fmousinh);= cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt As a thought experiment, Kumiko Ono and I had published a draft http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 to allow third parties to validate property information. If the validating = party (e.g., a bank regulator) is willing to sign a certificate, similar in= spirit to the framed gold-leaf diplomas in your dentist's office or, more = lowly, to the health departments rating in a restaurant window, and it can = be tied to a phone number, this shouldn't be too hard. It's a bit harder if the certifying authority (regulator, Realtor board, lo= cal bar association, ...) is not involved. Henning From: cnit-bounces@ietf.org [mailto:cnit-boun= ces@ietf.org] On Behalf Of Gorman, P= ierce A [NTK] Sent: Thursday, November 07, 2013 9:54 AM To: Brian Rosen; Richard Shockey Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I'll admit I am not familiar with v/x/jcard encoding differences or the imp= lications of their use so I'll encourage educating me if it isn't too onero= us. I'm not sure what is the concern with a 3rd party providing "validation" th= ough. There are numerous examples of 3rd parties providing validation of i= nformation including NASDAQ, NYSE, Barron's, Moody's, and the federal reser= ve banking system to name a few. Pierce From: Brian Rosen [mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the= data, which it has very little basis to validate. It could get a 3rd part= y to do the validation, but then it's putting its reputation on the back of= some hired hand validator. If the responsibility is the end user/device, then the signature has no val= ue. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is= XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey > wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party an= d ultimately signed by the responsible entity. The carrier could provision= this for their mobile or hosted customers. Enterprises could do this them= selves. This also has advantages in Enterprise to Enterprise UC as well wh= ere the data is derived from the Enterprise "directory" and could facilitat= e end to end PPX to PBX communications especially in point to point video c= ommunications. There are certainly privacy and security issues to be addressed. The Push = vs Pull model. This really would be PII in the clear but then its done vol= untarily. There would have to be some work around restructuring the Header and adding= some parameters but it's underutilized right now and this Use Case is a pe= rfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that = ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: ;purpose=3Dicon, ;purpose=3Dinfo From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name= , but is something like "bank", which might have some sort of validation be= hind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey > wrote: I agree with Pierce here and respectfully disagree that STIR might eliminat= e the need for other forms of caller identification. Though your use case = of credit card validation is a useful one and you are right there are still= applications that use SS7 for things that have nothing to do with call set= up. I agree with you STIR may have more applications beyond the obvious one= s of realtime session validation. It's been my experience recently that there is a use case for something MOR= E in the identification of the session as it is presented to the called par= ty. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identi= fy themselves to the consumer before establishing a conversation is exactly= what this process is about. STIR is essential but it's a multi-faceted pr= oblem that may require multi-faceted solutions.. and enhanced CNAM + being = only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a = utility worker before I let them into my house to make repairs. I would wa= nt some validation that the call to me to reconfirm the appointments was in= fact from the utility in question. From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it... it may eliminate the need for other forms of caller i= dentification beyond what STIR will provide, depending on the specific use = case. For example, a credit card company may choose to rely entirely on STI= R before allowing a card to be unblocked by an IVR (and as I said earlier, = many companies do it today). In other use cases, the TN alone is not suffic= ient information - my health care provider will want to know which member o= f the family is calling. I agree that ANI is already broadly used to improve customer service today.= However, it is not usually deemed as a secure enough mechanism to validate= the caller (therefore this WG!), except if you are a large organization th= at can leverage things like SS7. STIR would make this type of validation av= ailable to a broader number of companies. Going on a tangent... perhaps this is out of scope, but there is not a lot = of discussion about called party hijacking. Couldn't a man-in-the-middle tr= y to answer calls on my behalf? If my bank is calling me, I want to make su= re it's really them before carrying a conversation, but wouldn't they want = the same? From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho >, "sti= r@ietf.org" > Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fra= ud however contact centers also use TN as a key to improve information avai= lable to call agents to reduce average time-per-call and increase capacity = of the call center. So I don't agree that STIR would "eliminate the need f= or caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more compan= ies are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for identificati= on. If I call from my home phone number, I'm informed that I don't need to = provide any further identification because my number is on file. Some (all?= ) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this ca= se, the "victim" is a business, unlike the other two scenarios we've listed= so far. Addressing this scenario would actually turn STIR into a feature, given it = would enable contact centers of all sizes to eliminate the need for caller = identification from known TNs. From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen >, "Peterson, J= on" > Cc: "stir@ietf.org" >, Richard Shockey >, "'DO= LLY, MARTIN C'" >, 'Robert Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the follo= wing sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is = simply the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the rendere= d information. No issues with leaving this as it's a valid point. Another= (increasing) motivation is to evade network and/or endpoint defenses that = may block based on CPN. So however it's worded, I think it's important to allow for both attack obj= ectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bo= unces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; '= DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" > > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draf= t: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried = in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in= the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> > > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [mailto:s= tir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_E6A16181E5FD2F46B962315BB05962D01FC23A6Fp2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For businesses, the incor= poration record contains the address, but that may well be Delaware.

 <= /p>

The carrier generally kno= ws the correct service address for landline (and the billing address for mo= st cell calls), for obvious reasons.

 <= /p>

I agree that names are ha= rd and should probably be left to the originator in many cases. It’s = much more helpful if the caller ID says “John Smith, ABC Bank” or “Wire department”, even if the carrier has no idea whether = that’s really John Smith or that particular department calling. (It&#= 8217;s helpful to the callee because they may recognize John Smith as their= financial advisor, for example.)

 <= /p>

From: stir-bou= nces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thursday, November 07, 2013 12:03 PM
To: Henning Schulzrinne
Cc: cnit@ietf.org; Richard Shockey; stir@ietf.org; Pierce.Gorman@spr= int.com; Michael Hammer; fmousinh@cisco.com
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

Right.  I believe we can do this pretty easily.=  We probably could have a 100 categories that would have similar auth= orities, and there are classifications maintained by folks like Dun Bradstr= eet that can go even farther.

 

What I think would be substantially harder is to val= idate an entire V/X/J card.  How is a validator to know your nickname = is Fluffy?  Name, phone number and, if a business, a classification, y= es, we can do that.  Content of a business card - very hard.

 

Brian

 

 

On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne <= Henning.Schulzrinne@fcc.gov<= /a>> wrote:



Yes, that’s a probl= em, but as long as the number of categories is small, you can build UIs tha= t only render information that’s appropriate to the declaration. For practical reasons, I think the number of useful categories is likely g= oing to be fairly limited:

-   = ;      =  Financial institution (FDIC and a few others)

-   = ;      =  Health care (each health care facility has a gov’t number)

-   = ;      =  Charity (501c3, state registered)

-   = ;      =  Contractor (state-licensed)

-   = ;      =  Public safety organization (police, fire)

-   = ;      =  Lawyer (bar association)

-   = ;      =  Local, state and federal government (.gov in the US)

 <= /p>

I suspect that list encom= passes a large fraction of the fraudulent (impersonation) calls. For all of= the above, at least within a country, it’s pretty clear who can attest to the membership. Yes, this requires some UI work or some = server logic, but these categories and the organizations don’t change= all that often – in most cases, the certifying entities have probabl= y been the same for the past 50+ years. I’m not as worried about figuring out whether the beautician, mortician or flo= rist is licensed and properly identified, although I’m sure we can al= l come up with potential fraud stories.

 <= /p>

From: Michael Hammer [mailto:michael.ham= mer@yaanatech.com]  Sent: Thursday, No= vember 07, 2013 10:28 AM
To: Henning Schulz= rinne; Pierce.Gorman@sprint.com; br@brian= rosen.net; richard@shockey.us
Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org
Subject: RE: [stir= ] draft-peterson-stir-threats-00.txt

 

So, would you trust a cer= tificate from the City of Reston, Virginia police department?

 <= /p>

(Hint:  you can find= Reston on a map, but there is no City of Reston. 

  The only poli= ce are Fairfax County.)

 <= /p>

My concern is that one yo= u dilute or disperse authority, it becomes a free-for-all again, and anybod= y’s guess.

 <= /p>

Mike

 <= /p>

 <= /p>

From: stir-bounces@ietf.o= rg [mailto:stir-bou= nces@ietf.org] On Behalf Of Henning Sc= hulzrinne
Sent: Thursday, No= vember 07, 2013 10:00 AM
To: 'Gorman, Pierc= e A [NTK]'; Brian Rosen; Richard Shockey
Cc: stir@ietf.org List; Fernando Mousinho (fm= ousinh); cnit@ietf.org
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

As a thought experiment, = Kumiko Ono and I had published a draft

 <= /p>

 <= /p>

to allow third parties to= validate property information. If the validating party (e.g., a bank regul= ator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist’s office or, more l= owly, to the health departments rating in a restaurant window, and it can b= e tied to a phone number, this shouldn’t be too hard.

 <= /p>

It’s a bit harder i= f the certifying authority (regulator, Realtor board, local bar association= , …) is not involved.

 <= /p>

Henning=

 <= /p>

From: cnit-bounces@ietf.o= rg [mailto= :cnit-bounces@ietf.org]&nb= sp;On Behalf Of Gorman, Pi= erce A [NTK]
Sent: Thursday, No= vember 07, 2013 9:54 AM
To: Brian Rosen; R= ichard Shockey
Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh)
Subject: Re: [cnit= ] [stir] draft-peterson-stir-threats-00.txt

 

I’ll admit I am not f= amiliar with v/x/jcard encoding differences or the implications of their us= e so I’ll encourage educating me if it isn’t too onerous.

 

I’m not sure what is = the concern with a 3rd&nbs= p;party providing “validation” though.  There are n= umerous examples of 3rd partie= s providing validation of information including NASDAQ, NYSE, Barron’= s, Moody’s, and the federal reserve banking system to name a few.

 

Pierce

 

From: Brian Rosen [m= ailto:br@brianrosen.net]&n= bsp;
Sent: November 06,= 2013 11:59 PM
To: Richard Shocke= y
Cc: Fernando Mousi= nho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

I think this would be a heavy lift.

 

If the responsible entity was a carrier, then it wou= ld have to validate the data, which it has very little basis to validate. &= nbsp;It could get a 3rd party to do the validation, but then it’s put= ting its reputation on the back of some hired hand validator.

 

If the responsibility is the end user/device, then t= he signature has no value.

 

I do not argue that Call-Info is suitable,  it = is.

 

I do question JCARD vs xCard, but that’s an en= coding detail.  All of SIP Is XML described by schema, not json.<= /o:p>

 

Brian

 

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shoc= key.us> wrote:

 

URI for a JCARD in the CA= LL INFO header provisioned by the calling party and ultimately signed by th= e responsible entity.  The carrier could provision this for their mobile or hosted customers.  Enterprises could do this them= selves.  This also has advantages in Enterprise to Enterprise UC as we= ll where the data is derived from the Enterprise “directory” an= d could facilitate end to end PPX to PBX communications especially in point to point video communications.

 <= /p>

There are certainly priva= cy and security issues to be addressed.  The Push vs Pull model. = This really would be PII in the clear but then its done voluntarily.

 <= /p>

There would have to be so= me work around restructuring the Header and adding some parameters but it&#= 8217;s underutilized right now and this Use Case is a perfectly appropriate use.

 <= /p>

 <= /p>

Obviously it would need t= o be signed but we don’t need to worry about that ..yet.<= /o:p>

 <= /p>

From 3261

 <= /p>

20.9 Call-Info

 <= /p>

   The Call-Inf= o header field provides additional information about the<= /p>

   caller or ca= llee, depending on whether it is found in a request or

   response.&nb= sp; The purpose of the URI is described by the "purpose"

   parameter.&n= bsp; The "icon" parameter designates an image suitable as an

   iconic repre= sentation of the caller or callee.  The "info" parameter

   describes th= e caller or callee in general, for example, through a web=

   page.  = The "card" parameter provides a business card, for example, in

   vCard [36] o= r LDIF [37] formats.  Additional tokens can be registered<= /o:p>

   using IANA a= nd the procedures in Section 27.

 <= /p>

   Use of the C= all-Info header field can pose a security risk.  If a

   callee fetch= es the URIs provided by a malicious caller, the callee

   may be at ri= sk for displaying inappropriate or offensive content,

   dangerous or= illegal content, and so on.  Therefore, it is

   RECOMMENDED = that a UA only render the information in the Call-Info

   header field= if it can verify the authenticity of the element that

   originated t= he header field and trusts that element.  This need not

   be the peer = UA; a proxy can insert this header field into requests.

 <= /p>

   Example:

 <= /p>

   Call-Info: &= lt;http://wwww.example.com/alice/photo.jpg> ;purpose=3D= icon,

     = <= http://www.example.com/alice/> ;purpose=3Dinfo

 <= /p>

From: Brian Rosen [m= ailto:br@brianrosen.net]&n= bsp;
Sent: Wednesday, N= ovember 06, 2013 3:41 PM
To: Richard Shocke= y
Cc: Fernando Mousi= nho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

We’ve considered adding some information that = is not number and is not name, but is something like “bank”, wh= ich might have some sort of validation behind it.

 

Is that along the lines you were thinking?

 

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shoc= key.us> wrote:

 

I agree with Pierce here = and respectfully disagree that STIR might eliminate the need for other form= s of caller identification.  Though your use case of credit card validation is a useful one and you are right there are still applicat= ions that use SS7 for things that have nothing to do with call setup. I agr= ee with you STIR may have more applications beyond the obvious ones of real= time session validation.

 <= /p>

It’s been my experi= ence recently that there is a use case for something MORE in the identifica= tion of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list.=

 <= /p>

_________________________= ______________________

cnit mailing list<= o:p>

cnit@ietf.org<= /o:p>

 <= /p>

But your use case of a ba= nk wanting to make sure they could properly identify themselves to the cons= umer before establishing a conversation is exactly what this process is about.  STIR is essential but it’s a multi-face= ted problem that may require multi-faceted solutions.. and enhanced CNAM &#= 43; being only one of them.   Its not unreasonable to discuss tho= se.

 <= /p>

The obviously analogy is = I would want to see some real identification of a utility worker before I l= et them into my house to make repairs.  I would want some validation that the call to me to reconfirm the appointments was in fact f= rom the utility in question.

 <= /p>

 <= /p>

 <= /p>

From: stir-bounces@iet= f.org [mailto:stir-= bounces@ietf.org] On Behalf Of Fernando M= ousinho (fmousinh)
Sent: Tuesday, Nov= ember 05, 2013 6:26 PM
To: Gorman, Pierce= A [NTK]; stir@ietf.org
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

Let me rephrase it… it may elimin= ate the need for other forms of caller identification beyond what STIR will= provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to= be unblocked by an IVR (and as I said earlier, many companies do it today)= . In other use cases, the TN alone is not sufficient information – my= health care provider will want to know which member of the family is calling.

 

I agree that ANI is already broadly use= d to improve customer service today. However, it is not usually deemed as a= secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things= like SS7. STIR would make this type of validation available to a broader n= umber of companies.

 

 

Going on a tangent… perhaps this = is out of scope, but there is not a lot of discussion about called party hi= jacking. Couldn’t a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it’s really th= em before carrying a conversation, but wouldn’t they want the same?&n= bsp;

 

 

From: <Gorman>, "Pierce A = [NTK]" <Pierce.Gorman@sprint.com>
Date: Tuesday, Nov= ember 5, 2013 at 6:05 PM
To: Fernando Mousi= nho <fmousinh@cisco.com>, "= stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir= ] draft-peterson-stir-threats-00.txt

 

I agree with your character= ization of businesses as victim of caller ID fraud however contact centers = also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the c= all center.  So I don’t agree that STIR would “eliminate t= he need for caller identification from known TNs.”<= /p>

 

But perhaps I misunderstood= your last sentence?

 

 

From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05,= 2013 4:34 PM
To: stir@ietf.org Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

I would suggest we add a new attack typ= e to section 3. More and more companies are using the caller ID for account= validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my h= ome phone number, I’m informed that I don’t need to provide any= further identification because my number is on file. Some (all?) companies= that implement this type of validation rely on SS7 today.

 

Ultimately, this is yet another variati= on of impersonation – but in this case, the “victim” is a= business, unlike the other two scenarios we’ve listed so far.=

 

Addressing this scenario would actually= turn STIR into a feature, given it would enable contact centers of all siz= es to eliminate the need for caller identification from known TNs.

 

 

 

From: Alex Bobotek <alex@bobotek.net= >
Date: Tuesday, Oct= ober 1, 2013 at 12:51 PM
To: Brian Rosen &l= t;br@bri= anrosen.net>, "Peterson, Jon" <jon.peterson@neust= ar.biz>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey <richard@shockey.us>, "'DOLLY, MARTIN C'" <md3135@att.com>, 'Robert Sparks' <= rjspa= rks@nostrum.com>
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

Jon,

 

Thanks for the response.  The inte= ntion in #1 below is to clarify the following sentence:

 

The primary attack vector is

   therefore one where the at= tacker contrives for the calling telephone

   number in signaling to be = a particular chosen number, one that the

   attacker does not have the= authority to call from, = in order for that

   number to be rendered o= n the terminating side. 

 

This might be misconstrued as indicatin= g that the objective of spoofing is simply the rendering of a spoofed numbe= r on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information.  = ;No issues with leaving this as it’s a valid point.  Another (in= creasing) motivation is to evade network and/or endpoint defenses that may = block based on CPN. 

 

So however it’s worded, I think i= t’s important to allow for both attack objectives of a spoofed presen= tation at the endpoint and in transit.   

 

Regards,

 

Alex

 

> -----Original Message-----<= o:p>

> Brian Rosen

> Sent: Tuesday, October 01, 2013 9:= 29 AM

> To: Peterson, Jon

> Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard

> Shockey

> Subject: Re: [stir] draft-peterson= -stir-threats-00.txt

> 

> Don't think there is much MESSAGE.=   MSRP is about all we see, and XMPP is

> more likely than that.=

> 

> Brian

> 

> On Oct 1, 2013, at 12:24 PM, "= ;Peterson, Jon" <jon.peterson@neustar.biz>

> wrote:

> 

> > Thanks for these notes, Alex.= Some responses below.

> >

> >> Here are several comments= that should feed into the IETF Peterson draft:

> >>

> >> *   Remove any = assumptions that the solution cannot be in-network

> [IMO,

> >> both endpoint and in-netw= ork solutions should be facilitated]

> >

> > Agreed that both in-band and = out-of-band solutions can usually be

> > implemented in either endpoin= ts or in intermediaries of various kinds.

> > If I see text that implies ot= herwise, I'll certainly change it.

> >

> >> *   Add a sessi= onless attack scenario.  A spam payload may be carried in<= /o:p>

> a

> >> SIP INVITE or MESSAGE, wh= ich might contain stock market advice even

> >> in a display name field.&= nbsp; These attacks do NOT require session

> establishment.

> >> More generally, we should= be mindful of the fact that SIP is used in

> >> telephony form more than = voice session setup.

> >

> > Probably if we were going to = include a sessionless attack scenario, it

> > would be with regular text me= ssages (whether carried on the PSTN over

> > TCAP or with some Internet pr= otocol, including MESSAGE) rather than

> > with an INVITE, which typical= ly wouldn't result in a payload being

> > immediately rendered to a use= r. More on this below with your suggested

> text.

> >

> >> Here's some suggested mar= kup:

> >>

> >>

> >> 1.    Repl= ace 2nd sentence of 2nd paragraph of 1.0 Introduction with:

> >>

> >> The primary attack vector= is

> >>  therefore one where= the attacker contrives for the calling telephone

> >> number in signaling to be= a particular chosen number that the

> >> attacker does not have th= e authority to call from.

> >

> > What you want here is to remo= ve the implication that the number will

> > be rendered on the terminatin= g side? While there are some attacks

> > where that isn't significant,= perhaps, I would say it is significant

> > in the primary attack vectors= that concern us.

> >

> >> 2.  Replace 3rd para= graph of 2.1 Endpoints with:

> >>

> >>     S= mart devices are generally based on computers with some degree<= /o:p>

> >> of programmability, the c= apacity to access the Internet, and

> >> capabilities of rendering= text, audio and/or images.  This includes

> >> smart phones, telephone a= pplications on desktop and laptop computers,

> >> IP private branch exchang= es, and so on.

> >

> > I can add the notion that sma= rt devices can render text, audio and/or

> > images as you suggest.=

> >

> >> 3.  Add to 3.3 Attac= k Scenarios:

> >>

> >>     &= nbsp; Impersonation, IP-Mobile Text Message

> >>

> >>     &= nbsp;  An attacker with an computer sends a high volume of SIP MESSAGE=

> >> spam message to IP-enable= d smart phones using randomized calling

> >> party numbers.

> >>

> >>     &= nbsp; Countermeasure: in-band authenticated identity

> >

> > Provided we're talking about = end-to-end SIP use of MESSAGE, agreed

> > that in-band would be the rig= ht countermeasure. I am curious though

> > whether practically speaking = there is enough use of MESSAGE in this

> > fashion that we're actually s= eeing high-volume spam over MESSAGE

> > today. Either way, no problem= having an attack scenario of this form in the

> document.

> >

> > Jon Peterson

> > Neustar, Inc.

> >

> >> Regards,

> >>

> >> Alex

> >>

> >>> -----Original Message= -----

> >>> Of Richard Shockey

> >>> Sent: Monday, Septemb= er 30, 2013 1:11 PM

> >>> To: 'DOLLY, MARTIN C'= ; 'Robert Sparks'

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] d= raft-peterson-stir-threats-00.txt

> >>>

> >>> +1

> >>>

> >>> -----Original Message= -----

> >>> Of DOLLY, MARTIN C

> >>> Sent: Monday, Septemb= er 30, 2013 12:58 PM

> >>> To: Robert Sparks

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] d= raft-peterson-stir-threats-00.txt

> >>>

> >>> Yes, ok

> >>>

> >>> Martin Dolly

> >>> Lead Member of Techni= cal Staff

> >>> Core Network & Go= v't/Regulatory Standards AT&T Labs - Network

> >>> Technology

> >>> +1-609-903-3360

> >>> md3135@att.com=

> >>>

> >>>> On Sep 30, 2013, = at 12:47 PM, "Robert Sparks"

> >>> wrote:

> >>>>=

> >>>>> On 9/26/13 3:= 42 PM, DOLLY, MARTIN C wrote:

> >>>>> With Hadriel = comments incorporated, it is a start

> >>>> Hi Martin -

> >>>>=

> >>>> Just to make sure= - I think you're referring to Hadriel's comments

> >>>> on the

> >>> problem statement doc= ument?

> >>>> I don't think Had= riel's commented directly on stir-threats yet.

> >>>>=

> >>>> In any case, we _= are_ talking about a starting place, not a

> >>>> finished

> >>> product.<= /o:p>

> >>>>=

> >>>> If there's no oth= er objection, I'd like to get Jon to submit the

> >>>> threats

> >>> document as a WG -00 = as soon as it's convenient.

> >>>>=

> >>>> RjS

> >>>>>

> >>>>> -----Original= Message-----

> >>>>> Behalf Of Rus= s Housley

> >>>>> Sent: Thursda= y, September 26, 2013 4:37 PM

> >>>>> To: IETF STIR= Mail List

> >>>>> Subject: Re: = [stir] draft-peterson-stir-threats-00.txt

> >>>>>

> >>>>> It has been s= ix days, I'd like to hear from more people about this

> >>> document.  Marti= n asked for an additional week, so I'm sure we will

> >>> hear from him soon.

> >>>>>

> >>>>> Russ

> >>>>>

> >>>>>

> >>>>>> On Sep 20= , 2013, at 5:23 PM, Russ Housley wrote:

> >>>>>>

> >>>>>>

> >>>>>> Should th= e working group adopt this I-D as the starting point for<= /p>

> >>>>>> the

> >>> STIR threat docuent?<= /span>

> >>>>>>

> >>>>>> Russ

> >>>>> _____________= __________________________________

> >>>>> stir mailing = list

> >>>>> stir@ietf.org

> >>>>=

> >>>> _________________= ______________________________

> >>>> stir mailing list=

> >>>> stir@ietf.org

> >>> _____________________= __________________________

> >>> stir mailing list

> >>> stir@ietf.org<= o:p>

> >>>

> >>> _____________________= __________________________

> >>> stir mailing list

> >>> stir@ietf.org<= o:p>

> >> _________________________= ______________________

> >> stir mailing list<= o:p>

> >

> > _____________________________= __________________

> > stir mailing list=

> 

> __________________________________= _____________

> stir mailing list

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

______________________________________= _________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir<= /o:p>

 

 

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

 

--_000_E6A16181E5FD2F46B962315BB05962D01FC23A6Fp2pxmb13fccnetw_-- From Pierce.Gorman@sprint.com Thu Nov 7 09:10:13 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE36E21E812B; Thu, 7 Nov 2013 09:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.061 X-Spam-Level: X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2XJ1VQI7Mwu; Thu, 7 Nov 2013 09:10:06 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 347B921E8134; Thu, 7 Nov 2013 09:09:41 -0800 (PST) Received: from mail220-db9-R.bigfish.com (10.174.16.244) by DB9EHSOBE018.bigfish.com (10.174.14.81) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 17:09:40 +0000 Received: from mail220-db9 (localhost [127.0.0.1]) by mail220-db9-R.bigfish.com (Postfix) with ESMTP id D0465801A9; Thu, 7 Nov 2013 17:09:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.25; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI X-SpamScore: -24 X-BigFish: VS-24(zz98dI9371I542I1fdcIzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2216h1155h) Received-SPF: pass (mail220-db9: domain of sprint.com designates 144.230.168.25 as permitted sender) client-ip=144.230.168.25; envelope-from=Pierce.Gorman@sprint.com; helo=plsasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail220-db9 (localhost.localdomain [127.0.0.1]) by mail220-db9 (MessageSwitch) id 13838441784542_25535; Thu, 7 Nov 2013 17:09:38 +0000 (UTC) Received: from DB9EHSMHS010.bigfish.com (unknown [10.174.16.248]) by mail220-db9.bigfish.com (Postfix) with ESMTP id F1BB620054; Thu, 7 Nov 2013 17:09:37 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by DB9EHSMHS010.bigfish.com (10.174.14.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 17:09:37 +0000 Received: from PLSWEH02.ad.sprint.com (plsweh02.corp.sprint.com [144.226.242.131]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA7H9ZGh011785 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2013 11:09:35 -0600 Received: from pdawm10a.ad.sprint.com ([169.254.2.186]) by PLSWEH02.ad.sprint.com ([144.226.242.131]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 11:09:35 -0600 From: "Gorman, Pierce A [NTK]" To: Henning Schulzrinne , 'Michael Hammer' , "br@brianrosen.net" , "richard@shockey.us" Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: Ac7b2+d8aE3RKG+HTk+hJde51INkfg== Date: Thu, 7 Nov 2013 17:09:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.229.76.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "stir@ietf.org" , "fmousinh@cisco.com" , "cnit@ietf.org" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:10:13 -0000 In addition to the examples of certifying organizations that Henning provid= ed, there are Barron's, Moody's, Dun & Bradstreet, Equifax, Experion, KPMG,= Deloitte-Touche, NYSE, NASDAQ, et cetera. Do we even need the categories, or do we just need 3rd parties to be expert= at vetting the authenticity of an originator? If it is the latter, I rema= in unconcerned about the business model aspects. Pierce -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: November 07, 2013 10:13 AM To: 'Michael Hammer'; Gorman, Pierce A [NTK]; br@brianrosen.net; richard@sh= ockey.us Cc: stir@ietf.org; cnit@ietf.org; fmousinh@cisco.com Subject: Re: [stir] draft-peterson-stir-threats-00.txt Yes, that's a problem, but as long as the number of categories is small, yo= u can build UIs that only render information that's appropriate to the decl= aration. For practical reasons, I think the number of useful categories is = likely going to be fairly limited: - Financial institution (FDIC and a few others) - Health care (each health care facility has a gov't number) - Charity (501c3, state registered) - Contractor (state-licensed) - Public safety organization (police, fire) - Lawyer (bar association) - Local, state and federal government (.gov in the US) I suspect that list encompasses a large fraction of the fraudulent (imperso= nation) calls. For all of the above, at least within a country, it's pretty= clear who can attest to the membership. Yes, this requires some UI work or= some server logic, but these categories and the organizations don't change= all that often - in most cases, the certifying entities have probably been= the same for the past 50+ years. I'm not as worried about figuring out whe= ther the beautician, mortician or florist is licensed and properly identifi= ed, although I'm sure we can all come up with potential fraud stories. From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 10:28 AM To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; richa= rd@shockey.us Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, would you trust a certificate from the City of Reston, Virginia police = department? (Hint: you can find Reston on a map, but there is no City of Reston. The only police are Fairfax County.) My concern is that one you dilute or disperse authority, it becomes a free-= for-all again, and anybody's guess. Mike From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, November 07, 2013 10:00 AM To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey Cc: stir@ietf.org List; Fernando Mousinho (fmousinh);= cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt As a thought experiment, Kumiko Ono and I had published a draft http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 to allow third parties to validate property information. If the validating = party (e.g., a bank regulator) is willing to sign a certificate, similar in= spirit to the framed gold-leaf diplomas in your dentist's office or, more = lowly, to the health departments rating in a restaurant window, and it can = be tied to a phone number, this shouldn't be too hard. It's a bit harder if the certifying authority (regulator, Realtor board, lo= cal bar association, ...) is not involved. Henning From: cnit-bounces@ietf.org [mailto:cnit-boun= ces@ietf.org] On Behalf Of Gorman, P= ierce A [NTK] Sent: Thursday, November 07, 2013 9:54 AM To: Brian Rosen; Richard Shockey Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I'll admit I am not familiar with v/x/jcard encoding differences or the imp= lications of their use so I'll encourage educating me if it isn't too onero= us. I'm not sure what is the concern with a 3rd party providing "validation" th= ough. There are numerous examples of 3rd parties providing validation of i= nformation including NASDAQ, NYSE, Barron's, Moody's, and the federal reser= ve banking system to name a few. Pierce From: Brian Rosen [mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the= data, which it has very little basis to validate. It could get a 3rd part= y to do the validation, but then it's putting its reputation on the back of= some hired hand validator. If the responsibility is the end user/device, then the signature has no val= ue. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is= XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey > wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party an= d ultimately signed by the responsible entity. The carrier could provision= this for their mobile or hosted customers. Enterprises could do this them= selves. This also has advantages in Enterprise to Enterprise UC as well wh= ere the data is derived from the Enterprise "directory" and could facilitat= e end to end PPX to PBX communications especially in point to point video c= ommunications. There are certainly privacy and security issues to be addressed. The Push = vs Pull model. This really would be PII in the clear but then its done vol= untarily. There would have to be some work around restructuring the Header and adding= some parameters but it's underutilized right now and this Use Case is a pe= rfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that = ..yet. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From br@brianrosen.net Thu Nov 7 09:10:52 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B787C21E80F5 for ; Thu, 7 Nov 2013 09:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG3j2h9dEVG2 for ; Thu, 7 Nov 2013 09:10:47 -0800 (PST) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0172C21E820D for ; Thu, 7 Nov 2013 09:10:24 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id 6so345193bkj.41 for ; Thu, 07 Nov 2013 09:10:24 -0800 (PST) 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:message-id:references:to; bh=AaSbwVtBu+HtUJAPazHAjM5GuaqDoba+M572lkQfo/E=; b=nFeXqTBRuTGICuxALZUMfMf3Y2DGI8HEI01OuXuVimcCFHdVHbVEs0tPJV43cU0jHI newk91Qht2fGCksO/TezkQqJ4Sv8NX6vrsgW7LAUhDDbTEosOBfCpYo6hRUh6G6sx0Pi KFjiHIxTEhA49Iirq95fNCY4C5Mam2uWPgcvgtvGHGchPobV7OKxj6JAraUoaZDQVpKB 2YQ97HsPfVdMKfvtv2AhB4SD7u6zhslxOGlvSnNP50huqKwk8jTBmMqlHrXyFgIwgtlL nrmRvMr117Z9ljQ3xM2g8Umo/NFVeM/ngvNTRMfkbDl0AUMfKB4e+9YrTSEQqw4cjymn aAWQ== X-Gm-Message-State: ALoCoQk5DziuHaoA1DE79k0dIF7L1xtAI0U/N3MQXKw/arOPHBmVZdpW5XerYG6uvZRlM5zXeAna X-Received: by 10.204.231.207 with SMTP id jr15mr53276bkb.66.1383844224144; Thu, 07 Nov 2013 09:10:24 -0800 (PST) Received: from dhcp-b7f9.meeting.ietf.org (dhcp-b7f9.meeting.ietf.org. [31.133.183.249]) by mx.google.com with ESMTPSA id l9sm3023886bkg.0.2013.11.07.09.10.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 09:10:22 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4AC161E6-68CE-4F8A-8156-0728D2677122" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: <00f401cedbcc$4a7e3700$df7aa500$@shockey.us> Date: Thu, 7 Nov 2013 09:10:14 -0800 Message-Id: <61DECB8D-A41A-41B8-B43C-DC11D3E2AE1B@brianrosen.net> References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> <00f401cedbcc$4a7e3700$df7aa500$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1816) Cc: "stir@ietf.org List" , "Gorman, Pierce A \[NTK\]" , "Fernando Mousinho \(fmousinh\)" , cnit@ietf.org Subject: Re: [stir] [cnit] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:10:52 -0000 --Apple-Mail=_4AC161E6-68CE-4F8A-8156-0728D2677122 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We=92re agreeing CNAM doesn=92t work, it lies, and we have to fix that. Billing relationships are useful, but only give you return routability = properties. Not very interesting, and billing addresses aren=92t often = what is wanted. Given various corporate relationships that are = tolerated by carriers, it would be trivial to make the billing name be = anything you wanted it to be and get service from most carriers. =20 I think it IS possible to validate a name, as long as you allow a = probability of that validation to be carried, because the techniques we = have aren=92t definitive. =20 See prior reply on the category idea, which I think is workable. FWIW, I am in favor of an in band solution for CNAM - display name of = From. You proposed a VCARD. I think that is unworkable. Name is hard enough. = We might be able to get an address. All the other fields in a VCARD = are pretty dicey. On Nov 7, 2013, at 7:16 AM, Richard Shockey wrote: > =20 > Like CNAM is so accurate today=85 ?? When certain companies get the = data from scanning phone books that are not even printed anymore? > =20 > The carrier has the billing relationship. As you well know that is = where the data comes from now but it is not granular.=20 > =20 > The carrier permits the customer to create the record(s). What are you = trying to validate? The Accuracy of the data? =85 In any event none of = that is our problem. We make the tools. Someone else worries about = policy. > =20 > You are making this way too complicated thus defeating the basic use = case. =20 > =20 > Well from time to time I=92ve discovered I=92m not a big fan of the = end to end principal. It just doesn=92t work for every use case. This = is a carrier service or in certain cases hosted. > =20 > Much like I=92m convinced the out of band solution in STIR is total = fantasy and like VIPR will almost never actually be used in practice. > =20 > As for encoding I mentioned JCARD since there seems to be a faction in = the IETF that is anti-XML > =20 > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf = Of Brian Rosen > Sent: Thursday, November 07, 2013 12:59 AM > To: Richard Shockey > Cc: stir@ietf.org List; Gorman, Pierce A [NTK]; cnit@ietf.org; = Fernando Mousinho (fmousinh) > Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt > =20 > I think this would be a heavy lift. > =20 > If the responsible entity was a carrier, then it would have to = validate the data, which it has very little basis to validate. It could = get a 3rd party to do the validation, but then it=92s putting its = reputation on the back of some hired hand validator. > =20 > If the responsibility is the end user/device, then the signature has = no value. > =20 > I do not argue that Call-Info is suitable, it is. > =20 > I do question JCARD vs xCard, but that=92s an encoding detail. All of = SIP Is XML described by schema, not json. > =20 > Brian > =20 > On Nov 6, 2013, at 1:10 PM, Richard Shockey = wrote: >=20 >=20 > URI for a JCARD in the CALL INFO header provisioned by the calling = party and ultimately signed by the responsible entity. The carrier = could provision this for their mobile or hosted customers. Enterprises = could do this themselves. This also has advantages in Enterprise to = Enterprise UC as well where the data is derived from the Enterprise = =93directory=94 and could facilitate end to end PPX to PBX = communications especially in point to point video communications. > =20 > There are certainly privacy and security issues to be addressed. The = Push vs Pull model. This really would be PII in the clear but then its = done voluntarily. > =20 > There would have to be some work around restructuring the Header and = adding some parameters but it=92s underutilized right now and this Use = Case is a perfectly appropriate use. > =20 > https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 > =20 > Obviously it would need to be signed but we don=92t need to worry = about that ..yet. > =20 > =46rom 3261 > =20 > 20.9 Call-Info > =20 > The Call-Info header field provides additional information about = the > caller or callee, depending on whether it is found in a request or > response. The purpose of the URI is described by the "purpose" > parameter. The "icon" parameter designates an image suitable as an > iconic representation of the caller or callee. The "info" = parameter > describes the caller or callee in general, for example, through a = web > page. The "card" parameter provides a business card, for example, = in > vCard [36] or LDIF [37] formats. Additional tokens can be = registered > using IANA and the procedures in Section 27. > =20 > Use of the Call-Info header field can pose a security risk. If a > callee fetches the URIs provided by a malicious caller, the callee > may be at risk for displaying inappropriate or offensive content, > dangerous or illegal content, and so on. Therefore, it is > RECOMMENDED that a UA only render the information in the Call-Info > header field if it can verify the authenticity of the element that > originated the header field and trusts that element. This need not > be the peer UA; a proxy can insert this header field into requests. > =20 > Example: > =20 > Call-Info: ;purpose=3Dicon,= > ;purpose=3Dinfo > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, November 06, 2013 3:41 PM > To: Richard Shockey > Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; = stir@ietf.org List > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > We=92ve considered adding some information that is not number and is = not name, but is something like =93bank=94, which might have some sort = of validation behind it. > =20 > Is that along the lines you were thinking? > =20 > Brian > On Nov 6, 2013, at 5:25 AM, Richard Shockey = wrote: >=20 >=20 >=20 > I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification. Though = your use case of credit card validation is a useful one and you are = right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session validation. > =20 > It=92s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list. > =20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > =20 > But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about. STIR is essential but it=92s a = multi-faceted problem that may require multi-faceted solutions.. and = enhanced CNAM + being only one of them. Its not unreasonable to = discuss those. > =20 > The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. I = would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in question. > =20 > =20 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Fernando Mousinho (fmousinh) > Sent: Tuesday, November 05, 2013 6:26 PM > To: Gorman, Pierce A [NTK]; stir@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Let me rephrase it=85 it may eliminate the need for other forms of = caller identification beyond what STIR will provide, depending on the = specific use case. For example, a credit card company may choose to rely = entirely on STIR before allowing a card to be unblocked by an IVR (and = as I said earlier, many companies do it today). In other use cases, the = TN alone is not sufficient information =96 my health care provider will = want to know which member of the family is calling. > =20 > I agree that ANI is already broadly used to improve customer service = today. However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of companies. > =20 > =20 > Going on a tangent=85 perhaps this is out of scope, but there is not a = lot of discussion about called party hijacking. Couldn=92t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it=92s really them before carrying a = conversation, but wouldn=92t they want the same?=20 > =20 > =20 > From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM > To: Fernando Mousinho , "stir@ietf.org" = > Subject: RE: [stir] draft-peterson-stir-threats-00.txt > =20 > I agree with your characterization of businesses as victim of caller = ID fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center. So I don=92t agree that STIR = would =93eliminate the need for caller identification from known TNs.=94 > =20 > But perhaps I misunderstood your last sentence? > =20 > =20 > From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com]=20 > Sent: November 05, 2013 4:34 PM > To: stir@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > I would suggest we add a new attack type to section 3. More and more = companies are using the caller ID for account validation. For example, = if I call my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I=92m informed that = I don=92t need to provide any further identification because my number = is on file. Some (all?) companies that implement this type of validation = rely on SS7 today. > =20 > Ultimately, this is yet another variation of impersonation =96 but in = this case, the =93victim=94 is a business, unlike the other two = scenarios we=92ve listed so far. > =20 > Addressing this scenario would actually turn STIR into a feature, = given it would enable contact centers of all sizes to eliminate the need = for caller identification from known TNs. > =20 > =20 > =20 > From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM > To: Brian Rosen , "Peterson, Jon" = > Cc: "stir@ietf.org" , Richard Shockey = , "'DOLLY, MARTIN C'" , 'Robert = Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Jon, > =20 > Thanks for the response. The intention in #1 below is to clarify the = following sentence: > =20 > The primary attack vector is > therefore one where the attacker contrives for the calling = telephone > number in signaling to be a particular chosen number, one that the > attacker does not have the authority to call from, in order for = that > number to be rendered on the terminating side.=20 > =20 > This might be misconstrued as indicating that the objective of = spoofing is simply the rendering of a spoofed number on the receiving = display, causing mistaken conclusions that defenses might be limited to = securing the rendered information. No issues with leaving this as it=92s = a valid point. Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on CPN.=20 > =20 > So however it=92s worded, I think it=92s important to allow for both = attack objectives of a spoofed presentation at the endpoint and in = transit. =20 > =20 > Regards, > =20 > Alex > =20 > > -----Original Message----- > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > > Brian Rosen > > Sent: Tuesday, October 01, 2013 9:29 AM > > To: Peterson, Jon > > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; = Richard > > Shockey > > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >=20 > > Don't think there is much MESSAGE. MSRP is about all we see, and = XMPP is > > more likely than that. > >=20 > > Brian > >=20 > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" = > > wrote: > >=20 > > > Thanks for these notes, Alex. Some responses below. > > > > > >> Here are several comments that should feed into the IETF Peterson = draft: > > >> > > >> * Remove any assumptions that the solution cannot be in-network > > [IMO, > > >> both endpoint and in-network solutions should be facilitated] > > > > > > Agreed that both in-band and out-of-band solutions can usually be > > > implemented in either endpoints or in intermediaries of various = kinds. > > > If I see text that implies otherwise, I'll certainly change it. > > > > > >> * Add a sessionless attack scenario. A spam payload may be = carried in > > a > > >> SIP INVITE or MESSAGE, which might contain stock market advice = even > > >> in a display name field. These attacks do NOT require session > > establishment. > > >> More generally, we should be mindful of the fact that SIP is used = in > > >> telephony form more than voice session setup. > > > > > > Probably if we were going to include a sessionless attack = scenario, it > > > would be with regular text messages (whether carried on the PSTN = over > > > TCAP or with some Internet protocol, including MESSAGE) rather = than > > > with an INVITE, which typically wouldn't result in a payload being > > > immediately rendered to a user. More on this below with your = suggested > > text. > > > > > >> Here's some suggested markup: > > >> > > >> > > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction = with: > > >> > > >> The primary attack vector is > > >> therefore one where the attacker contrives for the calling = telephone > > >> number in signaling to be a particular chosen number that the > > >> attacker does not have the authority to call from. > > > > > > What you want here is to remove the implication that the number = will > > > be rendered on the terminating side? While there are some attacks > > > where that isn't significant, perhaps, I would say it is = significant > > > in the primary attack vectors that concern us. > > > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > > >> > > >> Smart devices are generally based on computers with some = degree > > >> of programmability, the capacity to access the Internet, and > > >> capabilities of rendering text, audio and/or images. This = includes > > >> smart phones, telephone applications on desktop and laptop = computers, > > >> IP private branch exchanges, and so on. > > > > > > I can add the notion that smart devices can render text, audio = and/or > > > images as you suggest. > > > > > >> 3. Add to 3.3 Attack Scenarios: > > >> > > >> Impersonation, IP-Mobile Text Message > > >> > > >> An attacker with an computer sends a high volume of SIP = MESSAGE > > >> spam message to IP-enabled smart phones using randomized calling > > >> party numbers. > > >> > > >> Countermeasure: in-band authenticated identity > > > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > > that in-band would be the right countermeasure. I am curious = though > > > whether practically speaking there is enough use of MESSAGE in = this > > > fashion that we're actually seeing high-volume spam over MESSAGE > > > today. Either way, no problem having an attack scenario of this = form in the > > document. > > > > > > Jon Peterson > > > Neustar, Inc. > > > > > >> Regards, > > >> > > >> Alex > > >> > > >>> -----Original Message----- > > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf > > >>> Of Richard Shockey > > >>> Sent: Monday, September 30, 2013 1:11 PM > > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > > >>> Cc: stir@ietf.org > > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>> > > >>> +1 > > >>> > > >>> -----Original Message----- > > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf > > >>> Of DOLLY, MARTIN C > > >>> Sent: Monday, September 30, 2013 12:58 PM > > >>> To: Robert Sparks > > >>> Cc: stir@ietf.org > > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>> > > >>> Yes, ok > > >>> > > >>> Martin Dolly > > >>> Lead Member of Technical Staff > > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > > >>> Technology > > >>> +1-609-903-3360 > > >>> md3135@att.com > > >>> > > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > > >>>> > > >>> wrote: > > >>>> > > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > > >>>>> With Hadriel comments incorporated, it is a start > > >>>> Hi Martin - > > >>>> > > >>>> Just to make sure - I think you're referring to Hadriel's = comments > > >>>> on the > > >>> problem statement document? > > >>>> I don't think Hadriel's commented directly on stir-threats yet. > > >>>> > > >>>> In any case, we _are_ talking about a starting place, not a > > >>>> finished > > >>> product. > > >>>> > > >>>> If there's no other objection, I'd like to get Jon to submit = the > > >>>> threats > > >>> document as a WG -00 as soon as it's convenient. > > >>>> > > >>>> RjS > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On > > >>>>> Behalf Of Russ Housley > > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > > >>>>> To: IETF STIR Mail List > > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>>>> > > >>>>> It has been six days, I'd like to hear from more people about = this > > >>> document. Martin asked for an additional week, so I'm sure we = will > > >>> hear from him soon. > > >>>>> > > >>>>> Russ > > >>>>> > > >>>>> > > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > > >>>>>> > > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > > >>>>>> > > >>>>>> Should the working group adopt this I-D as the starting point = for > > >>>>>> the > > >>> STIR threat docuent? > > >>>>>> > > >>>>>> Russ > > >>>>> _______________________________________________ > > >>>>> 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 > > >>> _______________________________________________ > > >>> 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 > > >> _______________________________________________ > > >> 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 > >=20 > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > =20 >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_4AC161E6-68CE-4F8A-8156-0728D2677122 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 We=92re = agreeing CNAM doesn=92t work, it lies, and we have to fix = that.

Billing relationships are useful, but only give = you return routability properties.  Not very interesting, and = billing addresses aren=92t often what is wanted.  Given various = corporate relationships that are tolerated by carriers, it would be = trivial to make the billing name be anything you wanted it to be and get = service from most carriers.  

I think it = IS possible to validate a name, as long as you allow a probability of = that validation to be carried, because the techniques we have aren=92t = definitive.  

See prior reply on the = category idea, which I think is workable.

FWIW, = I am in favor of an in band solution for CNAM - display name of = From.

You proposed a VCARD.  I think that = is unworkable.  Name is hard enough.  We might be able to get = an address.  All the other fields in a VCARD are pretty = dicey.


On Nov 7, = 2013, at 7:16 AM, Richard Shockey <richard@shockey.us> = wrote:

 
Like CNAM is so accurate today=85 ??  When = certain companies get the data from scanning phone books that are not = even printed anymore?
 
The carrier has the = billing relationship. As you well know that is where the data comes from = now but it is not granular. 
 
The carrier permits the = customer to create the record(s). What are you trying to validate? The = Accuracy of the data?  =85 In any event none of that is our = problem.   We make the tools. Someone else worries about = policy.
 
You are making this way too complicated thus = defeating the basic use case.  
 
Well from time to time = I=92ve discovered I=92m not a big fan of the end to end principal.  = It just doesn=92t work for every use case.  This is a carrier = service or in certain cases hosted.
 
Much like I=92m convinced = the out of band solution in STIR is total fantasy and like VIPR will = almost never actually be used in practice.
 
As for encoding I = mentioned JCARD since there seems to be a faction in the IETF that is = anti-XML
 
From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Thursday, November 07, 2013 = 12:59 AM
To: Richard = Shockey
Cc: stir@ietf.org List; Gorman, Pierce A = [NTK]; cnit@ietf.org; Fernando = Mousinho (fmousinh)
Subject: Re: [cnit] [stir] = draft-peterson-stir-threats-00.txt
 
I = think this would be a heavy lift.
 
If the responsible entity was a carrier, then it = would have to validate the data, which it has very little basis to = validate.  It could get a 3rd party to do the validation, but then = it=92s putting its reputation on the back of some hired hand = validator.
 
If = the responsibility is the end user/device, then the signature has no = value.
 
I do = not argue that Call-Info is suitable,  it = is.
 
I do = question JCARD vs xCard, but that=92s an encoding detail.  All of = SIP Is XML described by schema, not = json.
 
Brian
 
On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> = wrote:


URI = for a JCARD in the CALL INFO header provisioned by the calling party and = ultimately signed by the responsible entity.  The carrier could = provision this for their mobile or hosted customers.  Enterprises = could do this themselves.  This also has advantages in Enterprise = to Enterprise UC as well where the data is derived from the Enterprise = =93directory=94 and could facilitate end to end PPX to PBX = communications especially in point to point video = communications.
 
There are certainly privacy and = security issues to be addressed.  The Push vs Pull model.  = This really would be PII in the clear but then its done = voluntarily.
 
There would have to be some work = around restructuring the Header and adding some parameters but it=92s = underutilized right now and this Use Case is a perfectly appropriate = use.
 
 
Obviously it would need to be signed but we don=92t = need to worry about that ..yet.
 
=46rom 3261
 
20.9 Call-Info
 
   The Call-Info header field provides = additional information about the
   caller or = callee, depending on whether it is found in a request = or
   response.  The purpose of the URI = is described by the "purpose"
   parameter.  The = "icon" parameter designates an image suitable as = an
   iconic representation of the caller or = callee.  The "info" parameter
   describes = the caller or callee in general, for example, through a = web
   page.  The "card" parameter = provides a business card, for example, in
   vCard [36] = or LDIF [37] formats.  Additional tokens can be = registered
   using IANA and the procedures in Section = 27.
 
   Use of the Call-Info = header field can pose a security risk.  If = a
   callee fetches the URIs provided by a = malicious caller, the callee
   may be at risk for = displaying inappropriate or offensive = content,
   dangerous or illegal content, and so = on.  Therefore, it is
   RECOMMENDED that a UA = only render the information in the Call-Info
   header field = if it can verify the authenticity of the element = that
   originated the header field and trusts = that element.  This need not
   be the peer = UA; a proxy can insert this header field into = requests.
 
   = Example:
 
   Call-Info: <http://wwww.example.com/alice/photo.jpg> = ;purpose=3Dicon,
     <http://www.example.com/alice/> = ;purpose=3Dinfo
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Wednesday, November 06, = 2013 3:41 PM
To: Richard = Shockey
Cc: Fernando Mousinho = (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
We=92ve= considered adding some information that is not number and is not name, = but is something like =93bank=94, which might have some sort of = validation behind it.
 
Is = that along the lines you were thinking?
 
Brian
On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:



I agree with Pierce here and respectfully disagree = that STIR might eliminate the need for other forms of caller = identification.  Though your use case of credit card validation is = a useful one and you are right there are still applications that use SS7 = for things that have nothing to do with call setup. I agree with you = STIR may have more applications beyond the obvious ones of realtime = session validation.
 
It=92s been my experience recently = that there is a use case for something MORE in the identification of the = session as it is presented to the called party. This is the CNAM + idea = we are kicking around on the CNIT = list.
 
_______________________________________________
cnit mailing = list
 
But your use case of a bank = wanting to make sure they could properly identify themselves to the = consumer before establishing a conversation is exactly what this process = is about.  STIR is essential but it=92s a multi-faceted problem = that may require multi-faceted solutions.. and enhanced CNAM + being = only one of them.   Its not unreasonable to discuss = those.
 
The obviously analogy is = I would want to see some real identification of a utility worker before = I let them into my house to make repairs.  I would want some = validation that the call to me to reconfirm the appointments was in fact = from the utility in question.
 
 
 
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A = [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
Let me rephrase it=85 it may eliminate the need = for other forms of caller identification beyond what STIR will provide, = depending on the specific use case. For example, a credit card company = may choose to rely entirely on STIR before allowing a card to be = unblocked by an IVR (and as I said earlier, many companies do it today). = In other use cases, the TN alone is not sufficient information =96 my = health care provider will want to know which member of the family is = calling.
 
I agree that ANI is already broadly used to = improve customer service today. However, it is not usually deemed as a = secure enough mechanism to validate the caller (therefore this WG!), = except if you are a large organization that can leverage things like = SS7. STIR would make this type of validation available to a broader = number of companies.
 
 
Going on a tangent=85 perhaps this is out of = scope, but there is not a lot of discussion about called party = hijacking. Couldn=92t a man-in-the-middle try to answer calls on my = behalf? If my bank is calling me, I want to make sure it=92s really them = before carrying a conversation, but wouldn=92t they want the = same? 
 
 
From: <Gorman>, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Date: Tuesday, November 5, = 2013 at 6:05 PM
To: Fernando Mousinho = <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt
 
I agree with your characterization = of businesses as victim of caller ID fraud however contact centers also = use TN as a key to improve information available to call agents to = reduce average time-per-call and increase capacity of the call = center.  So I don=92t agree that STIR would =93eliminate the need = for caller identification from known = TNs.=94
 
But perhaps I misunderstood your last = sentence?
 
 
From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
I would suggest we add a new attack type to = section 3. More and more companies are using the caller ID for account = validation. For example, if I call my credit card provider from my = office number, they ask me for identification. If I call from my home = phone number, I=92m informed that I don=92t need to provide any further = identification because my number is on file. Some (all?) companies that = implement this type of validation rely on SS7 = today.
 
Ultimately, this is yet another variation of = impersonation =96 but in this case, the =93victim=94 is a business, = unlike the other two scenarios we=92ve listed so = far.
 
Addressing this scenario would actually turn STIR = into a feature, given it would enable contact centers of all sizes to = eliminate the need for caller identification from known = TNs.
 
 
 
From: Alex = Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, = 2013 at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, MARTIN C'" <md3135@att.com>, 'Robert Sparks' <rjsparks@nostrum.com>
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
Jon,
 
Thanks for the response.  The intention in #1 = below is to clarify the following = sentence:
 
The primary attack vector = is
   therefore one where the attacker contrives for = the calling telephone
   number in signaling to be a = particular chosen number, one that = the
   attacker does not have the authority to call = from, in order for = that
   number to be rendered on the terminating = side. 
 
This might be misconstrued as indicating that the = objective of spoofing is simply the rendering of a spoofed number on the = receiving display, causing mistaken conclusions that defenses might be = limited to securing the rendered information.  No issues with = leaving this as it=92s a valid point.  Another (increasing) = motivation is to evade network and/or endpoint defenses that may block = based on CPN. 
 
So however it=92s worded, I think it=92s important = to allow for both attack objectives of a spoofed presentation at the = endpoint and in transit.  =  
 
Regards,
 
Alex
 
> -----Original = Message-----
> Brian = Rosen
> Sent: = Tuesday, October 01, 2013 9:29 AM
> To: Peterson, = Jon
> = Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, = MARTIN C'; Richard
> Shockey
> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> 
> Don't think there is much MESSAGE.  MSRP = is about all we see, and XMPP is
> more likely than = that.
> 
> Brian
> 
> On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" = <jon.peterson@neustar.biz>
> = wrote:
> 
> > Thanks for these notes, Alex. Some = responses below.
> >
> >> Here are several comments that = should feed into the IETF Peterson = draft:
> = >>
> = >> *   Remove any assumptions that the solution cannot = be in-network
> [IMO,
> >> both endpoint and in-network = solutions should be facilitated]
> >
> > Agreed that both in-band and out-of-band = solutions can usually be
> > implemented in either endpoints or in = intermediaries of various kinds.
> > If I see text that implies otherwise, = I'll certainly change it.
> >
> >> *   Add a sessionless = attack scenario.  A spam payload may be carried = in
> = a
> = >> SIP INVITE or MESSAGE, which might contain stock market advice = even
> = >> in a display name field.  These attacks do NOT require = session
> = establishment.
> >> More generally, we should be mindful of the = fact that SIP is used in
> >> telephony form more than voice = session setup.
> >
> > Probably if we were going to include a = sessionless attack scenario, it
> > would be with regular text messages = (whether carried on the PSTN over
> > TCAP or with some Internet protocol, = including MESSAGE) rather than
> > with an INVITE, which typically wouldn't = result in a payload being
> > immediately rendered to a user. More on = this below with your suggested
> text.
> >
> >> Here's some suggested = markup:
> = >>
> = >>
> = >> 1.    Replace 2nd sentence of 2nd paragraph of = 1.0 Introduction with:
> = >>
> = >> The primary attack vector = is
> = >>  therefore one where the attacker contrives for the = calling telephone
> >> number in signaling to be a particular chosen = number that the
> >> attacker does not have the authority to call = from.
> = >
> > = What you want here is to remove the implication that the number = will
> > = be rendered on the terminating side? While there are some = attacks
> > = where that isn't significant, perhaps, I would say it is = significant
> > in the primary attack vectors that concern = us.
> = >
> = >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:
> = >>
> = >>     Smart devices are generally based on = computers with some degree
> >> of programmability, the capacity to = access the Internet, and
> >> capabilities of rendering text, = audio and/or images.  This = includes
> = >> smart phones, telephone applications on desktop and laptop = computers,
> >> IP private branch exchanges, and so = on.
> = >
> > I = can add the notion that smart devices can render text, audio = and/or
> > = images as you suggest.
> >
> >> 3.  Add to 3.3 Attack = Scenarios:
> >>
> >>       = Impersonation, IP-Mobile Text = Message
> = >>
> = >>        An attacker with an = computer sends a high volume of SIP = MESSAGE
> = >> spam message to IP-enabled smart phones using randomized = calling
> = >> party numbers.
> = >>
> = >>       Countermeasure: in-band = authenticated identity
> >
> > Provided we're talking about end-to-end = SIP use of MESSAGE, agreed
> > that in-band would be the right = countermeasure. I am curious = though
> > = whether practically speaking there is enough use of MESSAGE in = this
> > = fashion that we're actually seeing high-volume spam over = MESSAGE
> > = today. Either way, no problem having an attack scenario of this form in = the
> = document.
> >
> > Jon = Peterson
> > = Neustar, Inc.
> >
> >> = Regards,
> = >>
> = >> Alex
> >>
> >>> -----Original = Message-----
> = >>> Of Richard Shockey
> >>> Sent: Monday, September 30, 2013 = 1:11 PM
> = >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'
> = >>> Cc: stir@ietf.org
> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> = >>>
> >>> +1
> = >>>
> >>> -----Original = Message-----
> = >>> Of DOLLY, MARTIN C
> >>> Sent: Monday, September 30, 2013 = 12:58 PM
> = >>> To: Robert Sparks
> >>> Cc: stir@ietf.org
> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> = >>>
> >>> Yes, = ok
> = >>>
> >>> Martin = Dolly
> = >>> Lead Member of Technical = Staff
> = >>> Core Network & Gov't/Regulatory Standards AT&T Labs = - Network
> >>> = Technology
> >>> = +1-609-903-3360
> = >>>
> >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"
> >>> = wrote:
> = >>>>
> >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN = C wrote:
> = >>>>> With Hadriel comments incorporated, it is a = start
> = >>>> Hi Martin -
> = >>>>
> >>>> Just to make sure - I think you're = referring to Hadriel's comments
> >>>> on = the
> = >>> problem statement = document?
> >>>> I don't think Hadriel's commented = directly on stir-threats yet.
> = >>>>
> >>>> In any case, we _are_ talking about a = starting place, not a
> >>>> = finished
> = >>> product.
> = >>>>
> >>>> If there's no other objection, I'd = like to get Jon to submit the
> >>>> = threats
> = >>> document as a WG -00 as soon as it's = convenient.
> = >>>>
> >>>> = RjS
> = >>>>>
> >>>>> -----Original = Message-----
> = >>>>> Behalf Of Russ = Housley
> = >>>>> Sent: Thursday, September 26, 2013 4:37 = PM
> = >>>>> To: IETF STIR Mail = List
> = >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> = >>>>>
> >>>>> It has been six days, = I'd like to hear from more people about = this
> = >>> document.  Martin asked for an additional week, so I'm = sure we will
> >>> hear from him = soon.
> = >>>>>
> >>>>> = Russ
> = >>>>>
> = >>>>>
> >>>>>> On Sep 20, 2013, at = 5:23 PM, Russ Housley wrote:
> = >>>>>>
> = >>>>
> >>>> = _______________________________________________
> >>>> stir mailing = list
> = >>>> stir@ietf.org
> >>> = _______________________________________________
> >>> stir mailing = list
> = >>> stir@ietf.org
> = >>>
> >>> = _______________________________________________
> >>> stir mailing = list
> = >>> stir@ietf.org
> >> = _______________________________________________
> >> stir mailing = list
> = >
> > = _______________________________________________
> > stir mailing = list
> 
> = _______________________________________________
> stir mailing = list
 

This e-mail may contain Sprint proprietary = information intended for the sole use of the recipient(s). Any use by = others is prohibited. If you are not the intended recipient, please = contact the sender and delete all copies of the = message.
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir
= --Apple-Mail=_4AC161E6-68CE-4F8A-8156-0728D2677122-- From michael.hammer@yaanatech.com Thu Nov 7 09:11:05 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BBA21E812B; Thu, 7 Nov 2013 09:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvMadk4jHWmd; Thu, 7 Nov 2013 09:10:52 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id DBA0C21E821A; Thu, 7 Nov 2013 09:10:26 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 7 Nov 2013 09:10:26 -0800 From: Michael Hammer To: "br@brianrosen.net" , "Henning.Schulzrinne@fcc.gov" Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQIJuyR31NLy1lMhJkGcqWArv1sc1QINOqbRAr/2giEC0l///wF434JzmR/4cmCAAD+vQIABiMQAgAABSwCAABcWAIA3YVcAgAAInoCAAAXVgIAA6nqAgAB5wgCAAAhegIAAk5aAgACVVgCAAAHaAP//gKwwgACTmgCAAA4fAP//exIA Date: Thu, 7 Nov 2013 17:10:24 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEF7E71@sc9-ex2k10mb1.corp.yaanatech.com> References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7D86@sc9-ex2k10mb1.corp.yaanatech.com> <6A94C6CF-69F6-42D9-9A6C-32361A0A4755@brianrosen.net> In-Reply-To: <6A94C6CF-69F6-42D9-9A6C-32361A0A4755@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.142] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0085_01CEDBB2.56084FD0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "Pierce.Gorman@sprint.com" , "fmousinh@cisco.com" , "cnit@ietf.org" , "richard@shockey.us" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:11:05 -0000 ------=_NextPart_000_0085_01CEDBB2.56084FD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0086_01CEDBB2.56084FD0" ------=_NextPart_001_0086_01CEDBB2.56084FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So, how does the average user know who is an authority? (Note, we are not designing for IETF geniuses here.) Is some well-known central authority going to certify all of these? Are each of these going to cross-certify all the others? (federated model) We need to always answer that fundamental user question: Why should I TRUST this information? Mike From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, November 07, 2013 12:03 PM To: Henning Schulzrinne Cc: Michael Hammer; Pierce.Gorman@sprint.com; Richard Shockey; stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Right. I believe we can do this pretty easily. We probably could have a 100 categories that would have similar authorities, and there are classifications maintained by folks like Dun Bradstreet that can go even farther. What I think would be substantially harder is to validate an entire V/X/J card. How is a validator to know your nickname is Fluffy? Name, phone number and, if a business, a classification, yes, we can do that. Content of a business card - very hard. Brian On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne wrote: Yes, that's a problem, but as long as the number of categories is small, you can build UIs that only render information that's appropriate to the declaration. For practical reasons, I think the number of useful categories is likely going to be fairly limited: - Financial institution (FDIC and a few others) - Health care (each health care facility has a gov't number) - Charity (501c3, state registered) - Contractor (state-licensed) - Public safety organization (police, fire) - Lawyer (bar association) - Local, state and federal government (.gov in the US) I suspect that list encompasses a large fraction of the fraudulent (impersonation) calls. For all of the above, at least within a country, it's pretty clear who can attest to the membership. Yes, this requires some UI work or some server logic, but these categories and the organizations don't change all that often - in most cases, the certifying entities have probably been the same for the past 50+ years. I'm not as worried about figuring out whether the beautician, mortician or florist is licensed and properly identified, although I'm sure we can all come up with potential fraud stories. From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 10:28 AM To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; richard@shockey.us Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, would you trust a certificate from the City of Reston, Virginia police department? (Hint: you can find Reston on a map, but there is no City of Reston. The only police are Fairfax County.) My concern is that one you dilute or disperse authority, it becomes a free-for-all again, and anybody's guess. Mike From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, November 07, 2013 10:00 AM To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey Cc: stir@ietf.org List; Fernando Mousinho (fmousinh); cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt As a thought experiment, Kumiko Ono and I had published a draft http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 to allow third parties to validate property information. If the validating party (e.g., a bank regulator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist's office or, more lowly, to the health departments rating in a restaurant window, and it can be tied to a phone number, this shouldn't be too hard. It's a bit harder if the certifying authority (regulator, Realtor board, local bar association, .) is not involved. Henning From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gorman, Pierce A [NTK] Sent: Thursday, November 07, 2013 9:54 AM To: Brian Rosen; Richard Shockey Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I'll admit I am not familiar with v/x/jcard encoding differences or the implications of their use so I'll encourage educating me if it isn't too onerous. I'm not sure what is the concern with a 3rd party providing "validation" though. There are numerous examples of 3rd parties providing validation of information including NASDAQ, NYSE, Barron's, Moody's, and the federal reserve banking system to name a few. Pierce From: Brian Rosen [ mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the data, which it has very little basis to validate. It could get a 3rd party to do the validation, but then it's putting its reputation on the back of some hired hand validator. If the responsibility is the end user/device, then the signature has no value. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey < richard@shockey.us> wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party and ultimately signed by the responsible entity. The carrier could provision this for their mobile or hosted customers. Enterprises could do this themselves. This also has advantages in Enterprise to Enterprise UC as well where the data is derived from the Enterprise "directory" and could facilitate end to end PPX to PBX communications especially in point to point video communications. There are certainly privacy and security issues to be addressed. The Push vs Pull model. This really would be PII in the clear but then its done voluntarily. There would have to be some work around restructuring the Header and adding some parameters but it's underutilized right now and this Use Case is a perfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: < http://wwww.example.com/alice/photo.jpg> ;purpose=icon, < http://www.example.com/alice/> ;purpose=info From: Brian Rosen [ mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name, but is something like "bank", which might have some sort of validation behind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey < richard@shockey.us> wrote: I agree with Pierce here and respectfully disagree that STIR might eliminate the need for other forms of caller identification. Though your use case of credit card validation is a useful one and you are right there are still applications that use SS7 for things that have nothing to do with call setup. I agree with you STIR may have more applications beyond the obvious ones of realtime session validation. It's been my experience recently that there is a use case for something MORE in the identification of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identify themselves to the consumer before establishing a conversation is exactly what this process is about. STIR is essential but it's a multi-faceted problem that may require multi-faceted solutions.. and enhanced CNAM + being only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a utility worker before I let them into my house to make repairs. I would want some validation that the call to me to reconfirm the appointments was in fact from the utility in question. From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it. it may eliminate the need for other forms of caller identification beyond what STIR will provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to be unblocked by an IVR (and as I said earlier, many companies do it today). In other use cases, the TN alone is not sufficient information - my health care provider will want to know which member of the family is calling. I agree that ANI is already broadly used to improve customer service today. However, it is not usually deemed as a secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things like SS7. STIR would make this type of validation available to a broader number of companies. Going on a tangent. perhaps this is out of scope, but there is not a lot of discussion about called party hijacking. Couldn't a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it's really them before carrying a conversation, but wouldn't they want the same? From: , "Pierce A [NTK]" < Pierce.Gorman@sprint.com> Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho < fmousinh@cisco.com>, " stir@ietf.org" < stir@ietf.org> Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fraud however contact centers also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the call center. So I don't agree that STIR would "eliminate the need for caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [ mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more companies are using the caller ID for account validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my home phone number, I'm informed that I don't need to provide any further identification because my number is on file. Some (all?) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this case, the "victim" is a business, unlike the other two scenarios we've listed so far. Addressing this scenario would actually turn STIR into a feature, given it would enable contact centers of all sizes to eliminate the need for caller identification from known TNs. From: Alex Bobotek < alex@bobotek.net> Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen < br@brianrosen.net>, "Peterson, Jon" < jon.peterson@neustar.biz> Cc: " stir@ietf.org" < stir@ietf.org>, Richard Shockey < richard@shockey.us>, "'DOLLY, MARTIN C'" < md3135@att.com>, 'Robert Sparks' < rjsparks@nostrum.com> Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the following sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is simply the rendering of a spoofed number on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information. No issues with leaving this as it's a valid point. Another (increasing) motivation is to evade network and/or endpoint defenses that may block based on CPN. So however it's worded, I think it's important to allow for both attack objectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" < jon.peterson@neustar.biz> > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draft: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> < rjsparks@nostrum.com> > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. ------=_NextPart_001_0086_01CEDBB2.56084FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So, how does the average user know who is an = authority?

(Note, we are not designing for IETF geniuses = here.)

 

Is some well-known central authority going to certify all of = these?

Are each of these going to cross-certify all the others? (federated = model)

 

We need to always answer that fundamental user = question:

Why should I TRUST this information?

 

Mike

 

 

From:= = Brian Rosen [mailto:br@brianrosen.net]
Sent: Thursday, = November 07, 2013 12:03 PM
To: Henning = Schulzrinne
Cc: Michael Hammer; Pierce.Gorman@sprint.com; = Richard Shockey; stir@ietf.org; fmousinh@cisco.com; = cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

Right. =  I believe we can do this pretty easily.  We probably could = have a 100 categories that would have similar authorities, and there are = classifications maintained by folks like Dun Bradstreet that can go even = farther.

 

What I think would be substantially harder is to = validate an entire V/X/J card.  How is a validator to know your = nickname is Fluffy?  Name, phone number and, if a business, a = classification, yes, we can do that.  Content of a business card - = very hard.

 

Brian

 

 

On = Nov 7, 2013, at 8:12 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:



From:=  Michael = Hammer [mailto:michael.hammer@yaanat= ech.com] 
Sent: Thursday, November 07, 2013 = 10:28 AM
To: Henning Schulzrinne; Pierce.Gorman@sprint.com; = br@brianrosen.net; richard@shockey.us
Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt

 

So, would you trust a certificate from the City of Reston, Virginia = police department?

 

(Hint:  you can find Reston on a map, but there is no City of = Reston. 

  The only police are Fairfax = County.)

 

My concern is that one you dilute or disperse authority, it becomes a = free-for-all again, and anybody’s = guess.

 

Mike

 

 

From:=  stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Thursday, November 07, 2013 = 10:00 AM
To: 'Gorman, Pierce A [NTK]'; = Brian Rosen; Richard Shockey
Cc: stir@ietf.org List; Fernando Mousinho = (fmousinh); cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

As a thought experiment, Kumiko Ono and I had published a = draft

 

 

to allow third parties to validate property information. If the = validating party (e.g., a bank regulator) is willing to sign a = certificate, similar in spirit to the framed gold-leaf diplomas in your = dentist’s office or, more lowly, to the health departments rating = in a restaurant window, and it can be tied to a phone number, this = shouldn’t be too hard.

 

It’s a bit harder if the certifying authority (regulator, = Realtor board, local bar association, …) is not = involved.

 

Henning

 

From:=  cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gorman, Pierce A = [NTK]
Sent: Thursday, November 07, 2013 = 9:54 AM
To: Brian Rosen; Richard = Shockey
Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho = (fmousinh)
Subject: Re: [cnit] [stir] = draft-peterson-stir-threats-00.txt

 

I’ll admit I am not familiar with v/x/jcard encoding differences = or the implications of their use so I’ll encourage educating me if = it isn’t too onerous.

 

I’m not sure what is the concern with a 3rd party providing = “validation” though.  There are numerous examples of = 3rd parties = providing validation of information including NASDAQ, NYSE, = Barron’s, Moody’s, and the federal reserve banking system to = name a few.

 

Pierce=

 

From:=  Brian Rosen = [mailto:br@brianrosen.net] 
Sent: November 06, 2013 11:59 = PM
To: Richard = Shockey
Cc: Fernando Mousinho (fmousinh); = Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

I think this would be a heavy = lift.

 

If the responsible entity was a carrier, then it would = have to validate the data, which it has very little basis to validate. =  It could get a 3rd party to do the validation, but then it’s = putting its reputation on the back of some hired hand = validator.

 

If the responsibility is the end user/device, then the = signature has no value.

 

I do not argue that Call-Info is suitable,  it = is.

 

I do question JCARD vs xCard, but that’s an = encoding detail.  All of SIP Is XML described by schema, not = json.

 

Brian

 

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> = wrote:

 

URI for a JCARD in the CALL INFO header provisioned by the calling = party and ultimately signed by the responsible entity.  The carrier = could provision this for their mobile or hosted customers.  = Enterprises could do this themselves.  This also has advantages in = Enterprise to Enterprise UC as well where the data is derived from the = Enterprise “directory” and could facilitate end to end PPX = to PBX communications especially in point to point video = communications.

 

There are certainly privacy and security issues to be = addressed.  The Push vs Pull model.  This really would be PII = in the clear but then its done = voluntarily.

 

There would have to be some work around restructuring the Header and = adding some parameters but it’s underutilized right now and this = Use Case is a perfectly appropriate = use.

 

 

Obviously it would need to be signed but we don’t need to worry = about that ..yet.

 

From 3261

 

20.9 Call-Info

 

   The Call-Info header field provides additional = information about the

   caller or callee, depending on whether it is found in a = request or

   response.  The purpose of the URI is described by = the "purpose"

   parameter.  The "icon" parameter = designates an image suitable as an

   iconic representation of the caller or callee.  The = "info" parameter

   describes the caller or callee in general, for example, = through a web

   page.  The "card" parameter provides a = business card, for example, in

   vCard [36] or LDIF [37] formats.  Additional tokens = can be registered

   using IANA and the procedures in Section = 27.

 

   Use of the Call-Info header field can pose a security = risk.  If a

   callee fetches the URIs provided by a malicious caller, = the callee

   may be at risk for displaying inappropriate or offensive = content,

   dangerous or illegal content, and so on.  = Therefore, it is

   RECOMMENDED that a UA only render the information in the = Call-Info

   header field if it can verify the authenticity of the = element that

   originated the header field and trusts that = element.  This need not

   be the peer UA; a proxy can insert this header field = into requests.

 

   Example:

 

   Call-Info: <http://wwww.example.com/alice/photo.jpg= > ;purpose=3Dicon,

     <http://www.example.com/alice/> = ;purpose=3Dinfo

 

From: Brian = Rosen [mailto:br@brianrosen.net] 
Sent: Wednesday, November 06, 2013 = 3:41 PM
To: Richard = Shockey
Cc: Fernando Mousinho (fmousinh); = Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

We’ve considered adding some information that is = not number and is not name, but is something like “bank”, = which might have some sort of validation behind = it.

 

Is that along the lines you were = thinking?

 

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:

 

I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification.  = Though your use case of credit card validation is a useful one and you = are right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session = validation.

 

It’s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list.

 

_______________________________________________

<= /div>

cnit mailing list

 

But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about.  STIR is essential but = it’s a multi-faceted problem that may require multi-faceted = solutions.. and enhanced CNAM + being only one of them.   Its = not unreasonable to discuss = those.

 

The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. =  I would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in = question.

 

 

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

Let me = rephrase it… it may eliminate the need for other forms of caller = identification beyond what STIR will provide, depending on the specific = use case. For example, a credit card company may choose to rely entirely = on STIR before allowing a card to be unblocked by an IVR (and as I said = earlier, many companies do it today). In other use cases, the TN alone = is not sufficient information – my health care provider will want = to know which member of the family is = calling.

 

I agree = that ANI is already broadly used to improve customer service today. = However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of = companies.

 

 

Going on a = tangent… perhaps this is out of scope, but there is not a lot of = discussion about called party hijacking. Couldn’t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it’s really them before carrying a = conversation, but wouldn’t they want the = same? 

 

 

From: <Gorman&= gt;, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Dat= e: Tuesday, November = 5, 2013 at 6:05 PM
To: Fernando Mousinho <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt

=

 

I agree with your characterization of businesses as victim of caller ID = fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center.  So I don’t agree that = STIR would “eliminate the need for caller identification from = known TNs.”

 

But perhaps I misunderstood your last = sentence?

 

 

From:=  Fernando = Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

I would = suggest we add a new attack type to section 3. More and more companies = are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I’m informed = that I don’t need to provide any further identification because my = number is on file. Some (all?) companies that implement this type of = validation rely on SS7 = today.

 

Ultimately,= this is yet another variation of impersonation – but in this = case, the “victim” is a business, unlike the other two = scenarios we’ve listed so = far.

 

Addressing = this scenario would actually turn STIR into a feature, given it would = enable contact centers of all sizes to eliminate the need for caller = identification from known = TNs.

 

 

 

From: Alex = Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, 2013 = at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, = "Peterson, Jon" <jon.peterson@neustar.biz>
Cc:=  "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, = MARTIN C'" <md3135@att.com>, 'Robert Sparks' = <rjsparks@nostrum.com>
Subject= : Re: [stir] = draft-peterson-stir-threats-00.txt

=

 

Jon,=

 

Thanks for = the response.  The intention in #1 below is to clarify the = following sentence:

 

The primary attack vector = is

  = ; therefore one where the attacker contrives for the calling = telephone

  = ; number in signaling to be a particular chosen number, one that = the

  = ; attacker does not have the authority to call from, in order for = that

  = ; number to be rendered on the terminating side. 

 

This might = be misconstrued as indicating that the objective of spoofing is simply = the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the = rendered information.  No issues with leaving this as it’s a = valid point.  Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on = CPN. 

 

So however = it’s worded, I think it’s important to allow for both attack = objectives of a spoofed presentation at the endpoint and in = transit.   

 

Regards,

 

Alex=

 

> = -----Original Message-----

> Brian = Rosen

> Sent: = Tuesday, October 01, 2013 9:29 = AM

> To: = Peterson, Jon

> = Cc: stir@ietf.org; Alex Bobotek; 'Robert = Sparks'; 'DOLLY, MARTIN C'; = Richard

> = Shockey

> = Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> <= /span>

> Don't = think there is much MESSAGE.  MSRP is about all we see, and XMPP = is

> more = likely than that.

> <= /span>

> = Brian

> <= /span>

> On = Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <jon.peterson@neustar.biz<= /span>>

> = wrote:

> <= /span>

> > = Thanks for these notes, Alex. Some responses = below.

> = >

> = >> Here are several comments that should feed into the IETF = Peterson draft:

> = >>

> = >> *   Remove any assumptions that the solution cannot = be in-network

> = [IMO,

> = >> both endpoint and in-network solutions should be = facilitated]

> = >

> > = Agreed that both in-band and out-of-band solutions can usually = be

> > = implemented in either endpoints or in intermediaries of various = kinds.

> > = If I see text that implies otherwise, I'll certainly change = it.

> = >

> = >> *   Add a sessionless attack scenario.  A spam = payload may be carried in

> = a

> = >> SIP INVITE or MESSAGE, which might contain stock market advice = even

> = >> in a display name field.  These attacks do NOT require = session

> = establishment.

> = >> More generally, we should be mindful of the fact that SIP is = used in

> = >> telephony form more than voice session = setup.

> = >

> > = Probably if we were going to include a sessionless attack scenario, = it

> > = would be with regular text messages (whether carried on the PSTN = over

> > = TCAP or with some Internet protocol, including MESSAGE) rather = than

> > = with an INVITE, which typically wouldn't result in a payload = being

> > = immediately rendered to a user. More on this below with your = suggested

> = text.

> = >

> = >> Here's some suggested = markup:

> = >>

> = >>

> = >> 1.    Replace 2nd sentence of 2nd paragraph of = 1.0 Introduction with:

> = >>

> = >> The primary attack vector = is

> = >>  therefore one where the attacker contrives for the = calling telephone

> = >> number in signaling to be a particular chosen number that = the

> = >> attacker does not have the authority to call = from.

> = >

> > = What you want here is to remove the implication that the number = will

> > = be rendered on the terminating side? While there are some = attacks

> > = where that isn't significant, perhaps, I would say it is = significant

> > = in the primary attack vectors that concern = us.

> = >

> = >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:

> = >>

> = >>     Smart devices are generally based on = computers with some degree

> = >> of programmability, the capacity to access the Internet, = and

> = >> capabilities of rendering text, audio and/or images.  This = includes

> = >> smart phones, telephone applications on desktop and laptop = computers,

> = >> IP private branch exchanges, and so = on.

> = >

> > = I can add the notion that smart devices can render text, audio = and/or

> > = images as you suggest.

> = >

> = >> 3.  Add to 3.3 Attack = Scenarios:

> = >>

> = >>       Impersonation, IP-Mobile Text = Message

> = >>

> = >>        An attacker with an = computer sends a high volume of SIP = MESSAGE

> = >> spam message to IP-enabled smart phones using randomized = calling

> = >> party numbers.

> = >>

> = >>       Countermeasure: in-band = authenticated identity

> = >

> > = Provided we're talking about end-to-end SIP use of MESSAGE, = agreed

> > = that in-band would be the right countermeasure. I am curious = though

> > = whether practically speaking there is enough use of MESSAGE in = this

> > = fashion that we're actually seeing high-volume spam over = MESSAGE

> > = today. Either way, no problem having an attack scenario of this form in = the

> = document.

> = >

> > = Jon Peterson

> > = Neustar, Inc.

> = >

> = >> Regards,

> = >>

> = >> Alex

> = >>

> = >>> -----Original = Message-----

> = >>> Of Richard = Shockey

> = >>> Sent: Monday, September 30, 2013 1:11 = PM

> = >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'

> = >>> Cc: stir@ietf.org<= /span>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> = >>>

> = >>> +1

> = >>>

> = >>> -----Original = Message-----

> = >>> Of DOLLY, MARTIN = C

> = >>> Sent: Monday, September 30, 2013 12:58 = PM

> = >>> To: Robert = Sparks

> = >>> Cc: stir@ietf.org<= /span>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> = >>>

> = >>> Yes, ok

> = >>>

> = >>> Martin Dolly

> = >>> Lead Member of Technical = Staff

> = >>> Core Network & Gov't/Regulatory Standards AT&T Labs = - Network

> = >>> Technology

> = >>> = +1-609-903-3360

> = >>> md3135@att.com=

> = >>>

> = >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"

> = >>> wrote:

> = >>>>

> = >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C = wrote:

> = >>>>> With Hadriel comments incorporated, it is a = start

> = >>>> Hi Martin = -

> = >>>>

> = >>>> Just to make sure - I think you're referring to = Hadriel's comments

> = >>>> on the

> = >>> problem statement = document?

> = >>>> I don't think Hadriel's commented directly on = stir-threats yet.

> = >>>>

> = >>>> In any case, we _are_ talking about a starting place, = not a

> = >>>> finished

> = >>> product.

> = >>>>

> = >>>> If there's no other objection, I'd like to get Jon to = submit the

> = >>>> threats

> = >>> document as a WG -00 as soon as it's = convenient.

> = >>>>

> = >>>> RjS

> = >>>>>

> = >>>>> -----Original = Message-----

> = >>>>> Behalf Of Russ = Housley

> = >>>>> Sent: Thursday, September 26, 2013 4:37 = PM

> = >>>>> To: IETF STIR Mail = List

> = >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> = >>>>>

> = >>>>> It has been six days, I'd like to hear from more = people about this

> = >>> document.  Martin asked for an additional week, so I'm = sure we will

> = >>> hear from him = soon.

> = >>>>>

> = >>>>> Russ

> = >>>>>

> = >>>>>

> = >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley = wrote:

> = >>>>>>

> = >>>>>>

> = >>>>>> Should the working group adopt this I-D as the = starting point for

> = >>>>>> = the

> = >>> STIR threat = docuent?

> = >>>>>>

> = >>>>>> = Russ

> = >>>>> = _______________________________________________

> = >>>>> stir mailing = list

> = >>>>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >>>>

> = >>>> = _______________________________________________

> = >>>> stir mailing = list

> = >>>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >>> = _______________________________________________

> = >>> stir mailing = list

> = >>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >>>

> = >>> = _______________________________________________

> = >>> stir mailing = list

> = >>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >> = _______________________________________________

> = >> stir mailing list

> = >> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >

> > = _______________________________________________

> > = stir mailing list

> = > stir@ietf.org<= /span>

<= p class=3DMsoNormal>> <= /span>

> = _______________________________________________

> stir = mailing list

> stir@ietf.org<= /span>

 

This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir<= /a>

 

------=_NextPart_001_0086_01CEDBB2.56084FD0-- ------=_NextPart_000_0085_01CEDBB2.56084FD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEw NzE3MTAyM1owIwYJKoZIhvcNAQkEMRYEFEGVsDTSzzQwAWpjVs96YvJNZexgMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAWe7bmhebvJca3L9Y0H+jrhaOFoNtvRyA3rJIkyXg 9NCyfTYIhhkglj+ntJtYlWbPQMlVlgOvoZ17riTXFdwfsllQ+n3QBTi88JMz8lxqstY+Tg750Cvq CLm+wCRsebuLCp236qq32ElRBfg6ge+HCcFE6LRnwWvgMgTwBThF+odZ0lv7ILogP1cv8jch88lq MQTgcgiBeVZuWtwq4bKLj2iad+xpuJQIibkjAOWCTFEOS7QOOjJpPWVGEdbwsNx9uv5ayYjx/Vq9 aarqQGCJkCpEqqyZe7f0HEpwUs4VSieCIzwuoyz6IslSypTt46pQvW9ddEdObcCrJhuWe23MowAA AAAAAA== ------=_NextPart_000_0085_01CEDBB2.56084FD0-- From br@brianrosen.net Thu Nov 7 09:15:04 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315FE21E81E1 for ; Thu, 7 Nov 2013 09:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7MqbGtGgUIe for ; Thu, 7 Nov 2013 09:14:57 -0800 (PST) Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9725021E81D8 for ; Thu, 7 Nov 2013 09:14:56 -0800 (PST) Received: by mail-bk0-f47.google.com with SMTP id d7so351699bkh.20 for ; Thu, 07 Nov 2013 09:14:55 -0800 (PST) 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:message-id:references:to; bh=PGqeQP+/sb/QJl2hmXk6A27GE76mJwqU9iNcefetrZA=; b=kvvtOpp1mvbcZJdvoAZbci1sc9Nm8wpKgDLmw23r+U9EJGPFOvO8R/m59IGA57W1TK NXnsnzIggettbCSYi1bgmVtFRhnmOOjTHrHNG8RQVU5++2cNqeDVGVdL2sQh3ZkNR4jd Ar5rgUMN38mODyQTnurIsiI7Hrpz1S0RwQuXbP8Lw0VisW+1JJ7HaoGz/N78sesY7Fif zsDOWVi4+fw+NK2dW8e7ZV908dpwasrS23m11+n/nYla4HLPDlZFJ+vFmzSLUI/eKeIX g+47sDARkjHt2lxwuN8OWhJLd2Z56PKkTP2wpNXQeIxKMiEVA3AcR7iQypGEToNqzSO4 WvPg== X-Gm-Message-State: ALoCoQn/2TJhyzzwfhLvPuwx3qe8p3ALFUOrZf5IOyATXBfqceTDYNvZoUgoJ20x1hVtS4m0+3me X-Received: by 10.205.15.72 with SMTP id pt8mr7192348bkb.17.1383844495647; Thu, 07 Nov 2013 09:14:55 -0800 (PST) Received: from dhcp-b7f9.meeting.ietf.org (dhcp-b7f9.meeting.ietf.org. [31.133.183.249]) by mx.google.com with ESMTPSA id l9sm3035432bkg.0.2013.11.07.09.14.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 09:14:54 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B4AA15F0-D053-4A54-BF14-9F16459A0029" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEF7E71@sc9-ex2k10mb1.corp.yaanatech.com> Date: Thu, 7 Nov 2013 09:14:48 -0800 Message-Id: References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7D86@sc9-ex2k10mb1.corp.yaanatech.com> <6A94C6CF-69F6-42D9-9A6C-32361A0A4755@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7E71@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1816) Cc: "cnit@ietf.org" , Richard Shockey , "stir@ietf.org" , "Pierce.Gorman@sprint.com" , "Henning.Schulzrinne@fcc.gov" , "fmousinh@cisco.com" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:15:05 -0000 --Apple-Mail=_B4AA15F0-D053-4A54-BF14-9F16459A0029 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yeah, I think we can work out a central authority in a country to handle = it. Don=92t think cross certifying would work. In the US, we have an agency (Federal Trade Commission) that is = intimately familiar with, and very motivated to do something about = spoofing of called id information, and could reasonably certify the = certifiers. Similar agencies exist in other countries that are = experiencing the problems we are addressing. Note that ALL you get out of this is the category. But, like Henning, I = think this is a VERY helpful, workable idea. Brian On Nov 7, 2013, at 9:10 AM, Michael Hammer = wrote: > So, how does the average user know who is an authority? > (Note, we are not designing for IETF geniuses here.) > =20 > Is some well-known central authority going to certify all of these? > Are each of these going to cross-certify all the others? (federated = model) > =20 > We need to always answer that fundamental user question: > Why should I TRUST this information? > =20 > Mike > =20 > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Thursday, November 07, 2013 12:03 PM > To: Henning Schulzrinne > Cc: Michael Hammer; Pierce.Gorman@sprint.com; Richard Shockey; = stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Right. I believe we can do this pretty easily. We probably could = have a 100 categories that would have similar authorities, and there are = classifications maintained by folks like Dun Bradstreet that can go even = farther. > =20 > What I think would be substantially harder is to validate an entire = V/X/J card. How is a validator to know your nickname is Fluffy? Name, = phone number and, if a business, a classification, yes, we can do that. = Content of a business card - very hard. > =20 > Brian > =20 > =20 > On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne = wrote: >=20 >=20 > Yes, that=92s a problem, but as long as the number of categories is = small, you can build UIs that only render information that=92s = appropriate to the declaration. For practical reasons, I think the = number of useful categories is likely going to be fairly limited: > - Financial institution (FDIC and a few others) > - Health care (each health care facility has a gov=92t = number) > - Charity (501c3, state registered) > - Contractor (state-licensed) > - Public safety organization (police, fire) > - Lawyer (bar association) > - Local, state and federal government (.gov in the US) > =20 > I suspect that list encompasses a large fraction of the fraudulent = (impersonation) calls. For all of the above, at least within a country, = it=92s pretty clear who can attest to the membership. Yes, this requires = some UI work or some server logic, but these categories and the = organizations don=92t change all that often =96 in most cases, the = certifying entities have probably been the same for the past 50+ years. = I=92m not as worried about figuring out whether the beautician, = mortician or florist is licensed and properly identified, although I=92m = sure we can all come up with potential fraud stories. > =20 > From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 > Sent: Thursday, November 07, 2013 10:28 AM > To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; = richard@shockey.us > Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org > Subject: RE: [stir] draft-peterson-stir-threats-00.txt > =20 > So, would you trust a certificate from the City of Reston, Virginia = police department? > =20 > (Hint: you can find Reston on a map, but there is no City of Reston.=20= > The only police are Fairfax County.) > =20 > My concern is that one you dilute or disperse authority, it becomes a = free-for-all again, and anybody=92s guess. > =20 > Mike > =20 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Henning Schulzrinne > Sent: Thursday, November 07, 2013 10:00 AM > To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey > Cc: stir@ietf.org List; Fernando Mousinho (fmousinh); cnit@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > As a thought experiment, Kumiko Ono and I had published a draft > =20 > http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 > =20 > to allow third parties to validate property information. If the = validating party (e.g., a bank regulator) is willing to sign a = certificate, similar in spirit to the framed gold-leaf diplomas in your = dentist=92s office or, more lowly, to the health departments rating in a = restaurant window, and it can be tied to a phone number, this shouldn=92t = be too hard. > =20 > It=92s a bit harder if the certifying authority (regulator, Realtor = board, local bar association, =85) is not involved. > =20 > Henning > =20 > From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf = Of Gorman, Pierce A [NTK] > Sent: Thursday, November 07, 2013 9:54 AM > To: Brian Rosen; Richard Shockey > Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) > Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt > =20 > I=92ll admit I am not familiar with v/x/jcard encoding differences or = the implications of their use so I=92ll encourage educating me if it = isn=92t too onerous. > =20 > I=92m not sure what is the concern with a 3rd party providing = =93validation=94 though. There are numerous examples of 3rd parties = providing validation of information including NASDAQ, NYSE, Barron=92s, = Moody=92s, and the federal reserve banking system to name a few. > =20 > Pierce > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: November 06, 2013 11:59 PM > To: Richard Shockey > Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; = stir@ietf.org List; cnit@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > I think this would be a heavy lift. > =20 > If the responsible entity was a carrier, then it would have to = validate the data, which it has very little basis to validate. It could = get a 3rd party to do the validation, but then it=92s putting its = reputation on the back of some hired hand validator. > =20 > If the responsibility is the end user/device, then the signature has = no value. > =20 > I do not argue that Call-Info is suitable, it is. > =20 > I do question JCARD vs xCard, but that=92s an encoding detail. All of = SIP Is XML described by schema, not json. > =20 > Brian > =20 > On Nov 6, 2013, at 1:10 PM, Richard Shockey = wrote: > =20 >=20 > URI for a JCARD in the CALL INFO header provisioned by the calling = party and ultimately signed by the responsible entity. The carrier = could provision this for their mobile or hosted customers. Enterprises = could do this themselves. This also has advantages in Enterprise to = Enterprise UC as well where the data is derived from the Enterprise = =93directory=94 and could facilitate end to end PPX to PBX = communications especially in point to point video communications. > =20 > There are certainly privacy and security issues to be addressed. The = Push vs Pull model. This really would be PII in the clear but then its = done voluntarily. > =20 > There would have to be some work around restructuring the Header and = adding some parameters but it=92s underutilized right now and this Use = Case is a perfectly appropriate use. > =20 > https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 > =20 > Obviously it would need to be signed but we don=92t need to worry = about that ..yet. > =20 > =46rom 3261 > =20 > 20.9 Call-Info > =20 > The Call-Info header field provides additional information about = the > caller or callee, depending on whether it is found in a request or > response. The purpose of the URI is described by the "purpose" > parameter. The "icon" parameter designates an image suitable as an > iconic representation of the caller or callee. The "info" = parameter > describes the caller or callee in general, for example, through a = web > page. The "card" parameter provides a business card, for example, = in > vCard [36] or LDIF [37] formats. Additional tokens can be = registered > using IANA and the procedures in Section 27. > =20 > Use of the Call-Info header field can pose a security risk. If a > callee fetches the URIs provided by a malicious caller, the callee > may be at risk for displaying inappropriate or offensive content, > dangerous or illegal content, and so on. Therefore, it is > RECOMMENDED that a UA only render the information in the Call-Info > header field if it can verify the authenticity of the element that > originated the header field and trusts that element. This need not > be the peer UA; a proxy can insert this header field into requests. > =20 > Example: > =20 > Call-Info: ;purpose=3Dicon,= > ;purpose=3Dinfo > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, November 06, 2013 3:41 PM > To: Richard Shockey > Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; = stir@ietf.org List > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > We=92ve considered adding some information that is not number and is = not name, but is something like =93bank=94, which might have some sort = of validation behind it. > =20 > Is that along the lines you were thinking? > =20 > Brian > On Nov 6, 2013, at 5:25 AM, Richard Shockey = wrote: > =20 >=20 > I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification. Though = your use case of credit card validation is a useful one and you are = right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session validation. > =20 > It=92s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list. > =20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > =20 > But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about. STIR is essential but it=92s a = multi-faceted problem that may require multi-faceted solutions.. and = enhanced CNAM + being only one of them. Its not unreasonable to = discuss those. > =20 > The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. I = would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in question. > =20 > =20 > =20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Fernando Mousinho (fmousinh) > Sent: Tuesday, November 05, 2013 6:26 PM > To: Gorman, Pierce A [NTK]; stir@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Let me rephrase it=85 it may eliminate the need for other forms of = caller identification beyond what STIR will provide, depending on the = specific use case. For example, a credit card company may choose to rely = entirely on STIR before allowing a card to be unblocked by an IVR (and = as I said earlier, many companies do it today). In other use cases, the = TN alone is not sufficient information =96 my health care provider will = want to know which member of the family is calling. > =20 > I agree that ANI is already broadly used to improve customer service = today. However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of companies. > =20 > =20 > Going on a tangent=85 perhaps this is out of scope, but there is not a = lot of discussion about called party hijacking. Couldn=92t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it=92s really them before carrying a = conversation, but wouldn=92t they want the same?=20 > =20 > =20 > From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM > To: Fernando Mousinho , "stir@ietf.org" = > Subject: RE: [stir] draft-peterson-stir-threats-00.txt > =20 > I agree with your characterization of businesses as victim of caller = ID fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center. So I don=92t agree that STIR = would =93eliminate the need for caller identification from known TNs.=94 > =20 > But perhaps I misunderstood your last sentence? > =20 > =20 > From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com]=20 > Sent: November 05, 2013 4:34 PM > To: stir@ietf.org > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > I would suggest we add a new attack type to section 3. More and more = companies are using the caller ID for account validation. For example, = if I call my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I=92m informed that = I don=92t need to provide any further identification because my number = is on file. Some (all?) companies that implement this type of validation = rely on SS7 today. > =20 > Ultimately, this is yet another variation of impersonation =96 but in = this case, the =93victim=94 is a business, unlike the other two = scenarios we=92ve listed so far. > =20 > Addressing this scenario would actually turn STIR into a feature, = given it would enable contact centers of all sizes to eliminate the need = for caller identification from known TNs. > =20 > =20 > =20 > From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM > To: Brian Rosen , "Peterson, Jon" = > Cc: "stir@ietf.org" , Richard Shockey = , "'DOLLY, MARTIN C'" , 'Robert = Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > =20 > Jon, > =20 > Thanks for the response. The intention in #1 below is to clarify the = following sentence: > =20 > The primary attack vector is > therefore one where the attacker contrives for the calling = telephone > number in signaling to be a particular chosen number, one that the > attacker does not have the authority to call from, in order for = that > number to be rendered on the terminating side.=20 > =20 > This might be misconstrued as indicating that the objective of = spoofing is simply the rendering of a spoofed number on the receiving = display, causing mistaken conclusions that defenses might be limited to = securing the rendered information. No issues with leaving this as it=92s = a valid point. Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on CPN.=20 > =20 > So however it=92s worded, I think it=92s important to allow for both = attack objectives of a spoofed presentation at the endpoint and in = transit. =20 > =20 > Regards, > =20 > Alex > =20 > > -----Original Message----- > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > > Brian Rosen > > Sent: Tuesday, October 01, 2013 9:29 AM > > To: Peterson, Jon > > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; = Richard > > Shockey > > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >=20 > > Don't think there is much MESSAGE. MSRP is about all we see, and = XMPP is > > more likely than that. > >=20 > > Brian > >=20 > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" = > > wrote: > >=20 > > > Thanks for these notes, Alex. Some responses below. > > > > > >> Here are several comments that should feed into the IETF Peterson = draft: > > >> > > >> * Remove any assumptions that the solution cannot be in-network > > [IMO, > > >> both endpoint and in-network solutions should be facilitated] > > > > > > Agreed that both in-band and out-of-band solutions can usually be > > > implemented in either endpoints or in intermediaries of various = kinds. > > > If I see text that implies otherwise, I'll certainly change it. > > > > > >> * Add a sessionless attack scenario. A spam payload may be = carried in > > a > > >> SIP INVITE or MESSAGE, which might contain stock market advice = even > > >> in a display name field. These attacks do NOT require session > > establishment. > > >> More generally, we should be mindful of the fact that SIP is used = in > > >> telephony form more than voice session setup. > > > > > > Probably if we were going to include a sessionless attack = scenario, it > > > would be with regular text messages (whether carried on the PSTN = over > > > TCAP or with some Internet protocol, including MESSAGE) rather = than > > > with an INVITE, which typically wouldn't result in a payload being > > > immediately rendered to a user. More on this below with your = suggested > > text. > > > > > >> Here's some suggested markup: > > >> > > >> > > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction = with: > > >> > > >> The primary attack vector is > > >> therefore one where the attacker contrives for the calling = telephone > > >> number in signaling to be a particular chosen number that the > > >> attacker does not have the authority to call from. > > > > > > What you want here is to remove the implication that the number = will > > > be rendered on the terminating side? While there are some attacks > > > where that isn't significant, perhaps, I would say it is = significant > > > in the primary attack vectors that concern us. > > > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > > >> > > >> Smart devices are generally based on computers with some = degree > > >> of programmability, the capacity to access the Internet, and > > >> capabilities of rendering text, audio and/or images. This = includes > > >> smart phones, telephone applications on desktop and laptop = computers, > > >> IP private branch exchanges, and so on. > > > > > > I can add the notion that smart devices can render text, audio = and/or > > > images as you suggest. > > > > > >> 3. Add to 3.3 Attack Scenarios: > > >> > > >> Impersonation, IP-Mobile Text Message > > >> > > >> An attacker with an computer sends a high volume of SIP = MESSAGE > > >> spam message to IP-enabled smart phones using randomized calling > > >> party numbers. > > >> > > >> Countermeasure: in-band authenticated identity > > > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > > that in-band would be the right countermeasure. I am curious = though > > > whether practically speaking there is enough use of MESSAGE in = this > > > fashion that we're actually seeing high-volume spam over MESSAGE > > > today. Either way, no problem having an attack scenario of this = form in the > > document. > > > > > > Jon Peterson > > > Neustar, Inc. > > > > > >> Regards, > > >> > > >> Alex > > >> > > >>> -----Original Message----- > > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf > > >>> Of Richard Shockey > > >>> Sent: Monday, September 30, 2013 1:11 PM > > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > > >>> Cc: stir@ietf.org > > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>> > > >>> +1 > > >>> > > >>> -----Original Message----- > > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf > > >>> Of DOLLY, MARTIN C > > >>> Sent: Monday, September 30, 2013 12:58 PM > > >>> To: Robert Sparks > > >>> Cc: stir@ietf.org > > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>> > > >>> Yes, ok > > >>> > > >>> Martin Dolly > > >>> Lead Member of Technical Staff > > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > > >>> Technology > > >>> +1-609-903-3360 > > >>> md3135@att.com > > >>> > > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > > >>>> > > >>> wrote: > > >>>> > > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > > >>>>> With Hadriel comments incorporated, it is a start > > >>>> Hi Martin - > > >>>> > > >>>> Just to make sure - I think you're referring to Hadriel's = comments > > >>>> on the > > >>> problem statement document? > > >>>> I don't think Hadriel's commented directly on stir-threats yet. > > >>>> > > >>>> In any case, we _are_ talking about a starting place, not a > > >>>> finished > > >>> product. > > >>>> > > >>>> If there's no other objection, I'd like to get Jon to submit = the > > >>>> threats > > >>> document as a WG -00 as soon as it's convenient. > > >>>> > > >>>> RjS > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On > > >>>>> Behalf Of Russ Housley > > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > > >>>>> To: IETF STIR Mail List > > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > >>>>> > > >>>>> It has been six days, I'd like to hear from more people about = this > > >>> document. Martin asked for an additional week, so I'm sure we = will > > >>> hear from him soon. > > >>>>> > > >>>>> Russ > > >>>>> > > >>>>> > > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > > >>>>>> > > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > > >>>>>> > > >>>>>> Should the working group adopt this I-D as the starting point = for > > >>>>>> the > > >>> STIR threat docuent? > > >>>>>> > > >>>>>> Russ > > >>>>> _______________________________________________ > > >>>>> 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 > > >>> _______________________________________________ > > >>> 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 > > >> _______________________________________________ > > >> 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 > >=20 > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > =20 >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > =20 > =20 > =20 >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. --Apple-Mail=_B4AA15F0-D053-4A54-BF14-9F16459A0029 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yeah, = I think we can work out a central authority in a country to handle it. =  Don=92t think cross certifying would work.
In the US, we have = an agency (Federal Trade Commission) that is intimately familiar with, = and very motivated to do something about spoofing of called id = information, and could reasonably certify the certifiers.  Similar = agencies exist in other countries that are experiencing the problems we = are addressing.

Note that ALL you get out of = this is the category.  But, like Henning, I think this is a VERY = helpful, workable = idea.

Brian


So, how does the average user know who is an = authority?
(Note, we are not designing for IETF geniuses = here.)
 
Is some well-known central authority going to certify = all of these?
Are each of these going to cross-certify all the = others? (federated model)
 
We need to always answer = that fundamental user question:
Why should I TRUST this = information?
 
Mike
 
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Thursday, November 07, 2013 = 12:03 PM
To: Henning = Schulzrinne
Cc: Michael Hammer; Pierce.Gorman@sprint.com; = Richard Shockey; stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
Right.  I believe we can do this pretty easily.  We = probably could have a 100 categories that would have similar = authorities, and there are classifications maintained by folks like Dun = Bradstreet that can go even farther.
 
What I think would be substantially harder is to = validate an entire V/X/J card.  How is a validator to know your = nickname is Fluffy?  Name, phone number and, if a business, a = classification, yes, we can do that.  Content of a business card - = very hard.
 
Brian
 
 
On = Nov 7, 2013, at 8:12 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> = wrote:


Yes, that=92s a problem, but as long as the number of = categories is small, you can build UIs that only render information = that=92s appropriate to the declaration. For practical reasons, I think = the number of useful categories is likely going to be fairly = limited:
-          Financial institution (FDIC and a few = others)
-          Health care (each health care facility has a gov=92t = number)
-          Charity (501c3, state = registered)
-          Contractor = (state-licensed)
-          Public safety organization (police, = fire)
-          Lawyer (bar = association)
-          Local, state and federal government (.gov in the = US)
 
I suspect that list = encompasses a large fraction of the fraudulent (impersonation) calls. = For all of the above, at least within a country, it=92s pretty clear who = can attest to the membership. Yes, this requires some UI work or some = server logic, but these categories and the organizations don=92t change = all that often =96 in most cases, the certifying entities have probably = been the same for the past 50+ years. I=92m not as worried about = figuring out whether the beautician, mortician or florist is licensed = and properly identified, although I=92m sure we can all come up with = potential fraud stories.
 
From: Michael Hammer [mailto:michael.hammer@yaanatech.com] 
Sent: Thursday, November 07, 2013 = 10:28 AM
To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; richard@shockey.us
Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt
 
So, would you trust a = certificate from the City of Reston, Virginia police = department?
 
(Hint:  you can find Reston = on a map, but there is no City of = Reston. 
  The only police are = Fairfax County.)
 
My concern is that one you dilute = or disperse authority, it becomes a free-for-all again, and anybody=92s = guess.
 
Mike
 
 
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Thursday, November 07, 2013 = 10:00 AM
To: 'Gorman, Pierce A [NTK]'; = Brian Rosen; Richard Shockey
Cc: stir@ietf.org List; Fernando Mousinho = (fmousinh); cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
As a thought experiment, = Kumiko Ono and I had published a = draft
 
 
to allow third parties to validate = property information. If the validating party (e.g., a bank regulator) = is willing to sign a certificate, similar in spirit to the framed = gold-leaf diplomas in your dentist=92s office or, more lowly, to the = health departments rating in a restaurant window, and it can be tied to = a phone number, this shouldn=92t be too = hard.
 
It=92s a bit harder if = the certifying authority (regulator, Realtor board, local bar = association, =85) is not = involved.
 
Henning
 
From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gorman, Pierce A = [NTK]
Sent: Thursday, November 07, 2013 = 9:54 AM
To: Brian Rosen; Richard = Shockey
Cc: stir@ietf.org List; cnit@ietf.org; = Fernando Mousinho (fmousinh)
Subject: Re: [cnit] [stir] = draft-peterson-stir-threats-00.txt
 
I=92ll admit I am not familiar with = v/x/jcard encoding differences or the implications of their use so I=92ll = encourage educating me if it isn=92t too = onerous.
 
I=92m not sure what is the concern with a = 3rd party = providing =93validation=94 though.  There are numerous examples of = 3rd parties = providing validation of information including NASDAQ, NYSE, Barron=92s, = Moody=92s, and the federal reserve banking system to name a = few.
 
Pierce
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: November 06, 2013 11:59 = PM
To: Richard= Shockey
Cc: Fernando Mousinho = (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
I think this would be a heavy = lift.
 
If = the responsible entity was a carrier, then it would have to validate the = data, which it has very little basis to validate.  It could get a = 3rd party to do the validation, but then it=92s putting its reputation = on the back of some hired hand = validator.
 
If = the responsibility is the end user/device, then the signature has no = value.
 
I do = not argue that Call-Info is suitable,  it = is.
 
I do = question JCARD vs xCard, but that=92s an encoding detail.  All of = SIP Is XML described by schema, not = json.
 
Brian
 
On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> = wrote:

 

URI for a JCARD in the CALL INFO header provisioned = by the calling party and ultimately signed by the responsible entity. =  The carrier could provision this for their mobile or hosted = customers.  Enterprises could do this themselves.  This also = has advantages in Enterprise to Enterprise UC as well where the data is = derived from the Enterprise =93directory=94 and could facilitate end to = end PPX to PBX communications especially in point to point video = communications.
 
There are certainly privacy and = security issues to be addressed.  The Push vs Pull model.  = This really would be PII in the clear but then its done = voluntarily.
 
There would have to be some work = around restructuring the Header and adding some parameters but it=92s = underutilized right now and this Use Case is a perfectly appropriate = use.
 
     <http://www.example.com/alice/> = ;purpose=3Dinfo
 
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Wednesday, November 06, = 2013 3:41 PM
To: Richard = Shockey
Cc: Fernando Mousinho = (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
We=92ve considered adding some information that is = not number and is not name, but is something like =93bank=94, which = might have some sort of validation behind = it.
 
Is = that along the lines you were thinking?
 
Brian
On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:

 

I agree with Pierce here and respectfully disagree = that STIR might eliminate the need for other forms of caller = identification.  Though your use case of credit card validation is = a useful one and you are right there are still applications that use SS7 = for things that have nothing to do with call setup. I agree with you = STIR may have more applications beyond the obvious ones of realtime = session validation.
 
It=92s been my experience recently = that there is a use case for something MORE in the identification of the = session as it is presented to the called party. This is the CNAM + idea = we are kicking around on the CNIT = list.
 
_______________________________________________
cnit mailing = list
 
But your use case of a bank = wanting to make sure they could properly identify themselves to the = consumer before establishing a conversation is exactly what this process = is about.  STIR is essential but it=92s a multi-faceted problem = that may require multi-faceted solutions.. and enhanced CNAM + being = only one of them.   Its not unreasonable to discuss = those.
 
The obviously analogy is = I would want to see some real identification of a utility worker before = I let them into my house to make repairs.  I would want some = validation that the call to me to reconfirm the appointments was in fact = from the utility in question.
 
 
 
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A = [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
Let me rephrase it=85 it may eliminate the need = for other forms of caller identification beyond what STIR will provide, = depending on the specific use case. For example, a credit card company = may choose to rely entirely on STIR before allowing a card to be = unblocked by an IVR (and as I said earlier, many companies do it today). = In other use cases, the TN alone is not sufficient information =96 my = health care provider will want to know which member of the family is = calling.
 
I agree that ANI is already broadly used to = improve customer service today. However, it is not usually deemed as a = secure enough mechanism to validate the caller (therefore this WG!), = except if you are a large organization that can leverage things like = SS7. STIR would make this type of validation available to a broader = number of companies.
 
 
Going on a tangent=85 perhaps this is out of = scope, but there is not a lot of discussion about called party = hijacking. Couldn=92t a man-in-the-middle try to answer calls on my = behalf? If my bank is calling me, I want to make sure it=92s really them = before carrying a conversation, but wouldn=92t they want the = same? 
 
 
From: <Gorman>, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Date: Tuesday, November 5, = 2013 at 6:05 PM
To: Fernando Mousinho = <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt
 
I agree with your characterization = of businesses as victim of caller ID fraud however contact centers also = use TN as a key to improve information available to call agents to = reduce average time-per-call and increase capacity of the call = center.  So I don=92t agree that STIR would =93eliminate the need = for caller identification from known = TNs.=94
 
But perhaps I misunderstood your last = sentence?
 
 
From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
I would suggest we add a new attack type to = section 3. More and more companies are using the caller ID for account = validation. For example, if I call my credit card provider from my = office number, they ask me for identification. If I call from my home = phone number, I=92m informed that I don=92t need to provide any further = identification because my number is on file. Some (all?) companies that = implement this type of validation rely on SS7 = today.
 
Ultimately, this is yet another variation of = impersonation =96 but in this case, the =93victim=94 is a business, = unlike the other two scenarios we=92ve listed so = far.
 
Addressing this scenario would actually turn STIR = into a feature, given it would enable contact centers of all sizes to = eliminate the need for caller identification from known = TNs.
 
 
 
From: Alex = Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, = 2013 at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, MARTIN C'" <md3135@att.com>, 'Robert Sparks' <rjsparks@nostrum.com>
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
 
Jon,
 
Thanks for the response.  The intention in #1 = below is to clarify the following = sentence:
 
The primary attack vector = is
   therefore one where the attacker contrives for = the calling telephone
   number in signaling to be a = particular chosen number, one that = the
   attacker does not have the authority to call = from, in order for = that
   number to be rendered on the terminating = side. 
 
This might be misconstrued as indicating that the = objective of spoofing is simply the rendering of a spoofed number on the = receiving display, causing mistaken conclusions that defenses might be = limited to securing the rendered information.  No issues with = leaving this as it=92s a valid point.  Another (increasing) = motivation is to evade network and/or endpoint defenses that may block = based on CPN. 
 
So however it=92s worded, I think it=92s important = to allow for both attack objectives of a spoofed presentation at the = endpoint and in transit.  =  
 
Regards,
 
Alex
 
> -----Original = Message-----
> Brian = Rosen
> Sent: = Tuesday, October 01, 2013 9:29 AM
> To: Peterson, = Jon
> = Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, = MARTIN C'; Richard
> Shockey
> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> 
> Don't think there is much MESSAGE.  MSRP = is about all we see, and XMPP is
> more likely than = that.
> 
> Brian
> 
> On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" = <jon.peterson@neustar.biz>
> = wrote:
> 
> > Thanks for these notes, Alex. Some = responses below.
> >
> >> Here are several comments that = should feed into the IETF Peterson = draft:
> = >>
> = >> *   Remove any assumptions that the solution cannot = be in-network
> [IMO,
> >> both endpoint and in-network = solutions should be facilitated]
> >
> > Agreed that both in-band and out-of-band = solutions can usually be
> > implemented in either endpoints or in = intermediaries of various kinds.
> > If I see text that implies otherwise, = I'll certainly change it.
> >
> >> *   Add a sessionless = attack scenario.  A spam payload may be carried = in
> = a
> = >> SIP INVITE or MESSAGE, which might contain stock market advice = even
> = >> in a display name field.  These attacks do NOT require = session
> = establishment.
> >> More generally, we should be mindful of the = fact that SIP is used in
> >> telephony form more than voice = session setup.
> >
> > Probably if we were going to include a = sessionless attack scenario, it
> > would be with regular text messages = (whether carried on the PSTN over
> > TCAP or with some Internet protocol, = including MESSAGE) rather than
> > with an INVITE, which typically wouldn't = result in a payload being
> > immediately rendered to a user. More on = this below with your suggested
> text.
> >
> >> Here's some suggested = markup:
> = >>
> = >>
> = >> 1.    Replace 2nd sentence of 2nd paragraph of = 1.0 Introduction with:
> = >>
> = >> The primary attack vector = is
> = >>  therefore one where the attacker contrives for the = calling telephone
> >> number in signaling to be a particular chosen = number that the
> >> attacker does not have the authority to call = from.
> = >
> > = What you want here is to remove the implication that the number = will
> > = be rendered on the terminating side? While there are some = attacks
> > = where that isn't significant, perhaps, I would say it is = significant
> > in the primary attack vectors that concern = us.
> = >
> = >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:
> = >>
> = >>     Smart devices are generally based on = computers with some degree
> >> of programmability, the capacity to = access the Internet, and
> >> capabilities of rendering text, = audio and/or images.  This = includes
> = >> smart phones, telephone applications on desktop and laptop = computers,
> >> IP private branch exchanges, and so = on.
> = >
> > I = can add the notion that smart devices can render text, audio = and/or
> > = images as you suggest.
> >
> >> 3.  Add to 3.3 Attack = Scenarios:
> >>
> >>       = Impersonation, IP-Mobile Text = Message
> = >>
> = >>        An attacker with an = computer sends a high volume of SIP = MESSAGE
> = >> spam message to IP-enabled smart phones using randomized = calling
> = >> party numbers.
> = >>
> = >>       Countermeasure: in-band = authenticated identity
> >
> > Provided we're talking about end-to-end = SIP use of MESSAGE, agreed
> > that in-band would be the right = countermeasure. I am curious = though
> > = whether practically speaking there is enough use of MESSAGE in = this
> > = fashion that we're actually seeing high-volume spam over = MESSAGE
> > = today. Either way, no problem having an attack scenario of this form in = the
> = document.
> >
> > Jon = Peterson
> > = Neustar, Inc.
> >
> >> = Regards,
> = >>
> = >> Alex
> >>
> >>> -----Original = Message-----
> = >>> Of Richard Shockey
> >>> Sent: Monday, September 30, 2013 = 1:11 PM
> = >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'
> = >>> Cc: stir@ietf.org
> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> = >>>
> >>> +1
> = >>>
> >>> -----Original = Message-----
> = >>> Of DOLLY, MARTIN C
> >>> Sent: Monday, September 30, 2013 = 12:58 PM
> = >>> To: Robert Sparks
> >>> Cc: stir@ietf.org
> >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> = >>>
> >>> Yes, = ok
> = >>>
> >>> Martin = Dolly
> = >>> Lead Member of Technical = Staff
> = >>> Core Network & Gov't/Regulatory Standards AT&T Labs = - Network
> >>> = Technology
> >>> = +1-609-903-3360
> = >>>
> >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"
> >>> = wrote:
> = >>>>
> >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN = C wrote:
> = >>>>> With Hadriel comments incorporated, it is a = start
> = >>>> Hi Martin -
> = >>>>
> >>>> Just to make sure - I think you're = referring to Hadriel's comments
> >>>> on = the
> = >>> problem statement = document?
> >>>> I don't think Hadriel's commented = directly on stir-threats yet.
> = >>>>
> >>>> In any case, we _are_ talking about a = starting place, not a
> >>>> = finished
> = >>> product.
> = >>>>
> >>>> If there's no other objection, I'd = like to get Jon to submit the
> >>>> = threats
> = >>> document as a WG -00 as soon as it's = convenient.
> = >>>>
> >>>> = RjS
> = >>>>>
> >>>>> -----Original = Message-----
> = >>>>> Behalf Of Russ = Housley
> = >>>>> Sent: Thursday, September 26, 2013 4:37 = PM
> = >>>>> To: IETF STIR Mail = List
> = >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt
> = >>>>>
> >>>>> It has been six days, = I'd like to hear from more people about = this
> = >>> document.  Martin asked for an additional week, so I'm = sure we will
> >>> hear from him = soon.
> = >>>>>
> >>>>> = Russ
> = >>>>>
> = >>>>>
> >>>>>> On Sep 20, 2013, at = 5:23 PM, Russ Housley wrote:
> = >>>>>>
> = >>>>
> >>>> = _______________________________________________
> >>>> stir mailing = list
> = >>>> stir@ietf.org
> >>> = _______________________________________________
> >>> stir mailing = list
> = >>> stir@ietf.org
> = >>>
> >>> = _______________________________________________
> >>> stir mailing = list
> = >>> stir@ietf.org
> >> = _______________________________________________
> >> stir mailing = list
> = >
> > = _______________________________________________
> > stir mailing = list
> 
> = _______________________________________________
> stir mailing = list
 

This e-mail may contain Sprint proprietary = information intended for the sole use of the recipient(s). Any use by = others is prohibited. If you are not the intended recipient, please = contact the sender and delete all copies of the = message.
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir=
 
 
 

This e-mail may contain Sprint proprietary information = intended for the sole use of the recipient(s). Any use by others is = prohibited. If you are not the intended recipient, please contact the = sender and delete all copies of the = message.

= --Apple-Mail=_B4AA15F0-D053-4A54-BF14-9F16459A0029-- From Henning.Schulzrinne@fcc.gov Thu Nov 7 09:15:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD7D11E8188; Thu, 7 Nov 2013 09:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn5ipXs3q3nf; Thu, 7 Nov 2013 09:15:12 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 6763121E81F1; Thu, 7 Nov 2013 09:15:07 -0800 (PST) Message-ID: From: Henning Schulzrinne To: 'Michael Hammer' , "br@brianrosen.net" Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQHO28lBm7MQs/E/Y0C8yrTGiGFz45oZ21rggABc6AD//7YS0IAAZHIAgAAB9wD//6y9gA== Date: Thu, 7 Nov 2013 17:15:05 +0000 References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7D86@sc9-ex2k10mb1.corp.yaanatech.com> <6A94C6CF-69F6-42D9-9A6C-32361A0A4755@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7E71@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEF7E71@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FC23ABCp2pxmb13fccnetw_" MIME-Version: 1.0 Cc: "stir@ietf.org" , "Pierce.Gorman@sprint.com" , "fmousinh@cisco.com" , "cnit@ietf.org" , "richard@shockey.us" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:15:31 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FC23ABCp2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The user shouldn't and wouldn't - they would trust a third party (often, th= eir carrier, I suspect) to figure out who can attest to the bankiness of a = bank. This is not new - there are a number of existing outfits that do this= for web sites. (Example: Avast has a bar graph that shows trustworthiness.= ) From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 12:10 PM To: br@brianrosen.net; Henning Schulzrinne Cc: Pierce.Gorman@sprint.com; richard@shockey.us; stir@ietf.org; fmousinh@c= isco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, how does the average user know who is an authority? (Note, we are not designing for IETF geniuses here.) Is some well-known central authority going to certify all of these? Are each of these going to cross-certify all the others? (federated model) We need to always answer that fundamental user question: Why should I TRUST this information? Mike From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, November 07, 2013 12:03 PM To: Henning Schulzrinne Cc: Michael Hammer; Pierce.Gorman@sprint.com; Richard Shockey; stir@ietf.org; fmousinh@cisco.co= m; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Right. I believe we can do this pretty easily. We probably could have a 1= 00 categories that would have similar authorities, and there are classifica= tions maintained by folks like Dun Bradstreet that can go even farther. What I think would be substantially harder is to validate an entire V/X/J c= ard. How is a validator to know your nickname is Fluffy? Name, phone numb= er and, if a business, a classification, yes, we can do that. Content of a= business card - very hard. Brian On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne > wrote: Yes, that's a problem, but as long as the number of categories is small, yo= u can build UIs that only render information that's appropriate to the decl= aration. For practical reasons, I think the number of useful categories is = likely going to be fairly limited: - Financial institution (FDIC and a few others) - Health care (each health care facility has a gov't number) - Charity (501c3, state registered) - Contractor (state-licensed) - Public safety organization (police, fire) - Lawyer (bar association) - Local, state and federal government (.gov in the US) I suspect that list encompasses a large fraction of the fraudulent (imperso= nation) calls. For all of the above, at least within a country, it's pretty= clear who can attest to the membership. Yes, this requires some UI work or= some server logic, but these categories and the organizations don't change= all that often - in most cases, the certifying entities have probably been= the same for the past 50+ years. I'm not as worried about figuring out whe= ther the beautician, mortician or florist is licensed and properly identifi= ed, although I'm sure we can all come up with potential fraud stories. From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 10:28 AM To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; richard@shockey.us Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, would you trust a certificate from the City of Reston, Virginia police = department? (Hint: you can find Reston on a map, but there is no City of Reston. The only police are Fairfax County.) My concern is that one you dilute or disperse authority, it becomes a free-= for-all again, and anybody's guess. Mike From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, November 07, 2013 10:00 AM To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey Cc: stir@ietf.org List; Fernando Mousinho (fmousinh);= cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt As a thought experiment, Kumiko Ono and I had published a draft http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 to allow third parties to validate property information. If the validating = party (e.g., a bank regulator) is willing to sign a certificate, similar in= spirit to the framed gold-leaf diplomas in your dentist's office or, more = lowly, to the health departments rating in a restaurant window, and it can = be tied to a phone number, this shouldn't be too hard. It's a bit harder if the certifying authority (regulator, Realtor board, lo= cal bar association, ...) is not involved. Henning From: cnit-bounces@ietf.org [mailto:cnit-boun= ces@ietf.org] On Behalf Of Gorman, P= ierce A [NTK] Sent: Thursday, November 07, 2013 9:54 AM To: Brian Rosen; Richard Shockey Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I'll admit I am not familiar with v/x/jcard encoding differences or the imp= lications of their use so I'll encourage educating me if it isn't too onero= us. I'm not sure what is the concern with a 3rd party providing "validation" th= ough. There are numerous examples of 3rd parties providing validation of i= nformation including NASDAQ, NYSE, Barron's, Moody's, and the federal reser= ve banking system to name a few. Pierce From: Brian Rosen [mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the= data, which it has very little basis to validate. It could get a 3rd part= y to do the validation, but then it's putting its reputation on the back of= some hired hand validator. If the responsibility is the end user/device, then the signature has no val= ue. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is= XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey > wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party an= d ultimately signed by the responsible entity. The carrier could provision= this for their mobile or hosted customers. Enterprises could do this them= selves. This also has advantages in Enterprise to Enterprise UC as well wh= ere the data is derived from the Enterprise "directory" and could facilitat= e end to end PPX to PBX communications especially in point to point video c= ommunications. There are certainly privacy and security issues to be addressed. The Push = vs Pull model. This really would be PII in the clear but then its done vol= untarily. There would have to be some work around restructuring the Header and adding= some parameters but it's underutilized right now and this Use Case is a pe= rfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that = ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: ;purpose=3Dicon, ;purpose=3Dinfo From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name= , but is something like "bank", which might have some sort of validation be= hind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey > wrote: I agree with Pierce here and respectfully disagree that STIR might eliminat= e the need for other forms of caller identification. Though your use case = of credit card validation is a useful one and you are right there are still= applications that use SS7 for things that have nothing to do with call set= up. I agree with you STIR may have more applications beyond the obvious one= s of realtime session validation. It's been my experience recently that there is a use case for something MOR= E in the identification of the session as it is presented to the called par= ty. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identi= fy themselves to the consumer before establishing a conversation is exactly= what this process is about. STIR is essential but it's a multi-faceted pr= oblem that may require multi-faceted solutions.. and enhanced CNAM + being = only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a = utility worker before I let them into my house to make repairs. I would wa= nt some validation that the call to me to reconfirm the appointments was in= fact from the utility in question. From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it... it may eliminate the need for other forms of caller i= dentification beyond what STIR will provide, depending on the specific use = case. For example, a credit card company may choose to rely entirely on STI= R before allowing a card to be unblocked by an IVR (and as I said earlier, = many companies do it today). In other use cases, the TN alone is not suffic= ient information - my health care provider will want to know which member o= f the family is calling. I agree that ANI is already broadly used to improve customer service today.= However, it is not usually deemed as a secure enough mechanism to validate= the caller (therefore this WG!), except if you are a large organization th= at can leverage things like SS7. STIR would make this type of validation av= ailable to a broader number of companies. Going on a tangent... perhaps this is out of scope, but there is not a lot = of discussion about called party hijacking. Couldn't a man-in-the-middle tr= y to answer calls on my behalf? If my bank is calling me, I want to make su= re it's really them before carrying a conversation, but wouldn't they want = the same? From: , "Pierce A [NTK]" > Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho >, "sti= r@ietf.org" > Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fra= ud however contact centers also use TN as a key to improve information avai= lable to call agents to reduce average time-per-call and increase capacity = of the call center. So I don't agree that STIR would "eliminate the need f= or caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more compan= ies are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for identificati= on. If I call from my home phone number, I'm informed that I don't need to = provide any further identification because my number is on file. Some (all?= ) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this ca= se, the "victim" is a business, unlike the other two scenarios we've listed= so far. Addressing this scenario would actually turn STIR into a feature, given it = would enable contact centers of all sizes to eliminate the need for caller = identification from known TNs. From: Alex Bobotek > Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen >, "Peterson, J= on" > Cc: "stir@ietf.org" >, Richard Shockey >, "'DO= LLY, MARTIN C'" >, 'Robert Sparks' > Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the follo= wing sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is = simply the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the rendere= d information. No issues with leaving this as it's a valid point. Another= (increasing) motivation is to evade network and/or endpoint defenses that = may block based on CPN. So however it's worded, I think it's important to allow for both attack obj= ectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bo= unces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; '= DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" > > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draf= t: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried = in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in= the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [mailto:sti= r-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> > > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [mailto:s= tir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_E6A16181E5FD2F46B962315BB05962D01FC23ABCp2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The user shouldn’t = and wouldn’t – they would trust a third party (often, their car= rier, I suspect) to figure out who can attest to the bankiness of a bank. This is not new – there are a number of existing outfits that do thi= s for web sites. (Example: Avast has a bar graph that shows trustworthiness= .)

 <= /p>

 <= /p>

From: Michael = Hammer [mailto:michael.hammer@yaanatech.com]
Sent: Thursday, November 07, 2013 12:10 PM
To: br@brianrosen.net; Henning Schulzrinne
Cc: Pierce.Gorman@sprint.com; richard@shockey.us; stir@ietf.org; fmo= usinh@cisco.com; cnit@ietf.org
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

 

So, how does the average = user know who is an authority?

(Note, we are not designi= ng for IETF geniuses here.)

 <= /p>

Is some well-known centra= l authority going to certify all of these?

Are each of these going t= o cross-certify all the others? (federated model)

 <= /p>

We need to always answer = that fundamental user question:

Why should I TRUST this i= nformation?

 <= /p>

Mike

 <= /p>

 <= /p>

From: Brian Ro= sen [mailto:br@brianrosen.net]
Sent: Thursday, November 07, 2013 12:03 PM
To: Henning Schulzrinne
Cc: Michael Hammer; Pier= ce.Gorman@sprint.com; Richard Shockey; stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org<= br> Subject: Re: [stir] draft-peterson-stir-threats-00.txt

 

Right.  I believe we can do this pretty easily.=  We probably could have a 100 categories that would have similar auth= orities, and there are classifications maintained by folks like Dun Bradstr= eet that can go even farther.

 

What I think would be substantially harder is to val= idate an entire V/X/J card.  How is a validator to know your nickname = is Fluffy?  Name, phone number and, if a business, a classification, y= es, we can do that.  Content of a business card - very hard.

 

Brian

 

 

On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne <= Henning.Schulzrinne@fcc.gov<= /a>> wrote:

 

Yes, that’s a probl= em, but as long as the number of categories is small, you can build UIs tha= t only render information that’s appropriate to the declaration. For practical reasons, I think the number of useful categories is likely g= oing to be fairly limited:

-   = ;      =  Financial institution (FDIC and a few others)

-   = ;      =  Health care (each health care facility has a gov’t number)

-   = ;      =  Charity (501c3, state registered)

-   = ;      =  Contractor (state-licensed)

-   = ;      =  Public safety organization (police, fire)

-   = ;      =  Lawyer (bar association)

-   = ;      =  Local, state and federal government (.gov in the US)

 <= /p>

I suspect that list encom= passes a large fraction of the fraudulent (impersonation) calls. For all of= the above, at least within a country, it’s pretty clear who can attest to the membership. Yes, this requires some UI work or some = server logic, but these categories and the organizations don’t change= all that often – in most cases, the certifying entities have probabl= y been the same for the past 50+ years. I’m not as worried about figuring out whether the beautician, mortician or flo= rist is licensed and properly identified, although I’m sure we can al= l come up with potential fraud stories.

 <= /p>

From: Michael Hammer [mailto:michael.ham= mer@yaanatech.com]  Sent: Thursday, No= vember 07, 2013 10:28 AM
To: Henning Schulz= rinne; Pierce.Gorman@sprint.com; br@brian= rosen.net; richard@shockey.us
Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org
Subject: RE: [stir= ] draft-peterson-stir-threats-00.txt

 

So, would you trust a cer= tificate from the City of Reston, Virginia police department?

 <= /p>

(Hint:  you can find= Reston on a map, but there is no City of Reston. 

  The only poli= ce are Fairfax County.)

 <= /p>

My concern is that one yo= u dilute or disperse authority, it becomes a free-for-all again, and anybod= y’s guess.

 <= /p>

Mike

 <= /p>

 <= /p>

From: stir-bounces@ietf.o= rg [mailto:stir-bou= nces@ietf.org] On Behalf Of Henning Sc= hulzrinne
Sent: Thursday, No= vember 07, 2013 10:00 AM
To: 'Gorman, Pierc= e A [NTK]'; Brian Rosen; Richard Shockey
Cc: stir@ietf.org List; Fernando Mousinho (fm= ousinh); cnit@ietf.org
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

As a thought experiment, = Kumiko Ono and I had published a draft

 <= /p>

 <= /p>

to allow third parties to= validate property information. If the validating party (e.g., a bank regul= ator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist’s office or, more l= owly, to the health departments rating in a restaurant window, and it can b= e tied to a phone number, this shouldn’t be too hard.

 <= /p>

It’s a bit harder i= f the certifying authority (regulator, Realtor board, local bar association= , …) is not involved.

 <= /p>

Henning=

 <= /p>

From: cnit-bounces@ietf.o= rg [mailto= :cnit-bounces@ietf.org]&nb= sp;On Behalf Of Gorman, Pi= erce A [NTK]
Sent: Thursday, No= vember 07, 2013 9:54 AM
To: Brian Rosen; R= ichard Shockey
Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh)
Subject: Re: [cnit= ] [stir] draft-peterson-stir-threats-00.txt

 

I’ll admit I am not f= amiliar with v/x/jcard encoding differences or the implications of their us= e so I’ll encourage educating me if it isn’t too onerous.

 

I’m not sure what is = the concern with a 3rd&nbs= p;party providing “validation” though.  There are n= umerous examples of 3rd partie= s providing validation of information including NASDAQ, NYSE, Barron’= s, Moody’s, and the federal reserve banking system to name a few.

 

Pierce

 

From: Brian Rosen [m= ailto:br@brianrosen.net]&n= bsp;
Sent: November 06,= 2013 11:59 PM
To: Richard Shocke= y
Cc: Fernando Mousi= nho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

I think this would be a heavy lift.

 

If the responsible entity was a carrier, then it wou= ld have to validate the data, which it has very little basis to validate. &= nbsp;It could get a 3rd party to do the validation, but then it’s put= ting its reputation on the back of some hired hand validator.

 

If the responsibility is the end user/device, then t= he signature has no value.

 

I do not argue that Call-Info is suitable,  it = is.

 

I do question JCARD vs xCard, but that’s an en= coding detail.  All of SIP Is XML described by schema, not json.<= /o:p>

 

Brian

 

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shoc= key.us> wrote:

 

URI for a JCARD in the CA= LL INFO header provisioned by the calling party and ultimately signed by th= e responsible entity.  The carrier could provision this for their mobile or hosted customers.  Enterprises could do this them= selves.  This also has advantages in Enterprise to Enterprise UC as we= ll where the data is derived from the Enterprise “directory” an= d could facilitate end to end PPX to PBX communications especially in point to point video communications.

 <= /p>

There are certainly priva= cy and security issues to be addressed.  The Push vs Pull model. = This really would be PII in the clear but then its done voluntarily.

 <= /p>

There would have to be so= me work around restructuring the Header and adding some parameters but it&#= 8217;s underutilized right now and this Use Case is a perfectly appropriate use.

 <= /p>

 <= /p>

Obviously it would need t= o be signed but we don’t need to worry about that ..yet.<= /o:p>

 <= /p>

From 3261

 <= /p>

20.9 Call-Info

 <= /p>

   The Call-Inf= o header field provides additional information about the<= /p>

   caller or ca= llee, depending on whether it is found in a request or

   response.&nb= sp; The purpose of the URI is described by the "purpose"

   parameter.&n= bsp; The "icon" parameter designates an image suitable as an

   iconic repre= sentation of the caller or callee.  The "info" parameter

   describes th= e caller or callee in general, for example, through a web=

   page.  = The "card" parameter provides a business card, for example, in

   vCard [36] o= r LDIF [37] formats.  Additional tokens can be registered<= /o:p>

   using IANA a= nd the procedures in Section 27.

 <= /p>

   Use of the C= all-Info header field can pose a security risk.  If a

   callee fetch= es the URIs provided by a malicious caller, the callee

   may be at ri= sk for displaying inappropriate or offensive content,

   dangerous or= illegal content, and so on.  Therefore, it is

   RECOMMENDED = that a UA only render the information in the Call-Info

   header field= if it can verify the authenticity of the element that

   originated t= he header field and trusts that element.  This need not

   be the peer = UA; a proxy can insert this header field into requests.

 <= /p>

   Example:

 <= /p>

   Call-Info: &= lt;http://wwww.example.com/alice/photo.jpg> ;purpose=3D= icon,

     = <= http://www.example.com/alice/> ;purpose=3Dinfo

 <= /p>

From: Brian Rosen [m= ailto:br@brianrosen.net]&n= bsp;
Sent: Wednesday, N= ovember 06, 2013 3:41 PM
To: Richard Shocke= y
Cc: Fernando Mousi= nho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

We’ve considered adding some information that = is not number and is not name, but is something like “bank”, wh= ich might have some sort of validation behind it.

 

Is that along the lines you were thinking?

 

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shoc= key.us> wrote:

 

I agree with Pierce here = and respectfully disagree that STIR might eliminate the need for other form= s of caller identification.  Though your use case of credit card validation is a useful one and you are right there are still applicat= ions that use SS7 for things that have nothing to do with call setup. I agr= ee with you STIR may have more applications beyond the obvious ones of real= time session validation.

 <= /p>

It’s been my experi= ence recently that there is a use case for something MORE in the identifica= tion of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list.=

 <= /p>

_________________________= ______________________

cnit mailing list<= o:p>

cnit@ietf.org<= /o:p>

 <= /p>

But your use case of a ba= nk wanting to make sure they could properly identify themselves to the cons= umer before establishing a conversation is exactly what this process is about.  STIR is essential but it’s a multi-face= ted problem that may require multi-faceted solutions.. and enhanced CNAM &#= 43; being only one of them.   Its not unreasonable to discuss tho= se.

 <= /p>

The obviously analogy is = I would want to see some real identification of a utility worker before I l= et them into my house to make repairs.  I would want some validation that the call to me to reconfirm the appointments was in fact f= rom the utility in question.

 <= /p>

 <= /p>

 <= /p>

From: stir-bounces@iet= f.org [mailto:stir-= bounces@ietf.org] On Behalf Of Fernando M= ousinho (fmousinh)
Sent: Tuesday, Nov= ember 05, 2013 6:26 PM
To: Gorman, Pierce= A [NTK]; stir@ietf.org
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

Let me rephrase it… it may elimin= ate the need for other forms of caller identification beyond what STIR will= provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to= be unblocked by an IVR (and as I said earlier, many companies do it today)= . In other use cases, the TN alone is not sufficient information – my= health care provider will want to know which member of the family is calling.

 

I agree that ANI is already broadly use= d to improve customer service today. However, it is not usually deemed as a= secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things= like SS7. STIR would make this type of validation available to a broader n= umber of companies.

 

 

Going on a tangent… perhaps this = is out of scope, but there is not a lot of discussion about called party hi= jacking. Couldn’t a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it’s really th= em before carrying a conversation, but wouldn’t they want the same?&n= bsp;

 

 

From: <Gorman>, "Pierce A = [NTK]" <Pierce.Gorman@sprint.com>
Date: Tuesday, Nov= ember 5, 2013 at 6:05 PM
To: Fernando Mousi= nho <fmousinh@cisco.com>, "= stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir= ] draft-peterson-stir-threats-00.txt

 

I agree with your character= ization of businesses as victim of caller ID fraud however contact centers = also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the c= all center.  So I don’t agree that STIR would “eliminate t= he need for caller identification from known TNs.”<= /p>

 

But perhaps I misunderstood= your last sentence?

 

 

From: Fernando Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05,= 2013 4:34 PM
To: stir@ietf.org Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

I would suggest we add a new attack typ= e to section 3. More and more companies are using the caller ID for account= validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my h= ome phone number, I’m informed that I don’t need to provide any= further identification because my number is on file. Some (all?) companies= that implement this type of validation rely on SS7 today.

 

Ultimately, this is yet another variati= on of impersonation – but in this case, the “victim” is a= business, unlike the other two scenarios we’ve listed so far.=

 

Addressing this scenario would actually= turn STIR into a feature, given it would enable contact centers of all siz= es to eliminate the need for caller identification from known TNs.

 

 

 

From: Alex Bobotek <alex@bobotek.net= >
Date: Tuesday, Oct= ober 1, 2013 at 12:51 PM
To: Brian Rosen &l= t;br@bri= anrosen.net>, "Peterson, Jon" <jon.peterson@neust= ar.biz>
Cc: "stir@ietf.org" <stir@ietf.org>, Richard Shockey <richard@shockey.us>, "'DOLLY, MARTIN C'" <md3135@att.com>, 'Robert Sparks' <= rjspa= rks@nostrum.com>
Subject: Re: [stir= ] draft-peterson-stir-threats-00.txt

 

Jon,

 

Thanks for the response.  The inte= ntion in #1 below is to clarify the following sentence:

 

The primary attack vector is

   therefore one where the at= tacker contrives for the calling telephone

   number in signaling to be = a particular chosen number, one that the

   attacker does not have the= authority to call from, = in order for that

   number to be rendered o= n the terminating side. 

 

This might be misconstrued as indicatin= g that the objective of spoofing is simply the rendering of a spoofed numbe= r on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information.  = ;No issues with leaving this as it’s a valid point.  Another (in= creasing) motivation is to evade network and/or endpoint defenses that may = block based on CPN. 

 

So however it’s worded, I think i= t’s important to allow for both attack objectives of a spoofed presen= tation at the endpoint and in transit.   

 

Regards,

 

Alex

 

> -----Original Message-----<= o:p>

> Brian Rosen

> Sent: Tuesday, October 01, 2013 9:= 29 AM

> To: Peterson, Jon

> Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard

> Shockey

> Subject: Re: [stir] draft-peterson= -stir-threats-00.txt

> 

> Don't think there is much MESSAGE.=   MSRP is about all we see, and XMPP is

> more likely than that.=

> 

> Brian

> 

> On Oct 1, 2013, at 12:24 PM, "= ;Peterson, Jon" <jon.peterson@neustar.biz>

> wrote:

> 

> > Thanks for these notes, Alex.= Some responses below.

> >

> >> Here are several comments= that should feed into the IETF Peterson draft:

> >>

> >> *   Remove any = assumptions that the solution cannot be in-network

> [IMO,

> >> both endpoint and in-netw= ork solutions should be facilitated]

> >

> > Agreed that both in-band and = out-of-band solutions can usually be

> > implemented in either endpoin= ts or in intermediaries of various kinds.

> > If I see text that implies ot= herwise, I'll certainly change it.

> >

> >> *   Add a sessi= onless attack scenario.  A spam payload may be carried in<= /o:p>

> a

> >> SIP INVITE or MESSAGE, wh= ich might contain stock market advice even

> >> in a display name field.&= nbsp; These attacks do NOT require session

> establishment.

> >> More generally, we should= be mindful of the fact that SIP is used in

> >> telephony form more than = voice session setup.

> >

> > Probably if we were going to = include a sessionless attack scenario, it

> > would be with regular text me= ssages (whether carried on the PSTN over

> > TCAP or with some Internet pr= otocol, including MESSAGE) rather than

> > with an INVITE, which typical= ly wouldn't result in a payload being

> > immediately rendered to a use= r. More on this below with your suggested

> text.

> >

> >> Here's some suggested mar= kup:

> >>

> >>

> >> 1.    Repl= ace 2nd sentence of 2nd paragraph of 1.0 Introduction with:

> >>

> >> The primary attack vector= is

> >>  therefore one where= the attacker contrives for the calling telephone

> >> number in signaling to be= a particular chosen number that the

> >> attacker does not have th= e authority to call from.

> >

> > What you want here is to remo= ve the implication that the number will

> > be rendered on the terminatin= g side? While there are some attacks

> > where that isn't significant,= perhaps, I would say it is significant

> > in the primary attack vectors= that concern us.

> >

> >> 2.  Replace 3rd para= graph of 2.1 Endpoints with:

> >>

> >>     S= mart devices are generally based on computers with some degree<= /o:p>

> >> of programmability, the c= apacity to access the Internet, and

> >> capabilities of rendering= text, audio and/or images.  This includes

> >> smart phones, telephone a= pplications on desktop and laptop computers,

> >> IP private branch exchang= es, and so on.

> >

> > I can add the notion that sma= rt devices can render text, audio and/or

> > images as you suggest.=

> >

> >> 3.  Add to 3.3 Attac= k Scenarios:

> >>

> >>     &= nbsp; Impersonation, IP-Mobile Text Message

> >>

> >>     &= nbsp;  An attacker with an computer sends a high volume of SIP MESSAGE=

> >> spam message to IP-enable= d smart phones using randomized calling

> >> party numbers.

> >>

> >>     &= nbsp; Countermeasure: in-band authenticated identity

> >

> > Provided we're talking about = end-to-end SIP use of MESSAGE, agreed

> > that in-band would be the rig= ht countermeasure. I am curious though

> > whether practically speaking = there is enough use of MESSAGE in this

> > fashion that we're actually s= eeing high-volume spam over MESSAGE

> > today. Either way, no problem= having an attack scenario of this form in the

> document.

> >

> > Jon Peterson

> > Neustar, Inc.

> >

> >> Regards,

> >>

> >> Alex

> >>

> >>> -----Original Message= -----

> >>> Of Richard Shockey

> >>> Sent: Monday, Septemb= er 30, 2013 1:11 PM

> >>> To: 'DOLLY, MARTIN C'= ; 'Robert Sparks'

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] d= raft-peterson-stir-threats-00.txt

> >>>

> >>> +1

> >>>

> >>> -----Original Message= -----

> >>> Of DOLLY, MARTIN C

> >>> Sent: Monday, Septemb= er 30, 2013 12:58 PM

> >>> To: Robert Sparks

> >>> Cc: stir@ietf.org

> >>> Subject: Re: [stir] d= raft-peterson-stir-threats-00.txt

> >>>

> >>> Yes, ok

> >>>

> >>> Martin Dolly

> >>> Lead Member of Techni= cal Staff

> >>> Core Network & Go= v't/Regulatory Standards AT&T Labs - Network

> >>> Technology

> >>> +1-609-903-3360

> >>> md3135@att.com=

> >>>

> >>>> On Sep 30, 2013, = at 12:47 PM, "Robert Sparks"

> >>> wrote:

> >>>>=

> >>>>> On 9/26/13 3:= 42 PM, DOLLY, MARTIN C wrote:

> >>>>> With Hadriel = comments incorporated, it is a start

> >>>> Hi Martin -

> >>>>=

> >>>> Just to make sure= - I think you're referring to Hadriel's comments

> >>>> on the

> >>> problem statement doc= ument?

> >>>> I don't think Had= riel's commented directly on stir-threats yet.

> >>>>=

> >>>> In any case, we _= are_ talking about a starting place, not a

> >>>> finished

> >>> product.<= /o:p>

> >>>>=

> >>>> If there's no oth= er objection, I'd like to get Jon to submit the

> >>>> threats

> >>> document as a WG -00 = as soon as it's convenient.

> >>>>=

> >>>> RjS

> >>>>>

> >>>>> -----Original= Message-----

> >>>>> Behalf Of Rus= s Housley

> >>>>> Sent: Thursda= y, September 26, 2013 4:37 PM

> >>>>> To: IETF STIR= Mail List

> >>>>> Subject: Re: = [stir] draft-peterson-stir-threats-00.txt

> >>>>>

> >>>>> It has been s= ix days, I'd like to hear from more people about this

> >>> document.  Marti= n asked for an additional week, so I'm sure we will

> >>> hear from him soon.

> >>>>>

> >>>>> Russ

> >>>>>

> >>>>>

> >>>>>> On Sep 20= , 2013, at 5:23 PM, Russ Housley wrote:

> >>>>>>

> >>>>>>

> >>>>>> Should th= e working group adopt this I-D as the starting point for<= /p>

> >>>>>> the

> >>> STIR threat docuent?<= /span>

> >>>>>>

> >>>>>> Russ

> >>>>> _____________= __________________________________

> >>>>> stir mailing = list

> >>>>> stir@ietf.org

> >>>>=

> >>>> _________________= ______________________________

> >>>> stir mailing list=

> >>>> stir@ietf.org

> >>> _____________________= __________________________

> >>> stir mailing list

> >>> stir@ietf.org<= o:p>

> >>>

> >>> _____________________= __________________________

> >>> stir mailing list

> >>> stir@ietf.org<= o:p>

> >> _________________________= ______________________

> >> stir mailing list<= o:p>

> >

> > _____________________________= __________________

> > stir mailing list=

> 

> __________________________________= _____________

> stir mailing list

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

______________________________________= _________
stir mailing list
stir@ietf.org=
https://www.ietf.org/mailman/listinfo/stir<= /o:p>

 

 

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

 

--_000_E6A16181E5FD2F46B962315BB05962D01FC23ABCp2pxmb13fccnetw_-- From michael.hammer@yaanatech.com Thu Nov 7 09:21:44 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EB621E81FE; Thu, 7 Nov 2013 09:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPE+QagjjTuR; Thu, 7 Nov 2013 09:21:31 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id A4E9C11E822F; Thu, 7 Nov 2013 09:21:09 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 7 Nov 2013 09:21:09 -0800 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQIJuyR31NLy1lMhJkGcqWArv1sc1QINOqbRAr/2giEC0l///wF434JzmR/4cmCAAD+vQIABiMQAgAABSwCAABcWAIA3YVcAgAAInoCAAAXVgIAA6nqAgAB5wgCAAAhegIAAk5aAgACVVgCAAAHaAP//gKwwgACTmgCAAA4fAP//exIAgACINID//3rI4A== Date: Thu, 7 Nov 2013 17:21:07 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEF7EFE@sc9-ex2k10mb1.corp.yaanatech.com> References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7D86@sc9-ex2k10mb1.corp.yaanatech.com> <6A94C6CF-69F6-42D9-9A6C-32361A0A4755@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7E71@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.142] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0095_01CEDBB3.D514C460" MIME-Version: 1.0 Cc: "stir@ietf.org" , "Pierce.Gorman@sprint.com" , "fmousinh@cisco.com" , "cnit@ietf.org" , "richard@shockey.us" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:21:44 -0000 ------=_NextPart_000_0095_01CEDBB3.D514C460 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0096_01CEDBB3.D514C460" ------=_NextPart_001_0096_01CEDBB3.D514C460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree, the user may trust the carrier or someone like FTC or FCC. But, if it goes beyond a small handful, forget it. Bottom line, the average user needs to know that someone has actually gone to the business site and knocked on the door, met the people, and seen that it is a real business. Not, just some fly-by-night operation that logged into some website. Mike From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, November 07, 2013 12:15 PM To: Michael Hammer; br@brianrosen.net Cc: Pierce.Gorman@sprint.com; richard@shockey.us; stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt The user shouldn't and wouldn't - they would trust a third party (often, their carrier, I suspect) to figure out who can attest to the bankiness of a bank. This is not new - there are a number of existing outfits that do this for web sites. (Example: Avast has a bar graph that shows trustworthiness.) From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 12:10 PM To: br@brianrosen.net; Henning Schulzrinne Cc: Pierce.Gorman@sprint.com; richard@shockey.us; stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, how does the average user know who is an authority? (Note, we are not designing for IETF geniuses here.) Is some well-known central authority going to certify all of these? Are each of these going to cross-certify all the others? (federated model) We need to always answer that fundamental user question: Why should I TRUST this information? Mike From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, November 07, 2013 12:03 PM To: Henning Schulzrinne Cc: Michael Hammer; Pierce.Gorman@sprint.com; Richard Shockey; stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Right. I believe we can do this pretty easily. We probably could have a 100 categories that would have similar authorities, and there are classifications maintained by folks like Dun Bradstreet that can go even farther. What I think would be substantially harder is to validate an entire V/X/J card. How is a validator to know your nickname is Fluffy? Name, phone number and, if a business, a classification, yes, we can do that. Content of a business card - very hard. Brian On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne wrote: Yes, that's a problem, but as long as the number of categories is small, you can build UIs that only render information that's appropriate to the declaration. For practical reasons, I think the number of useful categories is likely going to be fairly limited: - Financial institution (FDIC and a few others) - Health care (each health care facility has a gov't number) - Charity (501c3, state registered) - Contractor (state-licensed) - Public safety organization (police, fire) - Lawyer (bar association) - Local, state and federal government (.gov in the US) I suspect that list encompasses a large fraction of the fraudulent (impersonation) calls. For all of the above, at least within a country, it's pretty clear who can attest to the membership. Yes, this requires some UI work or some server logic, but these categories and the organizations don't change all that often - in most cases, the certifying entities have probably been the same for the past 50+ years. I'm not as worried about figuring out whether the beautician, mortician or florist is licensed and properly identified, although I'm sure we can all come up with potential fraud stories. From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 10:28 AM To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; richard@shockey.us Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, would you trust a certificate from the City of Reston, Virginia police department? (Hint: you can find Reston on a map, but there is no City of Reston. The only police are Fairfax County.) My concern is that one you dilute or disperse authority, it becomes a free-for-all again, and anybody's guess. Mike From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, November 07, 2013 10:00 AM To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey Cc: stir@ietf.org List; Fernando Mousinho (fmousinh); cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt As a thought experiment, Kumiko Ono and I had published a draft http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 to allow third parties to validate property information. If the validating party (e.g., a bank regulator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist's office or, more lowly, to the health departments rating in a restaurant window, and it can be tied to a phone number, this shouldn't be too hard. It's a bit harder if the certifying authority (regulator, Realtor board, local bar association, .) is not involved. Henning From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gorman, Pierce A [NTK] Sent: Thursday, November 07, 2013 9:54 AM To: Brian Rosen; Richard Shockey Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I'll admit I am not familiar with v/x/jcard encoding differences or the implications of their use so I'll encourage educating me if it isn't too onerous. I'm not sure what is the concern with a 3rd party providing "validation" though. There are numerous examples of 3rd parties providing validation of information including NASDAQ, NYSE, Barron's, Moody's, and the federal reserve banking system to name a few. Pierce From: Brian Rosen [ mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the data, which it has very little basis to validate. It could get a 3rd party to do the validation, but then it's putting its reputation on the back of some hired hand validator. If the responsibility is the end user/device, then the signature has no value. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey < richard@shockey.us> wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party and ultimately signed by the responsible entity. The carrier could provision this for their mobile or hosted customers. Enterprises could do this themselves. This also has advantages in Enterprise to Enterprise UC as well where the data is derived from the Enterprise "directory" and could facilitate end to end PPX to PBX communications especially in point to point video communications. There are certainly privacy and security issues to be addressed. The Push vs Pull model. This really would be PII in the clear but then its done voluntarily. There would have to be some work around restructuring the Header and adding some parameters but it's underutilized right now and this Use Case is a perfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: < http://wwww.example.com/alice/photo.jpg> ;purpose=icon, < http://www.example.com/alice/> ;purpose=info From: Brian Rosen [ mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name, but is something like "bank", which might have some sort of validation behind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey < richard@shockey.us> wrote: I agree with Pierce here and respectfully disagree that STIR might eliminate the need for other forms of caller identification. Though your use case of credit card validation is a useful one and you are right there are still applications that use SS7 for things that have nothing to do with call setup. I agree with you STIR may have more applications beyond the obvious ones of realtime session validation. It's been my experience recently that there is a use case for something MORE in the identification of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identify themselves to the consumer before establishing a conversation is exactly what this process is about. STIR is essential but it's a multi-faceted problem that may require multi-faceted solutions.. and enhanced CNAM + being only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a utility worker before I let them into my house to make repairs. I would want some validation that the call to me to reconfirm the appointments was in fact from the utility in question. From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it. it may eliminate the need for other forms of caller identification beyond what STIR will provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to be unblocked by an IVR (and as I said earlier, many companies do it today). In other use cases, the TN alone is not sufficient information - my health care provider will want to know which member of the family is calling. I agree that ANI is already broadly used to improve customer service today. However, it is not usually deemed as a secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things like SS7. STIR would make this type of validation available to a broader number of companies. Going on a tangent. perhaps this is out of scope, but there is not a lot of discussion about called party hijacking. Couldn't a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it's really them before carrying a conversation, but wouldn't they want the same? From: , "Pierce A [NTK]" < Pierce.Gorman@sprint.com> Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho < fmousinh@cisco.com>, " stir@ietf.org" < stir@ietf.org> Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fraud however contact centers also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the call center. So I don't agree that STIR would "eliminate the need for caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [ mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more companies are using the caller ID for account validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my home phone number, I'm informed that I don't need to provide any further identification because my number is on file. Some (all?) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this case, the "victim" is a business, unlike the other two scenarios we've listed so far. Addressing this scenario would actually turn STIR into a feature, given it would enable contact centers of all sizes to eliminate the need for caller identification from known TNs. From: Alex Bobotek < alex@bobotek.net> Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen < br@brianrosen.net>, "Peterson, Jon" < jon.peterson@neustar.biz> Cc: " stir@ietf.org" < stir@ietf.org>, Richard Shockey < richard@shockey.us>, "'DOLLY, MARTIN C'" < md3135@att.com>, 'Robert Sparks' < rjsparks@nostrum.com> Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the following sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is simply the rendering of a spoofed number on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information. No issues with leaving this as it's a valid point. Another (increasing) motivation is to evade network and/or endpoint defenses that may block based on CPN. So however it's worded, I think it's important to allow for both attack objectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" < jon.peterson@neustar.biz> > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draft: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> < rjsparks@nostrum.com> > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. ------=_NextPart_001_0096_01CEDBB3.D514C460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree, the user may trust the carrier or someone like FTC or = FCC.

But, if it goes beyond a small handful, forget = it.

 

Bottom line, the average user needs to know that someone has actually =

gone to the business site and knocked on the door, met the people, =

and seen that it is a real business.

Not, just some fly-by-night operation that logged into some = website.

 

Mike

 

 

From:= = Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] =
Sent: Thursday, November 07, 2013 12:15 PM
To: = Michael Hammer; br@brianrosen.net
Cc: = Pierce.Gorman@sprint.com; richard@shockey.us; stir@ietf.org; = fmousinh@cisco.com; cnit@ietf.org
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt

 

The user shouldn’t and wouldn’t – they would trust = a third party (often, their carrier, I suspect) to figure out who can = attest to the bankiness of a bank. This is not new – there are a = number of existing outfits that do this for web sites. (Example: Avast = has a bar graph that shows trustworthiness.)

 

 

From:= = Michael Hammer [mailto:michael.ham= mer@yaanatech.com]
Sent: Thursday, November 07, 2013 = 12:10 PM
To: br@brianrosen.net; Henning = Schulzrinne
Cc: Pierce.Gorman@sprint.com; = richard@shockey.us; stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org
Subject: RE: = [stir] = draft-peterson-stir-threats-00.txt

 

So, how does the average user know who is an = authority?

(Note, we are not designing for IETF geniuses = here.)

 

Is some well-known central authority going to certify all of = these?

Are each of these going to cross-certify all the others? (federated = model)

 

We need to always answer that fundamental user = question:

Why should I TRUST this information?

 

Mike

 

 

From:= = Brian Rosen [mailto:br@brianrosen.net] =
Sent: Thursday, November 07, 2013 12:03 PM
To: = Henning Schulzrinne
Cc: Michael Hammer; Pierce.Gorman@sprint.com; = Richard Shockey; stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org
Subject: Re: = [stir] = draft-peterson-stir-threats-00.txt

 

Right. =  I believe we can do this pretty easily.  We probably could = have a 100 categories that would have similar authorities, and there are = classifications maintained by folks like Dun Bradstreet that can go even = farther.

 

What I think would be substantially harder is to = validate an entire V/X/J card.  How is a validator to know your = nickname is Fluffy?  Name, phone number and, if a business, a = classification, yes, we can do that.  Content of a business card - = very hard.

 

Brian

 

 

On = Nov 7, 2013, at 8:12 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

 

From:=  Michael = Hammer [mailto:michael.hammer@yaanat= ech.com] 
Sent: Thursday, November 07, 2013 = 10:28 AM
To: Henning Schulzrinne; Pierce.Gorman@sprint.com; = br@brianrosen.net; richard@shockey.us
Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt

 

So, would you trust a certificate from the City of Reston, Virginia = police department?

 

(Hint:  you can find Reston on a map, but there is no City of = Reston. 

  The only police are Fairfax = County.)

 

My concern is that one you dilute or disperse authority, it becomes a = free-for-all again, and anybody’s = guess.

 

Mike

 

 

From:=  stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Thursday, November 07, 2013 = 10:00 AM
To: 'Gorman, Pierce A [NTK]'; = Brian Rosen; Richard Shockey
Cc: stir@ietf.org List; Fernando Mousinho = (fmousinh); cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

As a thought experiment, Kumiko Ono and I had published a = draft

 

 

to allow third parties to validate property information. If the = validating party (e.g., a bank regulator) is willing to sign a = certificate, similar in spirit to the framed gold-leaf diplomas in your = dentist’s office or, more lowly, to the health departments rating = in a restaurant window, and it can be tied to a phone number, this = shouldn’t be too hard.

 

It’s a bit harder if the certifying authority (regulator, = Realtor board, local bar association, …) is not = involved.

 

Henning

 

From:=  cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gorman, Pierce A = [NTK]
Sent: Thursday, November 07, 2013 = 9:54 AM
To: Brian Rosen; Richard = Shockey
Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho = (fmousinh)
Subject: Re: [cnit] [stir] = draft-peterson-stir-threats-00.txt

 

I’ll admit I am not familiar with v/x/jcard encoding differences = or the implications of their use so I’ll encourage educating me if = it isn’t too onerous.

 

I’m not sure what is the concern with a 3rd party providing = “validation” though.  There are numerous examples of = 3rd parties = providing validation of information including NASDAQ, NYSE, = Barron’s, Moody’s, and the federal reserve banking system to = name a few.

 

Pierce=

 

From:=  Brian Rosen = [mailto:br@brianrosen.net] 
Sent: November 06, 2013 11:59 = PM
To: Richard = Shockey
Cc: Fernando Mousinho (fmousinh); = Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

I think this would be a heavy = lift.

 

If the responsible entity was a carrier, then it would = have to validate the data, which it has very little basis to validate. =  It could get a 3rd party to do the validation, but then it’s = putting its reputation on the back of some hired hand = validator.

 

If the responsibility is the end user/device, then the = signature has no value.

 

I do not argue that Call-Info is suitable,  it = is.

 

I do question JCARD vs xCard, but that’s an = encoding detail.  All of SIP Is XML described by schema, not = json.

 

Brian

 

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> = wrote:

 

URI for a JCARD in the CALL INFO header provisioned by the calling = party and ultimately signed by the responsible entity.  The carrier = could provision this for their mobile or hosted customers.  = Enterprises could do this themselves.  This also has advantages in = Enterprise to Enterprise UC as well where the data is derived from the = Enterprise “directory” and could facilitate end to end PPX = to PBX communications especially in point to point video = communications.

 

There are certainly privacy and security issues to be = addressed.  The Push vs Pull model.  This really would be PII = in the clear but then its done = voluntarily.

 

There would have to be some work around restructuring the Header and = adding some parameters but it’s underutilized right now and this = Use Case is a perfectly appropriate = use.

 

 

Obviously it would need to be signed but we don’t need to worry = about that ..yet.

 

From 3261

 

20.9 Call-Info

 

   The Call-Info header field provides additional = information about the

   caller or callee, depending on whether it is found in a = request or

   response.  The purpose of the URI is described by = the "purpose"

   parameter.  The "icon" parameter = designates an image suitable as an

   iconic representation of the caller or callee.  The = "info" parameter

   describes the caller or callee in general, for example, = through a web

   page.  The "card" parameter provides a = business card, for example, in

   vCard [36] or LDIF [37] formats.  Additional tokens = can be registered

   using IANA and the procedures in Section = 27.

 

   Use of the Call-Info header field can pose a security = risk.  If a

   callee fetches the URIs provided by a malicious caller, = the callee

   may be at risk for displaying inappropriate or offensive = content,

   dangerous or illegal content, and so on.  = Therefore, it is

   RECOMMENDED that a UA only render the information in the = Call-Info

   header field if it can verify the authenticity of the = element that

   originated the header field and trusts that = element.  This need not

   be the peer UA; a proxy can insert this header field = into requests.

 

   Example:

 

   Call-Info: <http://wwww.example.com/alice/photo.jpg= > ;purpose=3Dicon,

     <http://www.example.com/alice/> = ;purpose=3Dinfo

 

From: Brian = Rosen [mailto:br@brianrosen.net] 
Sent: Wednesday, November 06, 2013 = 3:41 PM
To: Richard = Shockey
Cc: Fernando Mousinho (fmousinh); = Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

We’ve considered adding some information that is = not number and is not name, but is something like “bank”, = which might have some sort of validation behind = it.

 

Is that along the lines you were = thinking?

 

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:

 

I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification.  = Though your use case of credit card validation is a useful one and you = are right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session = validation.

 

It’s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list.

 

_______________________________________________

<= /div>

cnit mailing list

 

But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about.  STIR is essential but = it’s a multi-faceted problem that may require multi-faceted = solutions.. and enhanced CNAM + being only one of them.   Its = not unreasonable to discuss = those.

 

The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. =  I would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in = question.

 

 

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

Let me = rephrase it… it may eliminate the need for other forms of caller = identification beyond what STIR will provide, depending on the specific = use case. For example, a credit card company may choose to rely entirely = on STIR before allowing a card to be unblocked by an IVR (and as I said = earlier, many companies do it today). In other use cases, the TN alone = is not sufficient information – my health care provider will want = to know which member of the family is = calling.

 

I agree = that ANI is already broadly used to improve customer service today. = However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of = companies.

 

 

Going on a = tangent… perhaps this is out of scope, but there is not a lot of = discussion about called party hijacking. Couldn’t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it’s really them before carrying a = conversation, but wouldn’t they want the = same? 

 

 

From: <Gorman&= gt;, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Dat= e: Tuesday, November = 5, 2013 at 6:05 PM
To: Fernando Mousinho <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt

=

 

I agree with your characterization of businesses as victim of caller ID = fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center.  So I don’t agree that = STIR would “eliminate the need for caller identification from = known TNs.”

 

But perhaps I misunderstood your last = sentence?

 

 

From:=  Fernando = Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

I would = suggest we add a new attack type to section 3. More and more companies = are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I’m informed = that I don’t need to provide any further identification because my = number is on file. Some (all?) companies that implement this type of = validation rely on SS7 = today.

 

Ultimately,= this is yet another variation of impersonation – but in this = case, the “victim” is a business, unlike the other two = scenarios we’ve listed so = far.

 

Addressing = this scenario would actually turn STIR into a feature, given it would = enable contact centers of all sizes to eliminate the need for caller = identification from known = TNs.

 

 

 

From: Alex = Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, 2013 = at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, = "Peterson, Jon" <jon.peterson@neustar.biz>
Cc:=  "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, = MARTIN C'" <md3135@att.com>, 'Robert Sparks' = <rjsparks@nostrum.com>
Subject= : Re: [stir] = draft-peterson-stir-threats-00.txt

=

 

Jon,=

 

Thanks for = the response.  The intention in #1 below is to clarify the = following sentence:

 

The primary attack vector = is

  = ; therefore one where the attacker contrives for the calling = telephone

  = ; number in signaling to be a particular chosen number, one that = the

  = ; attacker does not have the authority to call from, in order for = that

  = ; number to be rendered on the terminating side. 

 

This might = be misconstrued as indicating that the objective of spoofing is simply = the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the = rendered information.  No issues with leaving this as it’s a = valid point.  Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on = CPN. 

 

So however = it’s worded, I think it’s important to allow for both attack = objectives of a spoofed presentation at the endpoint and in = transit.   

 

Regards,

 

Alex=

 

> = -----Original Message-----

> Brian = Rosen

> Sent: = Tuesday, October 01, 2013 9:29 = AM

> To: = Peterson, Jon

> = Cc: stir@ietf.org; Alex Bobotek; 'Robert = Sparks'; 'DOLLY, MARTIN C'; = Richard

> = Shockey

> = Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> <= /span>

> Don't = think there is much MESSAGE.  MSRP is about all we see, and XMPP = is

> more = likely than that.

> <= /span>

> = Brian

> <= /span>

> On = Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <jon.peterson@neustar.biz<= /span>>

> = wrote:

> <= /span>

> > = Thanks for these notes, Alex. Some responses = below.

> = >

> = >> Here are several comments that should feed into the IETF = Peterson draft:

> = >>

> = >> *   Remove any assumptions that the solution cannot = be in-network

> = [IMO,

> = >> both endpoint and in-network solutions should be = facilitated]

> = >

> > = Agreed that both in-band and out-of-band solutions can usually = be

> > = implemented in either endpoints or in intermediaries of various = kinds.

> > = If I see text that implies otherwise, I'll certainly change = it.

> = >

> = >> *   Add a sessionless attack scenario.  A spam = payload may be carried in

> = a

> = >> SIP INVITE or MESSAGE, which might contain stock market advice = even

> = >> in a display name field.  These attacks do NOT require = session

> = establishment.

> = >> More generally, we should be mindful of the fact that SIP is = used in

> = >> telephony form more than voice session = setup.

> = >

> > = Probably if we were going to include a sessionless attack scenario, = it

> > = would be with regular text messages (whether carried on the PSTN = over

> > = TCAP or with some Internet protocol, including MESSAGE) rather = than

> > = with an INVITE, which typically wouldn't result in a payload = being

> > = immediately rendered to a user. More on this below with your = suggested

> = text.

> = >

> = >> Here's some suggested = markup:

> = >>

> = >>

> = >> 1.    Replace 2nd sentence of 2nd paragraph of = 1.0 Introduction with:

> = >>

> = >> The primary attack vector = is

> = >>  therefore one where the attacker contrives for the = calling telephone

> = >> number in signaling to be a particular chosen number that = the

> = >> attacker does not have the authority to call = from.

> = >

> > = What you want here is to remove the implication that the number = will

> > = be rendered on the terminating side? While there are some = attacks

> > = where that isn't significant, perhaps, I would say it is = significant

> > = in the primary attack vectors that concern = us.

> = >

> = >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:

> = >>

> = >>     Smart devices are generally based on = computers with some degree

> = >> of programmability, the capacity to access the Internet, = and

> = >> capabilities of rendering text, audio and/or images.  This = includes

> = >> smart phones, telephone applications on desktop and laptop = computers,

> = >> IP private branch exchanges, and so = on.

> = >

> > = I can add the notion that smart devices can render text, audio = and/or

> > = images as you suggest.

> = >

> = >> 3.  Add to 3.3 Attack = Scenarios:

> = >>

> = >>       Impersonation, IP-Mobile Text = Message

> = >>

> = >>        An attacker with an = computer sends a high volume of SIP = MESSAGE

> = >> spam message to IP-enabled smart phones using randomized = calling

> = >> party numbers.

> = >>

> = >>       Countermeasure: in-band = authenticated identity

> = >

> > = Provided we're talking about end-to-end SIP use of MESSAGE, = agreed

> > = that in-band would be the right countermeasure. I am curious = though

> > = whether practically speaking there is enough use of MESSAGE in = this

> > = fashion that we're actually seeing high-volume spam over = MESSAGE

> > = today. Either way, no problem having an attack scenario of this form in = the

> = document.

> = >

> > = Jon Peterson

> > = Neustar, Inc.

> = >

> = >> Regards,

> = >>

> = >> Alex

> = >>

> = >>> -----Original = Message-----

> = >>> Of Richard = Shockey

> = >>> Sent: Monday, September 30, 2013 1:11 = PM

> = >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'

> = >>> Cc: stir@ietf.org<= /span>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> = >>>

> = >>> +1

> = >>>

> = >>> -----Original = Message-----

> = >>> Of DOLLY, MARTIN = C

> = >>> Sent: Monday, September 30, 2013 12:58 = PM

> = >>> To: Robert = Sparks

> = >>> Cc: stir@ietf.org<= /span>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> = >>>

> = >>> Yes, ok

> = >>>

> = >>> Martin Dolly

> = >>> Lead Member of Technical = Staff

> = >>> Core Network & Gov't/Regulatory Standards AT&T Labs = - Network

> = >>> Technology

> = >>> = +1-609-903-3360

> = >>> md3135@att.com=

> = >>>

> = >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"

> = >>> wrote:

> = >>>>

> = >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C = wrote:

> = >>>>> With Hadriel comments incorporated, it is a = start

> = >>>> Hi Martin = -

> = >>>>

> = >>>> Just to make sure - I think you're referring to = Hadriel's comments

> = >>>> on the

> = >>> problem statement = document?

> = >>>> I don't think Hadriel's commented directly on = stir-threats yet.

> = >>>>

> = >>>> In any case, we _are_ talking about a starting place, = not a

> = >>>> finished

> = >>> product.

> = >>>>

> = >>>> If there's no other objection, I'd like to get Jon to = submit the

> = >>>> threats

> = >>> document as a WG -00 as soon as it's = convenient.

> = >>>>

> = >>>> RjS

> = >>>>>

> = >>>>> -----Original = Message-----

> = >>>>> Behalf Of Russ = Housley

> = >>>>> Sent: Thursday, September 26, 2013 4:37 = PM

> = >>>>> To: IETF STIR Mail = List

> = >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> = >>>>>

> = >>>>> It has been six days, I'd like to hear from more = people about this

> = >>> document.  Martin asked for an additional week, so I'm = sure we will

> = >>> hear from him = soon.

> = >>>>>

> = >>>>> Russ

> = >>>>>

> = >>>>>

> = >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley = wrote:

> = >>>>>>

> = >>>>>>

> = >>>>>> Should the working group adopt this I-D as the = starting point for

> = >>>>>> = the

> = >>> STIR threat = docuent?

> = >>>>>>

> = >>>>>> = Russ

> = >>>>> = _______________________________________________

> = >>>>> stir mailing = list

> = >>>>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >>>>

> = >>>> = _______________________________________________

> = >>>> stir mailing = list

> = >>>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >>> = _______________________________________________

> = >>> stir mailing = list

> = >>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >>>

> = >>> = _______________________________________________

> = >>> stir mailing = list

> = >>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >> = _______________________________________________

> = >> stir mailing list

> = >> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >

> > = _______________________________________________

> > = stir mailing list

> = > stir@ietf.org<= /span>

<= p class=3DMsoNormal>> <= /span>

> = _______________________________________________

> stir = mailing list

> stir@ietf.org<= /span>

 

This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir<= /a>

 

------=_NextPart_001_0096_01CEDBB3.D514C460-- ------=_NextPart_000_0095_01CEDBB3.D514C460 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEw NzE3MjEwNlowIwYJKoZIhvcNAQkEMRYEFL/FT7RpvtKB+JKPmrcM0mwLNwaUMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEANNYYm5f0/VNbjtlUldizY1PTp1JnItvXnYHbEMaE CmuHOtH+ZcTpAkvTlNpt/xDvDP4Mtuho+/k87Wd7P5LZIU0EE3VFbC0SEnlfqEBEoNa51NqSX+ly 31k9XN8lS/VSQcrRqDxP39xy+xtNnvLNWSZMmpvXcvhf3i3wJvjlv1hM/uTk725d1v/w9xTtZuwD IK99kUy+L2GQtH/01jqxevS/X1owrKjDVGTqzMG16Gc+MOwH4X0QCFO2ZNPevF3n0yBStPam4nUf m4dmkbwmD9vp2eSGp4Iz4yJbvDU/hos8FxrSJZvkDxmmqg7vCTCZx0PC6Rx1u6Vl1RvsuNzbvwAA AAAAAA== ------=_NextPart_000_0095_01CEDBB3.D514C460-- From Henning.Schulzrinne@fcc.gov Thu Nov 7 09:23:20 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E1C11E8150; Thu, 7 Nov 2013 09:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQGEEYXQknXg; Thu, 7 Nov 2013 09:23:16 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAE211E8208; Thu, 7 Nov 2013 09:22:47 -0800 (PST) Message-ID: From: Henning Schulzrinne To: "'Gorman, Pierce A [NTK]'" , 'Michael Hammer' , "br@brianrosen.net" , "richard@shockey.us" Thread-Topic: [stir] draft-peterson-stir-threats-00.txt Thread-Index: Ac7b2+d8m7MQs/E/Y0C8yrTGiGFz4wAAUJDw Date: Thu, 7 Nov 2013 17:22:46 +0000 References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "fmousinh@cisco.com" , "cnit@ietf.org" Subject: Re: [stir] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:23:20 -0000 Yes, I think category matters. Otherwise, fraudsters will register an authe= ntic shell company (which they already do) and will be "authentic" (i.e., t= hey have a record with the state of registration), but peddle Ponzi schemes= or pretend to collect money for starving, blind police officers with cance= r.=20 You, separately, could have entities that provide business reputation servi= ces, such as the Better Business Bureau. However, as BBB illustrates, this = is not an easy job. (Google BBB and some of the "issues" they have had.) Many of the entities you name are primarily in the business of attesting to= business-to-business creditworthiness. That's interesting if you're about = to sell something to the caller or buy their bonds (ignoring the AAA-rated = mortgage junk), but not all that useful for consumers. Most consumer-facing= businesses are too small to have much useful information with most of thes= e rating entities. -----Original Message----- From: Gorman, Pierce A [NTK] [mailto:Pierce.Gorman@sprint.com]=20 Sent: Thursday, November 07, 2013 12:10 PM To: Henning Schulzrinne; 'Michael Hammer'; br@brianrosen.net; richard@shock= ey.us Cc: stir@ietf.org; cnit@ietf.org; fmousinh@cisco.com Subject: RE: [stir] draft-peterson-stir-threats-00.txt In addition to the examples of certifying organizations that Henning provid= ed, there are Barron's, Moody's, Dun & Bradstreet, Equifax, Experion, KPMG,= Deloitte-Touche, NYSE, NASDAQ, et cetera. Do we even need the categories, or do we just need 3rd parties to be expert= at vetting the authenticity of an originator? If it is the latter, I rema= in unconcerned about the business model aspects. Pierce -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: November 07, 2013 10:13 AM To: 'Michael Hammer'; Gorman, Pierce A [NTK]; br@brianrosen.net; richard@sh= ockey.us Cc: stir@ietf.org; cnit@ietf.org; fmousinh@cisco.com Subject: Re: [stir] draft-peterson-stir-threats-00.txt Yes, that's a problem, but as long as the number of categories is small, yo= u can build UIs that only render information that's appropriate to the decl= aration. For practical reasons, I think the number of useful categories is = likely going to be fairly limited: - Financial institution (FDIC and a few others) - Health care (each health care facility has a gov't number) - Charity (501c3, state registered) - Contractor (state-licensed) - Public safety organization (police, fire) - Lawyer (bar association) - Local, state and federal government (.gov in the US) I suspect that list encompasses a large fraction of the fraudulent (imperso= nation) calls. For all of the above, at least within a country, it's pretty= clear who can attest to the membership. Yes, this requires some UI work or= some server logic, but these categories and the organizations don't change= all that often - in most cases, the certifying entities have probably been= the same for the past 50+ years. I'm not as worried about figuring out whe= ther the beautician, mortician or florist is licensed and properly identifi= ed, although I'm sure we can all come up with potential fraud stories. From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 10:28 AM To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; richa= rd@shockey.us Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, would you trust a certificate from the City of Reston, Virginia police = department? (Hint: you can find Reston on a map, but there is no City of Reston. The only police are Fairfax County.) My concern is that one you dilute or disperse authority, it becomes a free-= for-all again, and anybody's guess. Mike From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, November 07, 2013 10:00 AM To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey Cc: stir@ietf.org List; Fernando Mousinho (fmousinh);= cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt As a thought experiment, Kumiko Ono and I had published a draft http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 to allow third parties to validate property information. If the validating = party (e.g., a bank regulator) is willing to sign a certificate, similar in= spirit to the framed gold-leaf diplomas in your dentist's office or, more = lowly, to the health departments rating in a restaurant window, and it can = be tied to a phone number, this shouldn't be too hard. It's a bit harder if the certifying authority (regulator, Realtor board, lo= cal bar association, ...) is not involved. Henning From: cnit-bounces@ietf.org [mailto:cnit-boun= ces@ietf.org] On Behalf Of Gorman, P= ierce A [NTK] Sent: Thursday, November 07, 2013 9:54 AM To: Brian Rosen; Richard Shockey Cc: stir@ietf.org List; cnit@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I'll admit I am not familiar with v/x/jcard encoding differences or the imp= lications of their use so I'll encourage educating me if it isn't too onero= us. I'm not sure what is the concern with a 3rd party providing "validation" th= ough. There are numerous examples of 3rd parties providing validation of i= nformation including NASDAQ, NYSE, Barron's, Moody's, and the federal reser= ve banking system to name a few. Pierce From: Brian Rosen [mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the= data, which it has very little basis to validate. It could get a 3rd part= y to do the validation, but then it's putting its reputation on the back of= some hired hand validator. If the responsibility is the end user/device, then the signature has no val= ue. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is= XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey > wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party an= d ultimately signed by the responsible entity. The carrier could provision= this for their mobile or hosted customers. Enterprises could do this them= selves. This also has advantages in Enterprise to Enterprise UC as well wh= ere the data is derived from the Enterprise "directory" and could facilitat= e end to end PPX to PBX communications especially in point to point video c= ommunications. There are certainly privacy and security issues to be addressed. The Push = vs Pull model. This really would be PII in the clear but then its done vol= untarily. There would have to be some work around restructuring the Header and adding= some parameters but it's underutilized right now and this Use Case is a pe= rfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that = ..yet. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From Pierce.Gorman@sprint.com Thu Nov 7 10:40:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1398221E81F1; Thu, 7 Nov 2013 10:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.969 X-Spam-Level: X-Spam-Status: No, score=-2.969 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmnTy8RGuv-U; Thu, 7 Nov 2013 10:40:40 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id A943421E81E7; Thu, 7 Nov 2013 10:39:27 -0800 (PST) Received: from mail93-db9-R.bigfish.com (10.174.16.243) by DB9EHSOBE023.bigfish.com (10.174.14.86) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 18:39:25 +0000 Received: from mail93-db9 (localhost [127.0.0.1]) by mail93-db9-R.bigfish.com (Postfix) with ESMTP id 495F11C0356; Thu, 7 Nov 2013 18:39:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.229.32.56; KIP:(null); UIP:(null); IPV:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI X-SpamScore: -24 X-BigFish: VS-24(zz98dI9371I542I1fdcIzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h1155h) Received-SPF: pass (mail93-db9: domain of sprint.com designates 144.229.32.56 as permitted sender) client-ip=144.229.32.56; envelope-from=Pierce.Gorman@sprint.com; helo=pdaasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail93-db9 (localhost.localdomain [127.0.0.1]) by mail93-db9 (MessageSwitch) id 1383849561883559_8282; Thu, 7 Nov 2013 18:39:21 +0000 (UTC) Received: from DB9EHSMHS025.bigfish.com (unknown [10.174.16.240]) by mail93-db9.bigfish.com (Postfix) with ESMTP id CAB3E3E00A5; Thu, 7 Nov 2013 18:39:21 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by DB9EHSMHS025.bigfish.com (10.174.14.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 18:39:20 +0000 Received: from PLSWEH03.ad.sprint.com (plsweh03.corp.sprint.com [144.226.242.132]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA7IdISC000975 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2013 12:39:18 -0600 Received: from pdawm10a.ad.sprint.com ([144.226.111.33]) by PLSWEH03.ad.sprint.com ([144.226.242.132]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 12:39:17 -0600 From: "Gorman, Pierce A [NTK]" To: Michael Hammer , "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" Thread-Topic: [cnit] [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQHO2nc0UwzhVvA23kepk+N3A5gBjZoXQFMAgAIHxfuAAI6Z8IAAbRgAgAAH4QCAAAxlAIAADh8AgAAB9wCAAAFPgIAAAa+AgAAUxyA= Date: Thu, 7 Nov 2013 18:39:17 +0000 Message-ID: References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7D86@sc9-ex2k10mb1.corp.yaanatech.com> <6A94C6CF-69F6-42D9-9A6C-32361A0A4755@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF7E71@sc9-ex2k10mb1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBEF7EFE@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEF7EFE@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.229.76.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "stir@ietf.org" , "cnit@ietf.org" , "richard@shockey.us" , "fmousinh@cisco.com" Subject: Re: [stir] [cnit] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:40:54 -0000 The issues we keep circling are trust and value. For practical reasons, carriers are going to continue to want to use CNAM c= learinghouse information providers, and consumers are going to continue to = want better information. If the consumes are like me, they're going to be = willing to pay a little extra to get better information, or be unwilling to= pay but willing to just deal with liars calling. Nobody is forced to answ= er or to believe anything they're told if they do answer. Mechanisms are already in place to support real-time per-call per-subscribe= r 3rd party telecommunications services. If KPMG or Prudential started off= ering information security services for CNAM, I'd pay for it. IMHO, the focus of STIR and CNIT WGs should be mechanisms which 1) validate= that a calling number is authentic (not trustworthy), and 2) provide a car= rier or CNAM provider a key for retrieving (potentially untrustworthy) inf= ormation that has been associated with that calling number. Ensuring the trustworthiness of the calling number or the information assoc= iated with the calling number should not be the domain of the IETF. If trustworthiness of information is VALUABLE (and we've described multiple= examples of this being so), then the marketplace can determine how the val= ue is to be extracted and applied. Pierce -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: November 07, 2013 11:21 AM To: Henning.Schulzrinne@fcc.gov; br@brianrosen.net Cc: stir@ietf.org; Gorman, Pierce A [NTK]; fmousinh@cisco.com; cnit@ietf.or= g; richard@shockey.us Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt Agree, the user may trust the carrier or someone like FTC or FCC. But, if it goes beyond a small handful, forget it. Bottom line, the average user needs to know that someone has actually gone to the business site and knocked on the door, met the people, and seen that it is a real business. Not, just some fly-by-night operation that logged into some website. Mike From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, November 07, 2013 12:15 PM To: Michael Hammer; br@brianrosen.net Cc: Pierce.Gorman@sprint.com; richard@shockey.us; stir@ietf.org; fmousinh@c= isco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt The user shouldn't and wouldn't - they would trust a third party (often, th= eir carrier, I suspect) to figure out who can attest to the bankiness of a = bank. This is not new - there are a number of existing outfits that do this= for web sites. (Example: Avast has a bar graph that shows trustworthiness.= ) From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 12:10 PM To: br@brianrosen.net; Henning Schulzrinne Cc: Pierce.Gorman@sprint.com; richard@shockey.us; stir@ietf.org; fmousinh@c= isco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, how does the average user know who is an authority? (Note, we are not designing for IETF geniuses here.) Is some well-known central authority going to certify all of these? Are each of these going to cross-certify all the others? (federated model) We need to always answer that fundamental user question: Why should I TRUST this information? Mike From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, November 07, 2013 12:03 PM To: Henning Schulzrinne Cc: Michael Hammer; Pierce.Gorman@sprint.com; Richard Shockey; stir@ietf.or= g; fmousinh@cisco.com; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Right. I believe we can do this pretty easily. We probably could have a 100 categories that would have similar authorities, and there are classific= ations maintained by folks like Dun Bradstreet that can go even farther. What I think would be substantially harder is to validate an entire V/X/J c= ard. How is a validator to know your nickname is Fluffy? Name, phone numb= er and, if a business, a classification, yes, we can do that. Content of a= business card - very hard. Brian On Nov 7, 2013, at 8:12 AM, Henning Schulzrinne wrote: Yes, that's a problem, but as long as the number of categories is small, yo= u can build UIs that only render information that's appropriate to the decl= aration. For practical reasons, I think the number of useful categories is = likely going to be fairly limited: - Financial institution (FDIC and a few others) - Health care (each health care facility has a gov't number) - Charity (501c3, state registered) - Contractor (state-licensed) - Public safety organization (police, fire) - Lawyer (bar association) - Local, state and federal government (.gov in the US) I suspect that list encompasses a large fraction of the fraudulent (impersonation) calls. For all of the above, at least within a country, it'= s pretty clear who can attest to the membership. Yes, this requires some UI= work or some server logic, but these categories and the organizations don'= t change all that often - in most cases, the certifying entities have proba= bly been the same for the past 50+ years. I'm not as worried about figuring= out whether the beautician, mortician or florist is licensed and properly = identified, although I'm sure we can all come up with potential fraud stori= es. From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, November 07, 2013 10:28 AM To: Henning Schulzrinne; Pierce.Gorman@sprint.com; br@brianrosen.net; richa= rd@shockey.us Cc: stir@ietf.org; fmousinh@cisco.com; cnit@ietf.org Subject: RE: [stir] draft-peterson-stir-threats-00.txt So, would you trust a certificate from the City of Reston, Virginia police = department? (Hint: you can find Reston on a map, but there is no City of Reston. The only police are Fairfax County.) My concern is that one you dilute or disperse authority, it becomes a free-= for-all again, and anybody's guess. Mike From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulz= rinne Sent: Thursday, November 07, 2013 10:00 AM To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey Cc: stir@ietf.org List; Fernando Mousinho (fmousinh= ); cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt As a thought experiment, Kumiko Ono and I had published a draft http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 to allow third parties to validate property information. If the validating = party (e.g., a bank regulator) is willing to sign a certificate, similar in= spirit to the framed gold-leaf diplomas in your dentist's office or, more = lowly, to the health departments rating in a restaurant window, and it can = be tied to a phone number, this shouldn't be too hard. It's a bit harder if the certifying authority (regulator, Realtor board, lo= cal bar association, .) is not involved. Henning From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gorman= , Pierce A [NTK] Sent: Thursday, November 07, 2013 9:54 AM To: Brian Rosen; Richard Shockey Cc: stir@ietf.org List; cni= t@ietf.org; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I'll admit I am not familiar with v/x/jcard encoding differences or the imp= lications of their use so I'll encourage educating me if it isn't too onero= us. I'm not sure what is the concern with a 3rd party providing "validation" though. There are numerous examples of 3rd parties providing validation of= information including NASDAQ, NYSE, Barron's, Moody's, and the federal res= erve banking system to name a few. Pierce From: Brian Rosen [ mailto:br@brianrosen.net] Sent: November 06, 2013 11:59 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List; cnit@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the= data, which it has very little basis to validate. It could get a 3rd part= y to do the validation, but then it's putting its reputation on the back of= some hired hand validator. If the responsibility is the end user/device, then the signature has no val= ue. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is= XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey < r= ichard@shockey.us> wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party an= d ultimately signed by the responsible entity. The carrier could provision= this for their mobile or hosted customers. Enterprises could do this them= selves. This also has advantages in Enterprise to Enterprise UC as well wh= ere the data is derived from the Enterprise "directory" and could facilitat= e end to end PPX to PBX communications especially in point to point video c= ommunications. There are certainly privacy and security issues to be addressed. The Push = vs Pull model. This really would be PII in the clear but then its done vol= untarily. There would have to be some work around restructuring the Header and adding= some parameters but it's underutilized right now and this Use Case is a pe= rfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that = ..yet. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From wolfgang.beck01@googlemail.com Thu Nov 7 09:47:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C74821E8127 for ; Thu, 7 Nov 2013 09:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAL0J02surqz for ; Thu, 7 Nov 2013 09:47:27 -0800 (PST) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2C521E81C2 for ; Thu, 7 Nov 2013 09:47:11 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p6so615723vbe.32 for ; Thu, 07 Nov 2013 09:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=b4ZIY7lTepedHbRosRdQlho2LI5OV/Ir2ivbkPb3kdk=; b=taKXj+g1RKU5RJC/Yl9DkgjXCa4TZeTiV7IRdjOq9wzysBJfIo6JtrEBSmwjhUek3H G3u/Ljz7yt9NFsyxqZRgQVusQrIB+4w4sQFGb/jRRALDJaXi8iQ+40Zqsh/GQwwt8wbL RKrq9lqeW0jjI9gHuvSrdn8gk0JBOannVyUaeuw4wyl0eyRg2F0OgEM3v0SPQdRNQeUp d29Rm1agnJ7KvjaPAKNwEmy8LEzwHrwAWUcAil+1BlXLPnkUIq4uJIeuny0lPT9riDV9 soxJ/8k6O/OCQofpf0uLc4djXXLe5w081bE3f5C188DUkD8qJyT6v0hzOO+PkglJS1j5 HWEA== MIME-Version: 1.0 X-Received: by 10.58.107.204 with SMTP id he12mr7565570veb.26.1383846430425; Thu, 07 Nov 2013 09:47:10 -0800 (PST) Received: by 10.58.45.169 with HTTP; Thu, 7 Nov 2013 09:47:10 -0800 (PST) Date: Thu, 7 Nov 2013 18:47:10 +0100 Message-ID: From: Wolfgang Beck To: stir@ietf.org Content-Type: multipart/alternative; boundary=089e0116037ae8cd9104ea99dac8 X-Mailman-Approved-At: Thu, 07 Nov 2013 13:18:29 -0800 Subject: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:47:31 -0000 --089e0116037ae8cd9104ea99dac8 Content-Type: text/plain; charset=ISO-8859-1 Here's a half-baked idea: when a call c1 arives from , I send a DYPTC SIP request message outside of this call back to . The DYPTC request carries some headers that describe c1, eg. the original from and to. - if the receiving UA is indeed , it responds with 200 OK. The origin of call c1 is now verified. - if was spoofed by somebody, the request will arrive at a UA that does not know about the call described by DYPTC. It responds with 404 Not Found - if was spoofed and there is no UA reachable, the request will time out or the network will generate a 404 Not found. Whenever I dont receive a 200 OK on a DYPTC, the calling number could not be verified. So far all methods to determine a party that can verify a number seem to boil down to one of the two groups: 1. create a new database, replicated from the telcos' databases, that can be accessed by end devices. That's what iMessage, whatsapp, and VIPR try to do. Accurately replicating a fairly dynamic database without its cooperation is a challenge. 2. create a way so that end devices can directly query the telcos' databases. DNS is an obvious candidate for this. However, accessing the database itself is not enough. The end device would have to replicate all routing decisions the telcos make. All discussions about PBXs and number portability are essentially about the routing inside the telcos. Why not just use the existing platform to verify calling numbers? Wolfgang Beck --089e0116037ae8cd9104ea99dac8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Here's a half-baked idea: whe= n a call c1 arives from <a>, I send a DYPTC SIP request message outsi= de of this call back to <a>. The DYPTC request carries some headers t= hat describe c1, eg. the original from and to.

- if the receiving UA is indeed <a>, it responds with = 200 OK. The origin of call c1 is now verified.

- if <a= > was spoofed by somebody, the request will arrive at a UA that does not= know about the call described by DYPTC. It responds with 404 Not Found

- if <a> was spoofed and there is no UA reachable, the= request will time out or the network will generate a 404 Not found.
Whenever I dont receive a 200 OK on a DYPTC, the calling number= could not be verified.

So far all methods to determine a party that can = verify a number seem to boil down to one of the two groups:

1.= create a new database, replicated from the telcos' databases, that can= be accessed by end devices. That's what iMessage, whatsapp, and VIPR t= ry to do. Accurately replicating a fairly dynamic database without its coop= eration is a challenge.

2. create a way so that end devices can directly query the telcos= ' databases. DNS is an obvious candidate for this.

However= , accessing the database itself is not enough. The end device would have to= replicate all routing decisions the telcos make. All discussions about PBX= s and number portability are essentially about the routing inside the telco= s.

Why not just use the existing platform to verify calling numbers?=


Wolfgang Beck
--089e0116037ae8cd9104ea99dac8-- From jon.peterson@neustar.biz Thu Nov 7 13:26:41 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E046B21E818D for ; Thu, 7 Nov 2013 13:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDUoS+7oI7BV for ; Thu, 7 Nov 2013 13:26:37 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id CD88D21E80B6 for ; Thu, 7 Nov 2013 13:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383860195; x=1699219102; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=B8sdYie6RCcFonEu4XIr78ueWmL5VsIoT1YWngWQKYU=; b=pwPOvFD8Y857l3NzxX1eKZS21w3SbZylX2XL6G/LwjRLqSPypfJmMQDITQ1AgY zzpAUevdL0j8+7hwjcU0KDag== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.35148809; Thu, 07 Nov 2013 16:36:34 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.5]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 7 Nov 2013 16:26:25 -0500 From: "Peterson, Jon" To: 'Wolfgang Beck' , "'stir@ietf.org'" Thread-Topic: [stir] new SIP Method DYPTC 'Did You Place This Call?' Thread-Index: AQHO2/759gVKPWtkUE25HikC9AzlgJoaSAi0 Date: Thu, 7 Nov 2013 21:26:25 +0000 Message-ID: <596979554D802045BBD45C051A4399E40D40C61A@STNTEXMB10.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.15.96] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: KTmHUwPkCkz4Kwmm16iwPQ== Content-Type: multipart/alternative; boundary="_000_596979554D802045BBD45C051A4399E40D40C61ASTNTEXMB10cisne_" MIME-Version: 1.0 Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:26:42 -0000 --_000_596979554D802045BBD45C051A4399E40D40C61ASTNTEXMB10cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmFyaW91cyAiY2FsbGJhY2siIG1lY2hhbmlzbXMgYWxvbmcgdGhlc2UgbGluZXMgaGF2ZSBiZWVu IGNvbnNpZGVyZWQsIGFuZCB0aGVyZSBhcmUga25vd24gbGltaXRhdGlvbnMgb2YgdGhlc2UgbWVj aGFuaXNtcywgbW9zdCBvZiB3aGljaCByZXN1bHQgZnJvbSB0aGUgZmFjdCB0aGF0IHBsYWNpbmcg YSBjYWxsIGZyb20gYSBudW1iZXIgZG9lcyBub3QgZ3VhcmFudGVlIHRoYXQgYSByZXR1cm5lZCBj YWxsIHdvdWxkIHJlYWNoIHRoZSBzYW1lIGVuZHBvaW50IGluc3RhbmNlLiBHYXRld2F5cywgY2Fs bCBjZW50ZXJzLCB1c2VycyB3aXRoIG11bHRpcGxlIGNvbmN1cnJlbnRseSByZWdpc3RlcmVkIGRl dmljZXMsIGFsbCBvZiBvdXIgImRvY3RvcidzIG9mZmljZSIgdXNlIGNhc2VzIGFuZCByZWxhdGVk IGNvbmZpZ3VyYXRpb25zIHNob3cgd2h5IGFwcHJvYWNoZXMgYWxvbmcgdGhlc2UgbGluZXMgYXJl IGluc3VmZmljaWVudC4NCg0KSm9uIFBldGVyc29uDQpOZXVzdGFyLCBpbmMuDQoNCg0KDQpTZW50 IHdpdGggR29vZCAod3d3Lmdvb2QuY29tKQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBXb2xmZ2FuZyBCZWNrIFt3b2xmZ2FuZy5iZWNrMDFAZ29vZ2xlbWFpbC5jb208bWFp bHRvOndvbGZnYW5nLmJlY2swMUBnb29nbGVtYWlsLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgTm92 ZW1iZXIgMDcsIDIwMTMgMDQ6MTggUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzogc3RpckBp ZXRmLm9yZw0KU3ViamVjdDogW3N0aXJdIG5ldyBTSVAgTWV0aG9kIERZUFRDICdEaWQgWW91IFBs YWNlIFRoaXMgQ2FsbD8nDQoNCkhlcmUncyBhIGhhbGYtYmFrZWQgaWRlYTogd2hlbiBhIGNhbGwg YzEgYXJpdmVzIGZyb20gPGE+LCBJIHNlbmQgYSBEWVBUQyBTSVAgcmVxdWVzdCBtZXNzYWdlIG91 dHNpZGUgb2YgdGhpcyBjYWxsIGJhY2sgdG8gPGE+LiBUaGUgRFlQVEMgcmVxdWVzdCBjYXJyaWVz IHNvbWUgaGVhZGVycyB0aGF0IGRlc2NyaWJlIGMxLCBlZy4gdGhlIG9yaWdpbmFsIGZyb20gYW5k IHRvLg0KDQotIGlmIHRoZSByZWNlaXZpbmcgVUEgaXMgaW5kZWVkIDxhPiwgaXQgcmVzcG9uZHMg d2l0aCAyMDAgT0suIFRoZSBvcmlnaW4gb2YgY2FsbCBjMSBpcyBub3cgdmVyaWZpZWQuDQoNCi0g aWYgPGE+IHdhcyBzcG9vZmVkIGJ5IHNvbWVib2R5LCB0aGUgcmVxdWVzdCB3aWxsIGFycml2ZSBh dCBhIFVBIHRoYXQgZG9lcyBub3Qga25vdyBhYm91dCB0aGUgY2FsbCBkZXNjcmliZWQgYnkgRFlQ VEMuIEl0IHJlc3BvbmRzIHdpdGggNDA0IE5vdCBGb3VuZA0KDQotIGlmIDxhPiB3YXMgc3Bvb2Zl ZCBhbmQgdGhlcmUgaXMgbm8gVUEgcmVhY2hhYmxlLCB0aGUgcmVxdWVzdCB3aWxsIHRpbWUgb3V0 IG9yIHRoZSBuZXR3b3JrIHdpbGwgZ2VuZXJhdGUgYSA0MDQgTm90IGZvdW5kLg0KDQpXaGVuZXZl ciBJIGRvbnQgcmVjZWl2ZSBhIDIwMCBPSyBvbiBhIERZUFRDLCB0aGUgY2FsbGluZyBudW1iZXIg Y291bGQgbm90IGJlIHZlcmlmaWVkLg0KDQpTbyBmYXIgYWxsIG1ldGhvZHMgdG8gZGV0ZXJtaW5l IGEgcGFydHkgdGhhdCBjYW4gdmVyaWZ5IGEgbnVtYmVyIHNlZW0gdG8gYm9pbCBkb3duIHRvIG9u ZSBvZiB0aGUgdHdvIGdyb3VwczoNCg0KMS4gY3JlYXRlIGEgbmV3IGRhdGFiYXNlLCByZXBsaWNh dGVkIGZyb20gdGhlIHRlbGNvcycgZGF0YWJhc2VzLCB0aGF0IGNhbiBiZSBhY2Nlc3NlZCBieSBl bmQgZGV2aWNlcy4gVGhhdCdzIHdoYXQgaU1lc3NhZ2UsIHdoYXRzYXBwLCBhbmQgVklQUiB0cnkg dG8gZG8uIEFjY3VyYXRlbHkgcmVwbGljYXRpbmcgYSBmYWlybHkgZHluYW1pYyBkYXRhYmFzZSB3 aXRob3V0IGl0cyBjb29wZXJhdGlvbiBpcyBhIGNoYWxsZW5nZS4NCg0KMi4gY3JlYXRlIGEgd2F5 IHNvIHRoYXQgZW5kIGRldmljZXMgY2FuIGRpcmVjdGx5IHF1ZXJ5IHRoZSB0ZWxjb3MnIGRhdGFi YXNlcy4gRE5TIGlzIGFuIG9idmlvdXMgY2FuZGlkYXRlIGZvciB0aGlzLg0KDQpIb3dldmVyLCBh Y2Nlc3NpbmcgdGhlIGRhdGFiYXNlIGl0c2VsZiBpcyBub3QgZW5vdWdoLiBUaGUgZW5kIGRldmlj ZSB3b3VsZCBoYXZlIHRvIHJlcGxpY2F0ZSBhbGwgcm91dGluZyBkZWNpc2lvbnMgdGhlIHRlbGNv cyBtYWtlLiBBbGwgZGlzY3Vzc2lvbnMgYWJvdXQgUEJYcyBhbmQgbnVtYmVyIHBvcnRhYmlsaXR5 IGFyZSBlc3NlbnRpYWxseSBhYm91dCB0aGUgcm91dGluZyBpbnNpZGUgdGhlIHRlbGNvcy4NCg0K V2h5IG5vdCBqdXN0IHVzZSB0aGUgZXhpc3RpbmcgcGxhdGZvcm0gdG8gdmVyaWZ5IGNhbGxpbmcg bnVtYmVycz8NCg0KDQpXb2xmZ2FuZyBCZWNrDQo= --_000_596979554D802045BBD45C051A4399E40D40C61ASTNTEXMB10cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQo8aHRtbD4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iZ2VuZXJhdG9y IiBjb250ZW50PSJIVE1MIFRpZHkgZm9yIFdpbmRvd3MgKHZlcnMgMjUgTWFyY2ggMjAwOSksIHNl ZSB3d3cudzMub3JnIj4NCjx0aXRsZT48L3RpdGxlPg0KPC9oZWFkPg0KPGJvZHk+DQpWYXJpb3Vz ICZxdW90O2NhbGxiYWNrJnF1b3Q7IG1lY2hhbmlzbXMgYWxvbmcgdGhlc2UgbGluZXMgaGF2ZSBi ZWVuIGNvbnNpZGVyZWQsIGFuZCB0aGVyZSBhcmUga25vd24gbGltaXRhdGlvbnMgb2YgdGhlc2Ug bWVjaGFuaXNtcywgbW9zdCBvZiB3aGljaCByZXN1bHQgZnJvbSB0aGUgZmFjdCB0aGF0IHBsYWNp bmcgYSBjYWxsIGZyb20gYSBudW1iZXIgZG9lcyBub3QgZ3VhcmFudGVlIHRoYXQgYSByZXR1cm5l ZCBjYWxsIHdvdWxkIHJlYWNoIHRoZSBzYW1lIGVuZHBvaW50DQogaW5zdGFuY2UuIEdhdGV3YXlz LCBjYWxsIGNlbnRlcnMsIHVzZXJzIHdpdGggbXVsdGlwbGUgY29uY3VycmVudGx5IHJlZ2lzdGVy ZWQgZGV2aWNlcywgYWxsIG9mIG91ciAmcXVvdDtkb2N0b3IncyBvZmZpY2UmcXVvdDsgdXNlIGNh c2VzIGFuZCByZWxhdGVkIGNvbmZpZ3VyYXRpb25zIHNob3cgd2h5IGFwcHJvYWNoZXMgYWxvbmcg dGhlc2UgbGluZXMgYXJlIGluc3VmZmljaWVudC48YnI+DQo8YnI+DQpKb24gUGV0ZXJzb248YnI+ DQpOZXVzdGFyLCBpbmMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KU2VudCB3aXRoIEdvb2QgKHd3 dy5nb29kLmNvbSk8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCjxiPkZyb206Jm5ic3A7PC9iPldvbGZnYW5nIEJlY2sgWzxhIGhyZWY9Im1haWx0bzp3b2xm Z2FuZy5iZWNrMDFAZ29vZ2xlbWFpbC5jb20iPndvbGZnYW5nLmJlY2swMUBnb29nbGVtYWlsLmNv bTwvYT5dPGJyPg0KPGI+U2VudDombmJzcDs8L2I+VGh1cnNkYXksIE5vdmVtYmVyIDA3LCAyMDEz IDA0OjE4IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZTxicj4NCjxiPlRvOiZuYnNwOzwvYj5zdGly QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDombmJzcDs8L2I+W3N0aXJdIG5ldyBTSVAgTWV0aG9k IERZUFRDICdEaWQgWW91IFBsYWNlIFRoaXMgQ2FsbD8nPGJyPg0KPGJyPg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5IZXJlJ3MgYSBoYWxmLWJha2Vk IGlkZWE6IHdoZW4gYSBjYWxsIGMxIGFyaXZlcyBmcm9tICZsdDthJmd0OywgSSBzZW5kIGEgRFlQ VEMgU0lQIHJlcXVlc3QgbWVzc2FnZSBvdXRzaWRlIG9mIHRoaXMgY2FsbCBiYWNrIHRvICZsdDth Jmd0Oy4gVGhlIERZUFRDIHJlcXVlc3QgY2FycmllcyBzb21lIGhlYWRlcnMgdGhhdCBkZXNjcmli ZSBjMSwgZWcuIHRoZSBvcmlnaW5hbCBmcm9tIGFuZCB0by48YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KLSBpZiB0aGUgcmVjZWl2aW5nIFVBIGlzIGluZGVlZCAmbHQ7YSZndDssIGl0IHJlc3BvbmRz IHdpdGggMjAwIE9LLiBUaGUgb3JpZ2luIG9mIGNhbGwgYzEgaXMgbm93IHZlcmlmaWVkLjxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQotIGlmICZsdDthJmd0OyB3YXMgc3Bvb2ZlZCBieSBzb21lYm9k eSwgdGhlIHJlcXVlc3Qgd2lsbCBhcnJpdmUgYXQgYSBVQSB0aGF0IGRvZXMgbm90IGtub3cgYWJv dXQgdGhlIGNhbGwgZGVzY3JpYmVkIGJ5IERZUFRDLiBJdCByZXNwb25kcyB3aXRoIDQwNCBOb3Qg Rm91bmQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KLSBpZiAmbHQ7YSZndDsgd2FzIHNwb29mZWQg YW5kIHRoZXJlIGlzIG5vIFVBIHJlYWNoYWJsZSwgdGhlIHJlcXVlc3Qgd2lsbCB0aW1lIG91dCBv ciB0aGUgbmV0d29yayB3aWxsIGdlbmVyYXRlIGEgNDA0IE5vdCBmb3VuZC48YnI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXY+V2hlbmV2ZXIgSSBkb250IHJlY2VpdmUgYSAyMDAgT0sgb24gYSBEWVBUQywg dGhlIGNhbGxpbmcgbnVtYmVyIGNvdWxkIG5vdCBiZSB2ZXJpZmllZC48YnI+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNvIGZhciBhbGwgbWV0aG9kcyB0byBkZXRlcm1pbmUgYSBw YXJ0eSB0aGF0IGNhbiB2ZXJpZnkgYSBudW1iZXIgc2VlbSB0byBib2lsIGRvd24gdG8gb25lIG9m IHRoZSB0d28gZ3JvdXBzOjxicj4NCjxicj4NCjwvZGl2Pg0KMS4gY3JlYXRlIGEgbmV3IGRhdGFi YXNlLCByZXBsaWNhdGVkIGZyb20gdGhlIHRlbGNvcycgZGF0YWJhc2VzLCB0aGF0IGNhbiBiZSBh Y2Nlc3NlZCBieSBlbmQgZGV2aWNlcy4gVGhhdCdzIHdoYXQgaU1lc3NhZ2UsIHdoYXRzYXBwLCBh bmQgVklQUiB0cnkgdG8gZG8uIEFjY3VyYXRlbHkgcmVwbGljYXRpbmcgYSBmYWlybHkgZHluYW1p YyBkYXRhYmFzZSB3aXRob3V0IGl0cyBjb29wZXJhdGlvbiBpcyBhIGNoYWxsZW5nZS48YnI+DQo8 YnI+DQo8L2Rpdj4NCjIuIGNyZWF0ZSBhIHdheSBzbyB0aGF0IGVuZCBkZXZpY2VzIGNhbiBkaXJl Y3RseSBxdWVyeSB0aGUgdGVsY29zJyBkYXRhYmFzZXMuIEROUyBpcyBhbiBvYnZpb3VzIGNhbmRp ZGF0ZSBmb3IgdGhpcy48YnI+DQo8YnI+DQo8L2Rpdj4NCkhvd2V2ZXIsIGFjY2Vzc2luZyB0aGUg ZGF0YWJhc2UgaXRzZWxmIGlzIG5vdCBlbm91Z2guIFRoZSBlbmQgZGV2aWNlIHdvdWxkIGhhdmUg dG8gcmVwbGljYXRlIGFsbCByb3V0aW5nIGRlY2lzaW9ucyB0aGUgdGVsY29zIG1ha2UuIEFsbCBk aXNjdXNzaW9ucyBhYm91dCBQQlhzIGFuZCBudW1iZXIgcG9ydGFiaWxpdHkgYXJlIGVzc2VudGlh bGx5IGFib3V0IHRoZSByb3V0aW5nIGluc2lkZSB0aGUgdGVsY29zLjxicj4NCjxicj4NCjwvZGl2 Pg0KV2h5IG5vdCBqdXN0IHVzZSB0aGUgZXhpc3RpbmcgcGxhdGZvcm0gdG8gdmVyaWZ5IGNhbGxp bmcgbnVtYmVycz88YnI+DQo8YnI+DQo8L2Rpdj4NCjxicj4NCldvbGZnYW5nIEJlY2s8YnI+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_596979554D802045BBD45C051A4399E40D40C61ASTNTEXMB10cisne_-- From David.Holmes@sprint.com Thu Nov 7 14:00:55 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F1C21E818B for ; Thu, 7 Nov 2013 14:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHcMOrdXQbIP for ; Thu, 7 Nov 2013 14:00:50 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8FB11E82A8 for ; Thu, 7 Nov 2013 13:58:46 -0800 (PST) Received: from mail74-am1-R.bigfish.com (10.3.201.226) by AM1EHSOBE016.bigfish.com (10.3.207.138) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 21:58:44 +0000 Received: from mail74-am1 (localhost [127.0.0.1]) by mail74-am1-R.bigfish.com (Postfix) with ESMTP id E1C9910028E for ; Thu, 7 Nov 2013 21:58:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.25; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zz9371I542Ic85dhzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hz31iz1de098h1033IL8275bh8275dh18c673h1de097hz2fh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h1155h) Received-SPF: pass (mail74-am1: domain of sprint.com designates 144.230.168.25 as permitted sender) client-ip=144.230.168.25; envelope-from=David.Holmes@sprint.com; helo=plsasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail74-am1 (localhost.localdomain [127.0.0.1]) by mail74-am1 (MessageSwitch) id 1383861522157622_5435; Thu, 7 Nov 2013 21:58:42 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.243]) by mail74-am1.bigfish.com (Postfix) with ESMTP id 15D104A022F for ; Thu, 7 Nov 2013 21:58:42 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 21:58:41 +0000 Received: from PDAWEH03.ad.sprint.com (pdaweh03.corp.sprint.com [144.226.110.91]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA7LwdZl003490 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Nov 2013 15:58:40 -0600 Received: from plswm06b.ad.sprint.com ([169.254.2.181]) by PDAWEH03.ad.sprint.com ([144.226.110.91]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 15:58:39 -0600 From: "Holmes, David W [NTK]" To: "'stir@ietf.org'" Thread-Topic: [stir] new SIP Method DYPTC 'Did You Place This Call?' Thread-Index: AQHO2/75Idhh7AhL/kCcsHlgeJGWE5oaSAi0gAACJ8M= Date: Thu, 7 Nov 2013 21:58:38 +0000 Message-ID: References: <596979554D802045BBD45C051A4399E40D40C61A@STNTEXMB10.cis.neustar.com> In-Reply-To: <596979554D802045BBD45C051A4399E40D40C61A@STNTEXMB10.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.232.76.26] Content-Type: multipart/alternative; boundary="_000_F2A3B01434AD424F98139C02123503930111F789PLSWM06Badsprin_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:00:55 -0000 --_000_F2A3B01434AD424F98139C02123503930111F789PLSWM06Badsprin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maybe this has been considered before, but surely a "callback" approach cou= ld be made to work based on a the returned "callee" ID (called TN) in the "= callback" message being used to route the returned call beyond the "callbac= k" number (i.e. like a firewall/NAT function) - which is another descriptio= n of Wolfgang's idea below? The callee would receive only the gateway/call= center/doctor's office TN/ID, and the callee-based routing translation wou= ld only have a limited life, TBD by the originating server. I know this ha= s implications for routing the call in some cases (e.g. doctor's call to pa= tient must route through doctor's office), but these may allow additional a= dvantages beyond simple TN verification. ~ David ________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Peterson, = Jon [jon.peterson@neustar.biz] Sent: Thursday, November 07, 2013 1:26 PM To: 'Wolfgang Beck'; 'stir@ietf.org' Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' Various "callback" mechanisms along these lines have been considered, and t= here are known limitations of these mechanisms, most of which result from t= he fact that placing a call from a number does not guarantee that a returne= d call would reach the same endpoint instance. Gateways, call centers, user= s with multiple concurrently registered devices, all of our "doctor's offic= e" use cases and related configurations show why approaches along these lin= es are insufficient. Jon Peterson Neustar, inc. Sent with Good (www.good.com) -----Original Message----- From: Wolfgang Beck [wolfgang.beck01@googlemail.com] Sent: Thursday, November 07, 2013 04:18 PM Eastern Standard Time To: stir@ietf.org Subject: [stir] new SIP Method DYPTC 'Did You Place This Call?' Here's a half-baked idea: when a call c1 arives from , I send a DYPTC SI= P request message outside of this call back to . The DYPTC request carri= es some headers that describe c1, eg. the original from and to. - if the receiving UA is indeed , it responds with 200 OK. The origin of= call c1 is now verified. - if was spoofed by somebody, the request will arrive at a UA that does= not know about the call described by DYPTC. It responds with 404 Not Found - if was spoofed and there is no UA reachable, the request will time ou= t or the network will generate a 404 Not found. Whenever I dont receive a 200 OK on a DYPTC, the calling number could not b= e verified. So far all methods to determine a party that can verify a number seem to bo= il down to one of the two groups: 1. create a new database, replicated from the telcos' databases, that can b= e accessed by end devices. That's what iMessage, whatsapp, and VIPR try to = do. Accurately replicating a fairly dynamic database without its cooperatio= n is a challenge. 2. create a way so that end devices can directly query the telcos' database= s. DNS is an obvious candidate for this. However, accessing the database itself is not enough. The end device would = have to replicate all routing decisions the telcos make. All discussions ab= out PBXs and number portability are essentially about the routing inside th= e telcos. Why not just use the existing platform to verify calling numbers? Wolfgang Beck ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_F2A3B01434AD424F98139C02123503930111F789PLSWM06Badsprin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Maybe this has been considered before, but surely a "callback"= approach could be made to work based on a the returned "callee" = ID (called TN) in the "callback" message being used to route the = returned call beyond the "callback" number (i.e. like a firewall/= NAT function) - which is another description of Wolfgang's idea below?  T= he callee would receive only the gateway/call center/doctor's office TN/ID,= and the callee-based routing translation would only have a limited li= fe, TBD by the originating server.  I know this has implications for routing the call in some cases (e.g. doctor's ca= ll to patient must route through doctor's office), but these may allow addi= tional advantages beyond simple TN verification.  ~ David

From: stir-bounces@ietf.org [stir-bounces@i= etf.org] on behalf of Peterson, Jon [jon.peterson@neustar.biz]
Sent: Thursday, November 07, 2013 1:26 PM
To: 'Wolfgang Beck'; 'stir@ietf.org'
Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?'<= br>
Various "callback" mechanisms along these lines have been co= nsidered, and there are known limitations of these mechanisms, most of whic= h result from the fact that placing a call from a number does not guarantee= that a returned call would reach the same endpoint instance. Gateways, call centers, users with multiple concurrentl= y registered devices, all of our "doctor's office" use cases and = related configurations show why approaches along these lines are insufficie= nt.

Jon Peterson
Neustar, inc.



Sent with Good (www.good.com)


-----Original Message-----
From: Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent: Thursday, November 07, 2013 04:18 PM Eastern Standard Tim= e
To: stir@ietf.org
Subject: [stir] new SIP Method DYPTC 'Did You Place This Call?'=

Here's a half-baked idea: when a call c1 arives from <a>, I send= a DYPTC SIP request message outside of this call back to <a>. The DY= PTC request carries some headers that describe c1, eg. the original from an= d to.

- if the receiving UA is indeed <a>, it responds with 200 OK. The ori= gin of call c1 is now verified.

- if <a> was spoofed by somebody, the request will arrive at a UA tha= t does not know about the call described by DYPTC. It responds with 404 Not= Found

- if <a> was spoofed and there is no UA reachable, the request will t= ime out or the network will generate a 404 Not found.

Whenever I dont receive a 200 OK on a DYPTC, the calling number could = not be verified.

So far all methods to determine a party that can verify a number seem = to boil down to one of the two groups:

1. create a new database, replicated from the telcos' databases, that can b= e accessed by end devices. That's what iMessage, whatsapp, and VIPR try to = do. Accurately replicating a fairly dynamic database without its cooperatio= n is a challenge.

2. create a way so that end devices can directly query the telcos' database= s. DNS is an obvious candidate for this.

However, accessing the database itself is not enough. The end device would = have to replicate all routing decisions the telcos make. All discussions ab= out PBXs and number portability are essentially about the routing inside th= e telcos.

Why not just use the existing platform to verify calling numbers?


Wolfgang Beck


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_F2A3B01434AD424F98139C02123503930111F789PLSWM06Badsprin_-- From wolfgang.beck01@googlemail.com Thu Nov 7 14:23:09 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C074D11E815A for ; Thu, 7 Nov 2013 14:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYtov6Ox1JSk for ; Thu, 7 Nov 2013 14:23:09 -0800 (PST) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id BE4CD11E813B for ; Thu, 7 Nov 2013 14:23:08 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id cz12so893400veb.24 for ; Thu, 07 Nov 2013 14:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ak975jIkZrIxSi84hgAtJ6bSYcWM0hlpTaOmY6exqSM=; b=E+pZHhmCH80GnGOFpZyQMS1dANgjkK5R1KQP3g6XWDfQvYDhm78vu4gXSU9QkHZUww TZfW0cQPmhd4pLs0R0WjN4Bz59LP8rdbh3LEMfiYdixXKfSsv5nJctyLOsOi3jZdHL4L s5oC1tcDFFC/7o1gS8FvrDHfkVGvLQ8kaawAA53bl0ccdXB9CYmKr91fxbdICI72rUZW 2P1pDt7fa+YsgAb/t3JTKue22jungzMEmmpYSOR1v8IWCk/nf9t9iWbrgGXRgK/zd1IO WrJu5HzWIert6fYYD3GqB8tYf9mdXFg0OYOCA1ZpQnDt1TKVL6ucyNyBfLKWH8O8kr8A 6/CQ== MIME-Version: 1.0 X-Received: by 10.52.30.104 with SMTP id r8mr2696082vdh.18.1383862987875; Thu, 07 Nov 2013 14:23:07 -0800 (PST) Received: by 10.58.45.169 with HTTP; Thu, 7 Nov 2013 14:23:07 -0800 (PST) Received: by 10.58.45.169 with HTTP; Thu, 7 Nov 2013 14:23:07 -0800 (PST) In-Reply-To: <596979554D802045BBD45C051A4399E40D40C61A@STNTEXMB10.cis.neustar.com> References: <596979554D802045BBD45C051A4399E40D40C61A@STNTEXMB10.cis.neustar.com> Date: Thu, 7 Nov 2013 23:23:07 +0100 Message-ID: From: Wolfgang Beck To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=20cf3079c09acf6fcc04ea9db569 Cc: stir@ietf.org Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:23:09 -0000 --20cf3079c09acf6fcc04ea9db569 Content-Type: text/plain; charset=ISO-8859-1 Would you agree that such a SIP message would arrive at an element of a party that has delegated the number to its current user? Solving the problem 'who owns this number?' seems easier to me inside the system than in a separate one. Am 07.11.2013 13:26 schrieb "Peterson, Jon" : > Various "callback" mechanisms along these lines have been considered, > and there are known limitations of these mechanisms, most of which result > from the fact that placing a call from a number does not guarantee that a > returned call would reach the same endpoint instance. Gateways, call > centers, users with multiple concurrently registered devices, all of our > "doctor's office" use cases and related configurations show why approaches > along these lines are insufficient. > > Jon Peterson > Neustar, inc. > > > > Sent with Good (www.good.com) > > > -----Original Message----- > *From: *Wolfgang Beck [wolfgang.beck01@googlemail.com] > *Sent: *Thursday, November 07, 2013 04:18 PM Eastern Standard Time > *To: *stir@ietf.org > *Subject: *[stir] new SIP Method DYPTC 'Did You Place This Call?' > > Here's a half-baked idea: when a call c1 arives from , I send a > DYPTC SIP request message outside of this call back to . The DYPTC > request carries some headers that describe c1, eg. the original from and to. > > - if the receiving UA is indeed , it responds with 200 OK. The origin > of call c1 is now verified. > > - if was spoofed by somebody, the request will arrive at a UA that > does not know about the call described by DYPTC. It responds with 404 Not > Found > > - if was spoofed and there is no UA reachable, the request will time > out or the network will generate a 404 Not found. > > Whenever I dont receive a 200 OK on a DYPTC, the calling number could > not be verified. > > So far all methods to determine a party that can verify a number seem to > boil down to one of the two groups: > > 1. create a new database, replicated from the telcos' databases, that can > be accessed by end devices. That's what iMessage, whatsapp, and VIPR try to > do. Accurately replicating a fairly dynamic database without its > cooperation is a challenge. > > 2. create a way so that end devices can directly query the telcos' > databases. DNS is an obvious candidate for this. > > However, accessing the database itself is not enough. The end device > would have to replicate all routing decisions the telcos make. All > discussions about PBXs and number portability are essentially about the > routing inside the telcos. > > Why not just use the existing platform to verify calling numbers? > > > Wolfgang Beck > --20cf3079c09acf6fcc04ea9db569 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Would you agree that such a SIP message would arrive at an e= lement of a party that has delegated the number to its current user? Solvin= g the problem 'who owns this number?' seems easier to me inside the= system than in a separate one.

Am 07.11.2013 13:26 schrieb "Peterson, Jon&= quot; <jon.peterson@neustar.= biz>:
Various "callback" mechanisms along these lines have been conside= red, and there are known limitations of these mechanisms, most of which res= ult from the fact that placing a call from a number does not guarantee that= a returned call would reach the same endpoint instance. Gateways, call centers, users with multiple concurrently registe= red devices, all of our "doctor's office" use cases and relat= ed configurations show why approaches along these lines are insufficient.
Jon Peterson
Neustar, inc.



Sent with Good (www.good.= com)


-----Original Message-----
From:=A0Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent:=A0Thursday, November 07, 2013 04:18 PM Eastern Standard Time To:=A0stir@ietf.o= rg
Subject:=A0[stir] new SIP Method DYPTC 'Did You Place This Call?= '

Here's a half-baked idea: when a call c1 arives from <a>, I = send a DYPTC SIP request message outside of this call back to <a>. Th= e DYPTC request carries some headers that describe c1, eg. the original fro= m and to.

- if the receiving UA is indeed <a>, it responds with 200 OK. The ori= gin of call c1 is now verified.

- if <a> was spoofed by somebody, the request will arrive at a UA tha= t does not know about the call described by DYPTC. It responds with 404 Not= Found

- if <a> was spoofed and there is no UA reachable, the request will t= ime out or the network will generate a 404 Not found.

Whenever I dont receive a 200 OK on a DYPTC, the calling number could = not be verified.

So far all methods to determine a party that can verify a number seem = to boil down to one of the two groups:

1. create a new database, replicated from the telcos' databases, that c= an be accessed by end devices. That's what iMessage, whatsapp, and VIPR= try to do. Accurately replicating a fairly dynamic database without its co= operation is a challenge.

2. create a way so that end devices can directly query the telcos' data= bases. DNS is an obvious candidate for this.

However, accessing the database itself is not enough. The end device would = have to replicate all routing decisions the telcos make. All discussions ab= out PBXs and number portability are essentially about the routing inside th= e telcos.

Why not just use the existing platform to verify calling numbers?


Wolfgang Beck
--20cf3079c09acf6fcc04ea9db569-- From jon.peterson@neustar.biz Thu Nov 7 14:38:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4641621E8188 for ; Thu, 7 Nov 2013 14:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.311 X-Spam-Level: X-Spam-Status: No, score=-106.311 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctlzZaKi5scM for ; Thu, 7 Nov 2013 14:38:12 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B9AC921E80D3 for ; Thu, 7 Nov 2013 14:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383864491; x=1699222765; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=oAEoX3aIPX63xAHwLgbdO2h6fiHVdq7771bUWhAi94Q=; b=A01+cVQpKQTWZEDx6bVIfl2ZwPvBFYmt+/sFQp2RjBuylaiGLWb81bJdmBCuGG kFtOgz9m5L5US9T5IcNlhomQ== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.35155524; Thu, 07 Nov 2013 17:48:10 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.5]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 7 Nov 2013 17:38:02 -0500 From: "Peterson, Jon" To: 'Wolfgang Beck' Thread-Topic: [stir] new SIP Method DYPTC 'Did You Place This Call?' Thread-Index: AQHO2/759gVKPWtkUE25HikC9AzlgJoaSAi0gABjqYD//7BZ0g== Date: Thu, 7 Nov 2013 22:38:02 +0000 Message-ID: <596979554D802045BBD45C051A4399E40D40C6EE@STNTEXMB10.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.15.96] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: osq+RMKcyzvJfmr64nqETw== Content-Type: multipart/alternative; boundary="_000_596979554D802045BBD45C051A4399E40D40C6EESTNTEXMB10cisne_" MIME-Version: 1.0 Cc: "'stir@ietf.org'" Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:38:44 -0000 --_000_596979554D802045BBD45C051A4399E40D40C6EESTNTEXMB10cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIGJlbGlldmUgdGhhdCBTSVAgbWVzc2FnZXMgcm91dGVkIHRvIHRlbGVwaG9uZSBudW1iZXJz IHRvZGF5IGFyZSBtb3N0bHkgZnJlcXVlbnRseSBkcm9wcGVkIHRvIHRoZSBQU1ROLCBhbmQgbWF5 IGV2ZW50dWFsbHkgcmUtZW50ZXIgdGhlIEludGVybmV0IG9yIG5vdC4gSW4gY2FzZXMgd2hlcmUg cmVxdWVzdHMgdGFyZ2V0aW5nIHRlbGVwaG9uZSBudW1iZXJzIGRvIHRyYXZlbCBlbmQtdG8tZW5k IG92ZXIgdGhlIEludGVybmV0LCB2YXJpb3VzIGZsYXQgZmlsZXMgYW5kIHByaXZhdGUgZGF0YWJh c2VzIGFyZSBjb25zdWx0ZWQgdG8gZm9yd2FyZCByZXF1ZXN0cyBob3AtYnktaG9wIHVudGlsIHRo ZXkgcmVhY2ggYSBkZXN0aW5hdGlvbi4gVGhlIHJlbGF0aW9uc2hpcHMgb2YgdGhvc2UgbWVjaGFu aXNtcyB0byBudW1iZXJpbmcgYXV0aG9yaXRpZXMgY2FuIGJlIHRlbnVvdXMgdG9kYXksIHByZWNp c2VseSBiZWNhdXNlIG9mIHRoZSBhYnNlbmNlIG9mIHRoZSBhdXRob3JpdHkgYXJjaGl0ZWN0dXJl IHRoaXMgd29ya2luZyBncm91cCBpcyBjb25zaWRlcmluZy4NCg0KVGhlcmUncyBubyBmcmVlIGx1 bmNoIGhlcmUuDQoNCkpvbiBQZXRlcnNvbg0KTmV1c3RhciwgSW5jLg0KDQoNCg0KU2VudCB3aXRo IEdvb2QgKHd3dy5nb29kLmNvbSkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogV29sZmdhbmcgQmVjayBbd29sZmdhbmcuYmVjazAxQGdvb2dsZW1haWwuY29tPG1haWx0bzp3 b2xmZ2FuZy5iZWNrMDFAZ29vZ2xlbWFpbC5jb20+XQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVy IDA3LCAyMDEzIDA1OjIzIFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IFBldGVyc29uLCBK b24NCkNjOiBzdGlyQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3N0aXJdIG5ldyBTSVAgTWV0aG9k IERZUFRDICdEaWQgWW91IFBsYWNlIFRoaXMgQ2FsbD8nDQoNCg0KV291bGQgeW91IGFncmVlIHRo YXQgc3VjaCBhIFNJUCBtZXNzYWdlIHdvdWxkIGFycml2ZSBhdCBhbiBlbGVtZW50IG9mIGEgcGFy dHkgdGhhdCBoYXMgZGVsZWdhdGVkIHRoZSBudW1iZXIgdG8gaXRzIGN1cnJlbnQgdXNlcj8gU29s dmluZyB0aGUgcHJvYmxlbSAnd2hvIG93bnMgdGhpcyBudW1iZXI/JyBzZWVtcyBlYXNpZXIgdG8g bWUgaW5zaWRlIHRoZSBzeXN0ZW0gdGhhbiBpbiBhIHNlcGFyYXRlIG9uZS4NCg0KQW0gMDcuMTEu MjAxMyAxMzoyNiBzY2hyaWViICJQZXRlcnNvbiwgSm9uIiA8am9uLnBldGVyc29uQG5ldXN0YXIu Yml6PG1haWx0bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXo+PjoNClZhcmlvdXMgImNhbGxiYWNr IiBtZWNoYW5pc21zIGFsb25nIHRoZXNlIGxpbmVzIGhhdmUgYmVlbiBjb25zaWRlcmVkLCBhbmQg dGhlcmUgYXJlIGtub3duIGxpbWl0YXRpb25zIG9mIHRoZXNlIG1lY2hhbmlzbXMsIG1vc3Qgb2Yg d2hpY2ggcmVzdWx0IGZyb20gdGhlIGZhY3QgdGhhdCBwbGFjaW5nIGEgY2FsbCBmcm9tIGEgbnVt YmVyIGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IGEgcmV0dXJuZWQgY2FsbCB3b3VsZCByZWFjaCB0 aGUgc2FtZSBlbmRwb2ludCBpbnN0YW5jZS4gR2F0ZXdheXMsIGNhbGwgY2VudGVycywgdXNlcnMg d2l0aCBtdWx0aXBsZSBjb25jdXJyZW50bHkgcmVnaXN0ZXJlZCBkZXZpY2VzLCBhbGwgb2Ygb3Vy ICJkb2N0b3IncyBvZmZpY2UiIHVzZSBjYXNlcyBhbmQgcmVsYXRlZCBjb25maWd1cmF0aW9ucyBz aG93IHdoeSBhcHByb2FjaGVzIGFsb25nIHRoZXNlIGxpbmVzIGFyZSBpbnN1ZmZpY2llbnQuDQoN CkpvbiBQZXRlcnNvbg0KTmV1c3RhciwgaW5jLg0KDQoNCg0KU2VudCB3aXRoIEdvb2QgKHd3dy5n b29kLmNvbTxodHRwOi8vd3d3Lmdvb2QuY29tPikNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogV29sZmdhbmcgQmVjayBbd29sZmdhbmcuYmVjazAxQGdvb2dsZW1haWwuY29t PG1haWx0bzp3b2xmZ2FuZy5iZWNrMDFAZ29vZ2xlbWFpbC5jb20+XQ0KU2VudDogVGh1cnNkYXks IE5vdmVtYmVyIDA3LCAyMDEzIDA0OjE4IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IHN0 aXJAaWV0Zi5vcmc8bWFpbHRvOnN0aXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc3Rpcl0gbmV3IFNJ UCBNZXRob2QgRFlQVEMgJ0RpZCBZb3UgUGxhY2UgVGhpcyBDYWxsPycNCg0KSGVyZSdzIGEgaGFs Zi1iYWtlZCBpZGVhOiB3aGVuIGEgY2FsbCBjMSBhcml2ZXMgZnJvbSA8YT4sIEkgc2VuZCBhIERZ UFRDIFNJUCByZXF1ZXN0IG1lc3NhZ2Ugb3V0c2lkZSBvZiB0aGlzIGNhbGwgYmFjayB0byA8YT4u IFRoZSBEWVBUQyByZXF1ZXN0IGNhcnJpZXMgc29tZSBoZWFkZXJzIHRoYXQgZGVzY3JpYmUgYzEs IGVnLiB0aGUgb3JpZ2luYWwgZnJvbSBhbmQgdG8uDQoNCi0gaWYgdGhlIHJlY2VpdmluZyBVQSBp cyBpbmRlZWQgPGE+LCBpdCByZXNwb25kcyB3aXRoIDIwMCBPSy4gVGhlIG9yaWdpbiBvZiBjYWxs IGMxIGlzIG5vdyB2ZXJpZmllZC4NCg0KLSBpZiA8YT4gd2FzIHNwb29mZWQgYnkgc29tZWJvZHks IHRoZSByZXF1ZXN0IHdpbGwgYXJyaXZlIGF0IGEgVUEgdGhhdCBkb2VzIG5vdCBrbm93IGFib3V0 IHRoZSBjYWxsIGRlc2NyaWJlZCBieSBEWVBUQy4gSXQgcmVzcG9uZHMgd2l0aCA0MDQgTm90IEZv dW5kDQoNCi0gaWYgPGE+IHdhcyBzcG9vZmVkIGFuZCB0aGVyZSBpcyBubyBVQSByZWFjaGFibGUs IHRoZSByZXF1ZXN0IHdpbGwgdGltZSBvdXQgb3IgdGhlIG5ldHdvcmsgd2lsbCBnZW5lcmF0ZSBh IDQwNCBOb3QgZm91bmQuDQoNCldoZW5ldmVyIEkgZG9udCByZWNlaXZlIGEgMjAwIE9LIG9uIGEg RFlQVEMsIHRoZSBjYWxsaW5nIG51bWJlciBjb3VsZCBub3QgYmUgdmVyaWZpZWQuDQoNClNvIGZh ciBhbGwgbWV0aG9kcyB0byBkZXRlcm1pbmUgYSBwYXJ0eSB0aGF0IGNhbiB2ZXJpZnkgYSBudW1i ZXIgc2VlbSB0byBib2lsIGRvd24gdG8gb25lIG9mIHRoZSB0d28gZ3JvdXBzOg0KDQoxLiBjcmVh dGUgYSBuZXcgZGF0YWJhc2UsIHJlcGxpY2F0ZWQgZnJvbSB0aGUgdGVsY29zJyBkYXRhYmFzZXMs IHRoYXQgY2FuIGJlIGFjY2Vzc2VkIGJ5IGVuZCBkZXZpY2VzLiBUaGF0J3Mgd2hhdCBpTWVzc2Fn ZSwgd2hhdHNhcHAsIGFuZCBWSVBSIHRyeSB0byBkby4gQWNjdXJhdGVseSByZXBsaWNhdGluZyBh IGZhaXJseSBkeW5hbWljIGRhdGFiYXNlIHdpdGhvdXQgaXRzIGNvb3BlcmF0aW9uIGlzIGEgY2hh bGxlbmdlLg0KDQoyLiBjcmVhdGUgYSB3YXkgc28gdGhhdCBlbmQgZGV2aWNlcyBjYW4gZGlyZWN0 bHkgcXVlcnkgdGhlIHRlbGNvcycgZGF0YWJhc2VzLiBETlMgaXMgYW4gb2J2aW91cyBjYW5kaWRh dGUgZm9yIHRoaXMuDQoNCkhvd2V2ZXIsIGFjY2Vzc2luZyB0aGUgZGF0YWJhc2UgaXRzZWxmIGlz IG5vdCBlbm91Z2guIFRoZSBlbmQgZGV2aWNlIHdvdWxkIGhhdmUgdG8gcmVwbGljYXRlIGFsbCBy b3V0aW5nIGRlY2lzaW9ucyB0aGUgdGVsY29zIG1ha2UuIEFsbCBkaXNjdXNzaW9ucyBhYm91dCBQ QlhzIGFuZCBudW1iZXIgcG9ydGFiaWxpdHkgYXJlIGVzc2VudGlhbGx5IGFib3V0IHRoZSByb3V0 aW5nIGluc2lkZSB0aGUgdGVsY29zLg0KDQpXaHkgbm90IGp1c3QgdXNlIHRoZSBleGlzdGluZyBw bGF0Zm9ybSB0byB2ZXJpZnkgY2FsbGluZyBudW1iZXJzPw0KDQoNCldvbGZnYW5nIEJlY2sNCg== --_000_596979554D802045BBD45C051A4399E40D40C6EESTNTEXMB10cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVu dD0iSFRNTCBUaWR5IGZvciBXaW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3Lncz Lm9yZyI+DQo8dGl0bGU+PC90aXRsZT4NCjwvaGVhZD4NCjxib2R5Pg0KPGJyPg0KSSBiZWxpZXZl IHRoYXQgU0lQIG1lc3NhZ2VzIHJvdXRlZCB0byB0ZWxlcGhvbmUgbnVtYmVycyB0b2RheSBhcmUg bW9zdGx5IGZyZXF1ZW50bHkgZHJvcHBlZCB0byB0aGUgUFNUTiwgYW5kIG1heSBldmVudHVhbGx5 IHJlLWVudGVyIHRoZSBJbnRlcm5ldCBvciBub3QuIEluIGNhc2VzIHdoZXJlIHJlcXVlc3RzIHRh cmdldGluZyB0ZWxlcGhvbmUgbnVtYmVycyBkbyB0cmF2ZWwgZW5kLXRvLWVuZCBvdmVyIHRoZSBJ bnRlcm5ldCwgdmFyaW91cyBmbGF0DQogZmlsZXMgYW5kIHByaXZhdGUgZGF0YWJhc2VzIGFyZSBj b25zdWx0ZWQgdG8gZm9yd2FyZCByZXF1ZXN0cyBob3AtYnktaG9wIHVudGlsIHRoZXkgcmVhY2gg YSBkZXN0aW5hdGlvbi4gVGhlIHJlbGF0aW9uc2hpcHMgb2YgdGhvc2UgbWVjaGFuaXNtcyB0byBu dW1iZXJpbmcgYXV0aG9yaXRpZXMgY2FuIGJlIHRlbnVvdXMgdG9kYXksIHByZWNpc2VseSBiZWNh dXNlIG9mIHRoZSBhYnNlbmNlIG9mIHRoZSBhdXRob3JpdHkgYXJjaGl0ZWN0dXJlIHRoaXMNCiB3 b3JraW5nIGdyb3VwIGlzIGNvbnNpZGVyaW5nLjxicj4NCjxicj4NClRoZXJlJ3Mgbm8gZnJlZSBs dW5jaCBoZXJlLjxicj4NCjxicj4NCkpvbiBQZXRlcnNvbjxicj4NCk5ldXN0YXIsIEluYy48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQpTZW50IHdpdGggR29vZCAod3d3Lmdvb2QuY29tKTxicj4NCjxi cj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KPGI+RnJvbTombmJzcDs8 L2I+V29sZmdhbmcgQmVjayBbPGEgaHJlZj0ibWFpbHRvOndvbGZnYW5nLmJlY2swMUBnb29nbGVt YWlsLmNvbSI+d29sZmdhbmcuYmVjazAxQGdvb2dsZW1haWwuY29tPC9hPl08YnI+DQo8Yj5TZW50 OiZuYnNwOzwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMDcsIDIwMTMgMDU6MjMgUE0gRWFzdGVybiBT dGFuZGFyZCBUaW1lPGJyPg0KPGI+VG86Jm5ic3A7PC9iPlBldGVyc29uLCBKb248YnI+DQo8Yj5D YzombmJzcDs8L2I+c3RpckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6Jm5ic3A7PC9iPlJFOiBb c3Rpcl0gbmV3IFNJUCBNZXRob2QgRFlQVEMgJ0RpZCBZb3UgUGxhY2UgVGhpcyBDYWxsPyc8YnI+ DQo8YnI+DQo8cCBkaXI9Imx0ciI+V291bGQgeW91IGFncmVlIHRoYXQgc3VjaCBhIFNJUCBtZXNz YWdlIHdvdWxkIGFycml2ZSBhdCBhbiBlbGVtZW50IG9mIGEgcGFydHkgdGhhdCBoYXMgZGVsZWdh dGVkIHRoZSBudW1iZXIgdG8gaXRzIGN1cnJlbnQgdXNlcj8gU29sdmluZyB0aGUgcHJvYmxlbSAn d2hvIG93bnMgdGhpcyBudW1iZXI/JyBzZWVtcyBlYXNpZXIgdG8gbWUgaW5zaWRlIHRoZSBzeXN0 ZW0gdGhhbiBpbiBhIHNlcGFyYXRlIG9uZS48L3A+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ QW0gMDcuMTEuMjAxMyAxMzoyNiBzY2hyaWViICZxdW90O1BldGVyc29uLCBKb24mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXoiPmpvbi5wZXRlcnNvbkBu ZXVzdGFyLmJpejwvYT4mZ3Q7OjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+DQo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXY+VmFyaW91cyAmcXVvdDtjYWxs YmFjayZxdW90OyBtZWNoYW5pc21zIGFsb25nIHRoZXNlIGxpbmVzIGhhdmUgYmVlbiBjb25zaWRl cmVkLCBhbmQgdGhlcmUgYXJlIGtub3duIGxpbWl0YXRpb25zIG9mIHRoZXNlIG1lY2hhbmlzbXMs IG1vc3Qgb2Ygd2hpY2ggcmVzdWx0IGZyb20gdGhlIGZhY3QgdGhhdCBwbGFjaW5nIGEgY2FsbCBm cm9tIGEgbnVtYmVyIGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IGEgcmV0dXJuZWQgY2FsbCB3b3Vs ZCByZWFjaCB0aGUgc2FtZQ0KIGVuZHBvaW50IGluc3RhbmNlLiBHYXRld2F5cywgY2FsbCBjZW50 ZXJzLCB1c2VycyB3aXRoIG11bHRpcGxlIGNvbmN1cnJlbnRseSByZWdpc3RlcmVkIGRldmljZXMs IGFsbCBvZiBvdXIgJnF1b3Q7ZG9jdG9yJ3Mgb2ZmaWNlJnF1b3Q7IHVzZSBjYXNlcyBhbmQgcmVs YXRlZCBjb25maWd1cmF0aW9ucyBzaG93IHdoeSBhcHByb2FjaGVzIGFsb25nIHRoZXNlIGxpbmVz IGFyZSBpbnN1ZmZpY2llbnQuPGJyPg0KPGJyPg0KSm9uIFBldGVyc29uPGJyPg0KTmV1c3Rhciwg aW5jLjxicj4NCjxicj4NCjxicj4NCjxicj4NClNlbnQgd2l0aCBHb29kICg8YSBocmVmPSJodHRw Oi8vd3d3Lmdvb2QuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3Lmdvb2QuY29tPC9hPik8YnI+DQo8 YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCjxiPkZyb206Jm5ic3A7 PC9iPldvbGZnYW5nIEJlY2sgWzxhIGhyZWY9Im1haWx0bzp3b2xmZ2FuZy5iZWNrMDFAZ29vZ2xl bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj53b2xmZ2FuZy5iZWNrMDFAZ29vZ2xlbWFpbC5jb208 L2E+XTxicj4NCjxiPlNlbnQ6Jm5ic3A7PC9iPlRodXJzZGF5LCBOb3ZlbWJlciAwNywgMjAxMyAw NDoxOCBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWU8YnI+DQo8Yj5UbzombmJzcDs8L2I+PGEgaHJl Zj0ibWFpbHRvOnN0aXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zdGlyQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6Jm5ic3A7PC9iPltzdGlyXSBuZXcgU0lQIE1ldGhvZCBEWVBUQyAn RGlkIFlvdSBQbGFjZSBUaGlzIENhbGw/Jzxicj4NCjxicj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+SGVyZSdzIGEgaGFsZi1iYWtlZCBpZGVhOiB3 aGVuIGEgY2FsbCBjMSBhcml2ZXMgZnJvbSAmbHQ7YSZndDssIEkgc2VuZCBhIERZUFRDIFNJUCBy ZXF1ZXN0IG1lc3NhZ2Ugb3V0c2lkZSBvZiB0aGlzIGNhbGwgYmFjayB0byAmbHQ7YSZndDsuIFRo ZSBEWVBUQyByZXF1ZXN0IGNhcnJpZXMgc29tZSBoZWFkZXJzIHRoYXQgZGVzY3JpYmUgYzEsIGVn LiB0aGUgb3JpZ2luYWwgZnJvbSBhbmQgdG8uPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCi0gaWYg dGhlIHJlY2VpdmluZyBVQSBpcyBpbmRlZWQgJmx0O2EmZ3Q7LCBpdCByZXNwb25kcyB3aXRoIDIw MCBPSy4gVGhlIG9yaWdpbiBvZiBjYWxsIGMxIGlzIG5vdyB2ZXJpZmllZC48YnI+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KLSBpZiAmbHQ7YSZndDsgd2FzIHNwb29mZWQgYnkgc29tZWJvZHksIHRoZSBy ZXF1ZXN0IHdpbGwgYXJyaXZlIGF0IGEgVUEgdGhhdCBkb2VzIG5vdCBrbm93IGFib3V0IHRoZSBj YWxsIGRlc2NyaWJlZCBieSBEWVBUQy4gSXQgcmVzcG9uZHMgd2l0aCA0MDQgTm90IEZvdW5kPGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCi0gaWYgJmx0O2EmZ3Q7IHdhcyBzcG9vZmVkIGFuZCB0aGVy ZSBpcyBubyBVQSByZWFjaGFibGUsIHRoZSByZXF1ZXN0IHdpbGwgdGltZSBvdXQgb3IgdGhlIG5l dHdvcmsgd2lsbCBnZW5lcmF0ZSBhIDQwNCBOb3QgZm91bmQuPGJyPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2PldoZW5ldmVyIEkgZG9udCByZWNlaXZlIGEgMjAwIE9LIG9uIGEgRFlQVEMsIHRoZSBjYWxs aW5nIG51bWJlciBjb3VsZCBub3QgYmUgdmVyaWZpZWQuPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5TbyBmYXIgYWxsIG1ldGhvZHMgdG8gZGV0ZXJtaW5lIGEgcGFydHkgdGhh dCBjYW4gdmVyaWZ5IGEgbnVtYmVyIHNlZW0gdG8gYm9pbCBkb3duIHRvIG9uZSBvZiB0aGUgdHdv IGdyb3Vwczo8YnI+DQo8YnI+DQo8L2Rpdj4NCjEuIGNyZWF0ZSBhIG5ldyBkYXRhYmFzZSwgcmVw bGljYXRlZCBmcm9tIHRoZSB0ZWxjb3MnIGRhdGFiYXNlcywgdGhhdCBjYW4gYmUgYWNjZXNzZWQg YnkgZW5kIGRldmljZXMuIFRoYXQncyB3aGF0IGlNZXNzYWdlLCB3aGF0c2FwcCwgYW5kIFZJUFIg dHJ5IHRvIGRvLiBBY2N1cmF0ZWx5IHJlcGxpY2F0aW5nIGEgZmFpcmx5IGR5bmFtaWMgZGF0YWJh c2Ugd2l0aG91dCBpdHMgY29vcGVyYXRpb24gaXMgYSBjaGFsbGVuZ2UuPGJyPg0KPGJyPg0KPC9k aXY+DQoyLiBjcmVhdGUgYSB3YXkgc28gdGhhdCBlbmQgZGV2aWNlcyBjYW4gZGlyZWN0bHkgcXVl cnkgdGhlIHRlbGNvcycgZGF0YWJhc2VzLiBETlMgaXMgYW4gb2J2aW91cyBjYW5kaWRhdGUgZm9y IHRoaXMuPGJyPg0KPGJyPg0KPC9kaXY+DQpIb3dldmVyLCBhY2Nlc3NpbmcgdGhlIGRhdGFiYXNl IGl0c2VsZiBpcyBub3QgZW5vdWdoLiBUaGUgZW5kIGRldmljZSB3b3VsZCBoYXZlIHRvIHJlcGxp Y2F0ZSBhbGwgcm91dGluZyBkZWNpc2lvbnMgdGhlIHRlbGNvcyBtYWtlLiBBbGwgZGlzY3Vzc2lv bnMgYWJvdXQgUEJYcyBhbmQgbnVtYmVyIHBvcnRhYmlsaXR5IGFyZSBlc3NlbnRpYWxseSBhYm91 dCB0aGUgcm91dGluZyBpbnNpZGUgdGhlIHRlbGNvcy48YnI+DQo8YnI+DQo8L2Rpdj4NCldoeSBu b3QganVzdCB1c2UgdGhlIGV4aXN0aW5nIHBsYXRmb3JtIHRvIHZlcmlmeSBjYWxsaW5nIG51bWJl cnM/PGJyPg0KPGJyPg0KPC9kaXY+DQo8YnI+DQpXb2xmZ2FuZyBCZWNrPGJyPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_596979554D802045BBD45C051A4399E40D40C6EESTNTEXMB10cisne_-- From victor.pascual.avila@gmail.com Thu Nov 7 15:09:11 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06E311E815A for ; Thu, 7 Nov 2013 15:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bECBRmdxCXt for ; Thu, 7 Nov 2013 15:09:11 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CE3C111E8264 for ; Thu, 7 Nov 2013 15:09:01 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id r10so1269181pdi.32 for ; Thu, 07 Nov 2013 15:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=td/mGKehuuIDPhoFO707iNqZik4hA9LecOHlwVvDwFQ=; b=KLNh2mws2tDbWENyn1slVpZ3lfbh6Hq9Z9okC1p5wS5UitgbI/I/V3VYD58umf+z2m wgzK0AeZXXpVeO72T1KIwd+71SMqrSfbVXr48zQjZ10rqVornRM2LHTqHiml2aTBQB5f N6jPAh52lnGKOnAcGcJghGhk+RmrfFl0IpMtYrPQDb/wH5q69vPDTPdqlXy/Ijx9QnkG TMalbtsXXN6ZfpSrGLSl3QSD+bj4ssyNTELuh+LasG9cctFCHSO3RRUbuvDx2EhYctQj 5fWIQf1dr0MgiNRCMilN23a/wLmYpLlG5PN+x5ewI9Yy4gUIxigpnH7MOtb/ENY5VKKf 1CIQ== MIME-Version: 1.0 X-Received: by 10.68.91.3 with SMTP id ca3mr11723593pbb.20.1383865741461; Thu, 07 Nov 2013 15:09:01 -0800 (PST) Received: by 10.68.213.6 with HTTP; Thu, 7 Nov 2013 15:09:01 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Nov 2013 00:09:01 +0100 Message-ID: From: Victor Pascual Avila To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stir@ietf.org Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:09:12 -0000 Check this one: http://tools.ietf.org/html/draft-kuthan-sip-derive-00 On Thu, Nov 7, 2013 at 6:47 PM, Wolfgang Beck wrote: > Here's a half-baked idea: when a call c1 arives from , I send a DYPTC = SIP > request message outside of this call back to . The DYPTC request carri= es > some headers that describe c1, eg. the original from and to. > > - if the receiving UA is indeed , it responds with 200 OK. The origin = of > call c1 is now verified. > > - if was spoofed by somebody, the request will arrive at a UA that do= es > not know about the call described by DYPTC. It responds with 404 Not Foun= d > > - if was spoofed and there is no UA reachable, the request will time = out > or the network will generate a 404 Not found. > > Whenever I dont receive a 200 OK on a DYPTC, the calling number could not= be > verified. > > So far all methods to determine a party that can verify a number seem to > boil down to one of the two groups: > > 1. create a new database, replicated from the telcos' databases, that can= be > accessed by end devices. That's what iMessage, whatsapp, and VIPR try to = do. > Accurately replicating a fairly dynamic database without its cooperation = is > a challenge. > > 2. create a way so that end devices can directly query the telcos' > databases. DNS is an obvious candidate for this. > > However, accessing the database itself is not enough. The end device woul= d > have to replicate all routing decisions the telcos make. All discussions > about PBXs and number portability are essentially about the routing insid= e > the telcos. > > Why not just use the existing platform to verify calling numbers? > > > Wolfgang Beck > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --=20 Victor Pascual =C3=81vila From richard@shockey.us Thu Nov 7 15:19:55 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E811A21E8124 for ; Thu, 7 Nov 2013 15:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.994 X-Spam-Level: X-Spam-Status: No, score=-101.994 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUiGjjj6OcsF for ; Thu, 7 Nov 2013 15:19:51 -0800 (PST) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id EFBFE11E80E2 for ; Thu, 7 Nov 2013 15:19:50 -0800 (PST) Received: (qmail 20976 invoked by uid 0); 7 Nov 2013 23:19:25 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.mail.unifiedlayer.com with SMTP; 7 Nov 2013 23:19:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=uC6oeEmt+XMSjS0Wgx9jFO1raEO/lijPBzf8MqZdapM=; b=W6BLjUSKGMiSzKnvlPQOdKWVIGMdWeoCZ5tF6gyJ1+iTT3rBCbs65DCZNoP6/FNAa6/cwudSuc62Z/vYeZVyvTBfClrAryOihjRix+Mgz2DuYF1GYS4RMKqHiueUaB05; Received: from [173.79.179.104] (port=65171 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VeYrE-0006LU-JB; Thu, 07 Nov 2013 16:19:24 -0700 From: "Richard Shockey" To: "'Peterson, Jon'" , "'Wolfgang Beck'" References: <596979554D802045BBD45C051A4399E40D40C6EE@STNTEXMB10.cis.neustar.com> In-Reply-To: <596979554D802045BBD45C051A4399E40D40C6EE@STNTEXMB10.cis.neustar.com> Date: Thu, 7 Nov 2013 18:19:21 -0500 Message-ID: <036401cedc0f$cbaee520$630caf60$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0365_01CEDBE5.E2E38B80" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQE4XH/9Z5MDA1W6KwzaoGhWZoZUT5tHZEig X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:19:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0365_01CEDBE5.E2E38B80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 In general I have to agree with Jon here with some exceptions. The = level of SIP end to end in the US network is actually quite high and = with the advent of VoLTE in the next 2 years it will easily top 50% of = all voice minutes. =20 That said most of these transactions use IP technology and not = necessarily BGP routed =E2=80=9CInternet=E2=80=9D. These transactions I = have usually charactized as Voice USING IP not Voice Over IP.=20 =20 Jon is correct that the current database methodologies in use for VuIP = are rather =E2=80=9Ctenuous=E2=80=9D to say the least.. try Excel = spreadsheets. That said it is clear also clear that a restructure of = the national numbering databases will have to occur to facilitate end to = end SIP across carrier boundaries and whatever STIR mechanism is = ultimately chosen. =20 =20 From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Peterson, Jon Sent: Thursday, November 07, 2013 5:38 PM To: 'Wolfgang Beck' Cc: 'stir@ietf.org' Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' =20 I believe that SIP messages routed to telephone numbers today are mostly = frequently dropped to the PSTN, and may eventually re-enter the Internet = or not. In cases where requests targeting telephone numbers do travel = end-to-end over the Internet, various flat files and private databases = are consulted to forward requests hop-by-hop until they reach a = destination. The relationships of those mechanisms to numbering = authorities can be tenuous today, precisely because of the absence of = the authority architecture this working group is considering. There's no free lunch here. Jon Peterson Neustar, Inc. Sent with Good (www.good.com ) -----Original Message----- From: Wolfgang Beck [wolfgang.beck01@googlemail.com = ] Sent: Thursday, November 07, 2013 05:23 PM Eastern Standard Time To: Peterson, Jon Cc: stir@ietf.org =20 Subject: RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' Would you agree that such a SIP message would arrive at an element of a = party that has delegated the number to its current user? Solving the = problem 'who owns this number?' seems easier to me inside the system = than in a separate one. Am 07.11.2013 13:26 schrieb "Peterson, Jon" >: Various "callback" mechanisms along these lines have been considered, = and there are known limitations of these mechanisms, most of which = result from the fact that placing a call from a number does not = guarantee that a returned call would reach the same endpoint instance. = Gateways, call centers, users with multiple concurrently registered = devices, all of our "doctor's office" use cases and related = configurations show why approaches along these lines are insufficient. Jon Peterson Neustar, inc. Sent with Good (www.good.com ) -----Original Message----- From: Wolfgang Beck [wolfgang.beck01@googlemail.com = ] Sent: Thursday, November 07, 2013 04:18 PM Eastern Standard Time To: stir@ietf.org =20 Subject: [stir] new SIP Method DYPTC 'Did You Place This Call?' Here's a half-baked idea: when a call c1 arives from , I send a DYPTC = SIP request message outside of this call back to . The DYPTC request = carries some headers that describe c1, eg. the original from and to. - if the receiving UA is indeed , it responds with 200 OK. The origin = of call c1 is now verified. - if was spoofed by somebody, the request will arrive at a UA that = does not know about the call described by DYPTC. It responds with 404 = Not Found - if was spoofed and there is no UA reachable, the request will time = out or the network will generate a 404 Not found. Whenever I dont receive a 200 OK on a DYPTC, the calling number could = not be verified. =20 So far all methods to determine a party that can verify a number seem to = boil down to one of the two groups: 1. create a new database, replicated from the telcos' databases, that = can be accessed by end devices. That's what iMessage, whatsapp, and VIPR = try to do. Accurately replicating a fairly dynamic database without its = cooperation is a challenge. 2. create a way so that end devices can directly query the telcos' = databases. DNS is an obvious candidate for this. However, accessing the database itself is not enough. The end device = would have to replicate all routing decisions the telcos make. All = discussions about PBXs and number portability are essentially about the = routing inside the telcos. Why not just use the existing platform to verify calling numbers? Wolfgang Beck ------=_NextPart_000_0365_01CEDBE5.E2E38B80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

In general I have to agree with Jon here with some exceptions.=C2=A0 = The level of SIP end to end in the US network is actually quite high and = with the advent of VoLTE in the next 2 years it will easily top 50% of = all voice minutes.

 

That said most of these transactions use IP technology and not = necessarily BGP routed =E2=80=9CInternet=E2=80=9D.=C2=A0 These = transactions I have usually charactized as Voice USING IP not Voice Over = IP.

 

Jon is correct that the current database methodologies in use for = VuIP are rather =E2=80=9Ctenuous=E2=80=9D to say the least.. try Excel = spreadsheets. =C2=A0That said it is clear also clear that a restructure = of the national numbering databases will have to occur to facilitate end = to end SIP across carrier boundaries and whatever STIR mechanism is = ultimately chosen. =C2=A0

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Peterson, Jon
Sent: Thursday, November 07, 2013 5:38 = PM
To: 'Wolfgang Beck'
Cc: = 'stir@ietf.org'
Subject: Re: [stir] new SIP Method DYPTC 'Did = You Place This Call?'

 


I believe that SIP messages routed to = telephone numbers today are mostly frequently dropped to the PSTN, and = may eventually re-enter the Internet or not. In cases where requests = targeting telephone numbers do travel end-to-end over the Internet, = various flat files and private databases are consulted to forward = requests hop-by-hop until they reach a destination. The relationships of = those mechanisms to numbering authorities can be tenuous today, = precisely because of the absence of the authority architecture this = working group is considering.

There's no free lunch = here.

Jon Peterson
Neustar, Inc.



Sent with Good = (www.good.com)


-----Original = Message-----
From: Wolfgang Beck [wolfgang.beck01@googlemail= .com]
Sent: Thursday, November 07, 2013 05:23 PM = Eastern Standard Time
To: Peterson, = Jon
Cc: stir@ietf.org
Subject: R= E: [stir] new SIP Method DYPTC 'Did You Place This = Call?'

Would you agree that such a SIP message would = arrive at an element of a party that has delegated the number to its = current user? Solving the problem 'who owns this number?' seems easier = to me inside the system than in a separate one.

Am 07.11.2013 13:26 schrieb "Peterson, Jon" = <jon.peterson@neustar.biz>= :

Various "callback" mechanisms = along these lines have been considered, and there are known limitations = of these mechanisms, most of which result from the fact that placing a = call from a number does not guarantee that a returned call would reach = the same endpoint instance. Gateways, call centers, users with multiple = concurrently registered devices, all of our "doctor's office" = use cases and related configurations show why approaches along these = lines are insufficient.

Jon Peterson
Neustar, = inc.



Sent with Good (www.good.com)


-----Original = Message-----
From: Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent: Thursday, November 07, 2013 04:18 PM Eastern Standard = Time
To: stir@ietf.org
Subject: [stir] new = SIP Method DYPTC 'Did You Place This = Call?'

Here's a half-baked idea: when a call c1 arives from = <a>, I send a DYPTC SIP request message outside of this call back = to <a>. The DYPTC request carries some headers that describe c1, = eg. the original from and to.


- if the receiving UA is indeed <a>, it = responds with 200 OK. The origin of call c1 is now = verified.


- if = <a> was spoofed by somebody, the request will arrive at a UA that = does not know about the call described by DYPTC. It responds with 404 = Not Found


- if <a> was spoofed and there = is no UA reachable, the request will time out or the network will = generate a 404 Not found.

Whenever I dont receive a 200 OK on a DYPTC, the = calling number could not be verified.

 

So far all methods to determine a party = that can verify a number seem to boil down to one of the two = groups:

1. create a new database, replicated from = the telcos' databases, that can be accessed by end devices. That's what = iMessage, whatsapp, and VIPR try to do. Accurately replicating a fairly = dynamic database without its cooperation is a = challenge.

2. create a way so that end devices can = directly query the telcos' databases. DNS is an obvious candidate for = this.

However, accessing the database itself is = not enough. The end device would have to replicate all routing decisions = the telcos make. All discussions about PBXs and number portability are = essentially about the routing inside the telcos.

Why not just use the = existing platform to verify calling numbers?


Wolfgang = Beck

------=_NextPart_000_0365_01CEDBE5.E2E38B80-- From richard@shockey.us Thu Nov 7 15:33:32 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E90E21E8188 for ; Thu, 7 Nov 2013 15:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yxc0MM5qp31 for ; Thu, 7 Nov 2013 15:33:21 -0800 (PST) Received: from oproxy9-pub.mail.unifiedlayer.com (oproxy9-pub.mail.unifiedlayer.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id EE77521E80DB for ; Thu, 7 Nov 2013 15:33:18 -0800 (PST) Received: (qmail 20474 invoked by uid 0); 7 Nov 2013 23:32:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.mail.unifiedlayer.com with SMTP; 7 Nov 2013 23:32:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=e0BXa+zVXc0sTd+AZFISWdd+KGGl5AYPhifaDlG5QWE=; b=Nr6yKEBwiemL1CH/cSPUX2sMXs21qo5gGR7qv20MHi7pmsWFerfovHof/Czl61VTgMxHgwH43dNL/u91X9FuToJYr/HA0Gxp0fbTPKE+Olwd1e5m2QsPQVMw/5LfgMZx; Received: from [173.79.179.104] (port=65219 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VeZ4I-00007D-3J; Thu, 07 Nov 2013 16:32:54 -0700 From: "Richard Shockey" To: "'Brian Rosen'" References: <013601cedaf3$a05d72f0$e11858d0$@shockey.us> <0FDE6309-92B1-4031-AF72-2EDC11A5FE9E@brianrosen.net> <02e301cedb34$af790790$0e6b16b0$@shockey.us> <8285AA4C-2E08-46F7-B3A3-892FF793486E@brianrosen.net> <00f401cedbcc$4a7e3700$df7aa500$@shockey.us> <61DECB8D-A41A-41B8-B43C-DC11D3E2AE1B@brianrosen.net> In-Reply-To: <61DECB8D-A41A-41B8-B43C-DC11D3E2AE1B@brianrosen.net> Date: Thu, 7 Nov 2013 18:32:51 -0500 Message-ID: <038301cedc11$ae2f4010$0a8dc030$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0384_01CEDBE7.C56B8790" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQKuxOgdsFN95Qgmj4nb3bGbN4Q20wEejKIqAhCsH9QBYcTrswHCXLsVAZF++goCZ/4yCQGECT5Ql/wPvjA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: stir@ietf.org, "'Gorman, Pierce A \[NTK\]'" , cnit@ietf.org, "'Fernando Mousinho \(fmousinh\)'" Subject: Re: [stir] [cnit] draft-peterson-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:33:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0384_01CEDBE7.C56B8790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit VCARD SCHMEECARD.. whatever. I don't think you want to reinvent the wheel here but I won't argue about that. The issue is defining what set of data from a called party increases the level of trust in the session establishment process that the consumer generally would understand and can the network validate that data in a reasonable manner that does not increase costs or significantly increase post dial delay. Oh ..how would it be displayed . what would Google and Apple need to do to put the data on the devices? WebRTC for that matter since IMHO its going to end up being used as a SIP client quite often. And again I think a in band solution will not work and never actually be used by..sort of like VIPR. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, November 07, 2013 12:10 PM To: Richard Shockey Cc: stir@ietf.org List; Gorman, Pierce A [NTK]; Fernando Mousinho (fmousinh); cnit@ietf.org Subject: Re: [stir] [cnit] draft-peterson-stir-threats-00.txt We're agreeing CNAM doesn't work, it lies, and we have to fix that. Billing relationships are useful, but only give you return routability properties. Not very interesting, and billing addresses aren't often what is wanted. Given various corporate relationships that are tolerated by carriers, it would be trivial to make the billing name be anything you wanted it to be and get service from most carriers. I think it IS possible to validate a name, as long as you allow a probability of that validation to be carried, because the techniques we have aren't definitive. See prior reply on the category idea, which I think is workable. FWIW, I am in favor of an in band solution for CNAM - display name of From. You proposed a VCARD. I think that is unworkable. Name is hard enough. We might be able to get an address. All the other fields in a VCARD are pretty dicey. On Nov 7, 2013, at 7:16 AM, Richard Shockey > wrote: Like CNAM is so accurate today. ?? When certain companies get the data from scanning phone books that are not even printed anymore? The carrier has the billing relationship. As you well know that is where the data comes from now but it is not granular. The carrier permits the customer to create the record(s). What are you trying to validate? The Accuracy of the data? . In any event none of that is our problem. We make the tools. Someone else worries about policy. You are making this way too complicated thus defeating the basic use case. Well from time to time I've discovered I'm not a big fan of the end to end principal. It just doesn't work for every use case. This is a carrier service or in certain cases hosted. Much like I'm convinced the out of band solution in STIR is total fantasy and like VIPR will almost never actually be used in practice. As for encoding I mentioned JCARD since there seems to be a faction in the IETF that is anti-XML From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, November 07, 2013 12:59 AM To: Richard Shockey Cc: stir@ietf.org List; Gorman, Pierce A [NTK]; cnit@ietf.org ; Fernando Mousinho (fmousinh) Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt I think this would be a heavy lift. If the responsible entity was a carrier, then it would have to validate the data, which it has very little basis to validate. It could get a 3rd party to do the validation, but then it's putting its reputation on the back of some hired hand validator. If the responsibility is the end user/device, then the signature has no value. I do not argue that Call-Info is suitable, it is. I do question JCARD vs xCard, but that's an encoding detail. All of SIP Is XML described by schema, not json. Brian On Nov 6, 2013, at 1:10 PM, Richard Shockey < richard@shockey.us> wrote: URI for a JCARD in the CALL INFO header provisioned by the calling party and ultimately signed by the responsible entity. The carrier could provision this for their mobile or hosted customers. Enterprises could do this themselves. This also has advantages in Enterprise to Enterprise UC as well where the data is derived from the Enterprise "directory" and could facilitate end to end PPX to PBX communications especially in point to point video communications. There are certainly privacy and security issues to be addressed. The Push vs Pull model. This really would be PII in the clear but then its done voluntarily. There would have to be some work around restructuring the Header and adding some parameters but it's underutilized right now and this Use Case is a perfectly appropriate use. https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06 Obviously it would need to be signed but we don't need to worry about that ..yet. >From 3261 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: < http://wwww.example.com/alice/photo.jpg> ;purpose=icon, < http://www.example.com/alice/> ;purpose=info From: Brian Rosen [ mailto:br@brianrosen.net] Sent: Wednesday, November 06, 2013 3:41 PM To: Richard Shockey Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; stir@ietf.org List Subject: Re: [stir] draft-peterson-stir-threats-00.txt We've considered adding some information that is not number and is not name, but is something like "bank", which might have some sort of validation behind it. Is that along the lines you were thinking? Brian On Nov 6, 2013, at 5:25 AM, Richard Shockey < richard@shockey.us> wrote: I agree with Pierce here and respectfully disagree that STIR might eliminate the need for other forms of caller identification. Though your use case of credit card validation is a useful one and you are right there are still applications that use SS7 for things that have nothing to do with call setup. I agree with you STIR may have more applications beyond the obvious ones of realtime session validation. It's been my experience recently that there is a use case for something MORE in the identification of the session as it is presented to the called party. This is the CNAM + idea we are kicking around on the CNIT list. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit But your use case of a bank wanting to make sure they could properly identify themselves to the consumer before establishing a conversation is exactly what this process is about. STIR is essential but it's a multi-faceted problem that may require multi-faceted solutions.. and enhanced CNAM + being only one of them. Its not unreasonable to discuss those. The obviously analogy is I would want to see some real identification of a utility worker before I let them into my house to make repairs. I would want some validation that the call to me to reconfirm the appointments was in fact from the utility in question. From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho (fmousinh) Sent: Tuesday, November 05, 2013 6:26 PM To: Gorman, Pierce A [NTK]; stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt Let me rephrase it. it may eliminate the need for other forms of caller identification beyond what STIR will provide, depending on the specific use case. For example, a credit card company may choose to rely entirely on STIR before allowing a card to be unblocked by an IVR (and as I said earlier, many companies do it today). In other use cases, the TN alone is not sufficient information - my health care provider will want to know which member of the family is calling. I agree that ANI is already broadly used to improve customer service today. However, it is not usually deemed as a secure enough mechanism to validate the caller (therefore this WG!), except if you are a large organization that can leverage things like SS7. STIR would make this type of validation available to a broader number of companies. Going on a tangent. perhaps this is out of scope, but there is not a lot of discussion about called party hijacking. Couldn't a man-in-the-middle try to answer calls on my behalf? If my bank is calling me, I want to make sure it's really them before carrying a conversation, but wouldn't they want the same? From: , "Pierce A [NTK]" < Pierce.Gorman@sprint.com> Date: Tuesday, November 5, 2013 at 6:05 PM To: Fernando Mousinho < fmousinh@cisco.com>, " stir@ietf.org" < stir@ietf.org> Subject: RE: [stir] draft-peterson-stir-threats-00.txt I agree with your characterization of businesses as victim of caller ID fraud however contact centers also use TN as a key to improve information available to call agents to reduce average time-per-call and increase capacity of the call center. So I don't agree that STIR would "eliminate the need for caller identification from known TNs." But perhaps I misunderstood your last sentence? From: Fernando Mousinho (fmousinh) [ mailto:fmousinh@cisco.com] Sent: November 05, 2013 4:34 PM To: stir@ietf.org Subject: Re: [stir] draft-peterson-stir-threats-00.txt I would suggest we add a new attack type to section 3. More and more companies are using the caller ID for account validation. For example, if I call my credit card provider from my office number, they ask me for identification. If I call from my home phone number, I'm informed that I don't need to provide any further identification because my number is on file. Some (all?) companies that implement this type of validation rely on SS7 today. Ultimately, this is yet another variation of impersonation - but in this case, the "victim" is a business, unlike the other two scenarios we've listed so far. Addressing this scenario would actually turn STIR into a feature, given it would enable contact centers of all sizes to eliminate the need for caller identification from known TNs. From: Alex Bobotek < alex@bobotek.net> Date: Tuesday, October 1, 2013 at 12:51 PM To: Brian Rosen < br@brianrosen.net>, "Peterson, Jon" < jon.peterson@neustar.biz> Cc: " stir@ietf.org" < stir@ietf.org>, Richard Shockey < richard@shockey.us>, "'DOLLY, MARTIN C'" < md3135@att.com>, 'Robert Sparks' < rjsparks@nostrum.com> Subject: Re: [stir] draft-peterson-stir-threats-00.txt Jon, Thanks for the response. The intention in #1 below is to clarify the following sentence: The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a particular chosen number, one that the attacker does not have the authority to call from, in order for that number to be rendered on the terminating side. This might be misconstrued as indicating that the objective of spoofing is simply the rendering of a spoofed number on the receiving display, causing mistaken conclusions that defenses might be limited to securing the rendered information. No issues with leaving this as it's a valid point. Another (increasing) motivation is to evade network and/or endpoint defenses that may block based on CPN. So however it's worded, I think it's important to allow for both attack objectives of a spoofed presentation at the endpoint and in transit. Regards, Alex > -----Original Message----- > From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, October 01, 2013 9:29 AM > To: Peterson, Jon > Cc: stir@ietf.org; Alex Bobotek; 'Robert Sparks'; 'DOLLY, MARTIN C'; Richard > Shockey > Subject: Re: [stir] draft-peterson-stir-threats-00.txt > > Don't think there is much MESSAGE. MSRP is about all we see, and XMPP is > more likely than that. > > Brian > > On Oct 1, 2013, at 12:24 PM, "Peterson, Jon" < jon.peterson@neustar.biz> > wrote: > > > Thanks for these notes, Alex. Some responses below. > > > >> Here are several comments that should feed into the IETF Peterson draft: > >> > >> * Remove any assumptions that the solution cannot be in-network > [IMO, > >> both endpoint and in-network solutions should be facilitated] > > > > Agreed that both in-band and out-of-band solutions can usually be > > implemented in either endpoints or in intermediaries of various kinds. > > If I see text that implies otherwise, I'll certainly change it. > > > >> * Add a sessionless attack scenario. A spam payload may be carried in > a > >> SIP INVITE or MESSAGE, which might contain stock market advice even > >> in a display name field. These attacks do NOT require session > establishment. > >> More generally, we should be mindful of the fact that SIP is used in > >> telephony form more than voice session setup. > > > > Probably if we were going to include a sessionless attack scenario, it > > would be with regular text messages (whether carried on the PSTN over > > TCAP or with some Internet protocol, including MESSAGE) rather than > > with an INVITE, which typically wouldn't result in a payload being > > immediately rendered to a user. More on this below with your suggested > text. > > > >> Here's some suggested markup: > >> > >> > >> 1. Replace 2nd sentence of 2nd paragraph of 1.0 Introduction with: > >> > >> The primary attack vector is > >> therefore one where the attacker contrives for the calling telephone > >> number in signaling to be a particular chosen number that the > >> attacker does not have the authority to call from. > > > > What you want here is to remove the implication that the number will > > be rendered on the terminating side? While there are some attacks > > where that isn't significant, perhaps, I would say it is significant > > in the primary attack vectors that concern us. > > > >> 2. Replace 3rd paragraph of 2.1 Endpoints with: > >> > >> Smart devices are generally based on computers with some degree > >> of programmability, the capacity to access the Internet, and > >> capabilities of rendering text, audio and/or images. This includes > >> smart phones, telephone applications on desktop and laptop computers, > >> IP private branch exchanges, and so on. > > > > I can add the notion that smart devices can render text, audio and/or > > images as you suggest. > > > >> 3. Add to 3.3 Attack Scenarios: > >> > >> Impersonation, IP-Mobile Text Message > >> > >> An attacker with an computer sends a high volume of SIP MESSAGE > >> spam message to IP-enabled smart phones using randomized calling > >> party numbers. > >> > >> Countermeasure: in-band authenticated identity > > > > Provided we're talking about end-to-end SIP use of MESSAGE, agreed > > that in-band would be the right countermeasure. I am curious though > > whether practically speaking there is enough use of MESSAGE in this > > fashion that we're actually seeing high-volume spam over MESSAGE > > today. Either way, no problem having an attack scenario of this form in the > document. > > > > Jon Peterson > > Neustar, Inc. > > > >> Regards, > >> > >> Alex > >> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of Richard Shockey > >>> Sent: Monday, September 30, 2013 1:11 PM > >>> To: 'DOLLY, MARTIN C'; 'Robert Sparks' > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> +1 > >>> > >>> -----Original Message----- > >>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On Behalf > >>> Of DOLLY, MARTIN C > >>> Sent: Monday, September 30, 2013 12:58 PM > >>> To: Robert Sparks > >>> Cc: stir@ietf.org > >>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>> > >>> Yes, ok > >>> > >>> Martin Dolly > >>> Lead Member of Technical Staff > >>> Core Network & Gov't/Regulatory Standards AT&T Labs - Network > >>> Technology > >>> +1-609-903-3360 > >>> md3135@att.com > >>> > >>>> On Sep 30, 2013, at 12:47 PM, "Robert Sparks" > >>>> < rjsparks@nostrum.com> > >>> wrote: > >>>> > >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C wrote: > >>>>> With Hadriel comments incorporated, it is a start > >>>> Hi Martin - > >>>> > >>>> Just to make sure - I think you're referring to Hadriel's comments > >>>> on the > >>> problem statement document? > >>>> I don't think Hadriel's commented directly on stir-threats yet. > >>>> > >>>> In any case, we _are_ talking about a starting place, not a > >>>> finished > >>> product. > >>>> > >>>> If there's no other objection, I'd like to get Jon to submit the > >>>> threats > >>> document as a WG -00 as soon as it's convenient. > >>>> > >>>> RjS > >>>>> > >>>>> -----Original Message----- > >>>>> From: stir-bounces@ietf.org [ mailto:stir-bounces@ietf.org] On > >>>>> Behalf Of Russ Housley > >>>>> Sent: Thursday, September 26, 2013 4:37 PM > >>>>> To: IETF STIR Mail List > >>>>> Subject: Re: [stir] draft-peterson-stir-threats-00.txt > >>>>> > >>>>> It has been six days, I'd like to hear from more people about this > >>> document. Martin asked for an additional week, so I'm sure we will > >>> hear from him soon. > >>>>> > >>>>> Russ > >>>>> > >>>>> > >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley wrote: > >>>>>> > >>>>>> http://www.ietf.org/id/draft-peterson-stir-threats-00.txt > >>>>>> > >>>>>> Should the working group adopt this I-D as the starting point for > >>>>>> the > >>> STIR threat docuent? > >>>>>> > >>>>>> Russ > >>>>> _______________________________________________ > >>>>> 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 > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _____ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0384_01CEDBE7.C56B8790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

VCARD SCHMEECARD.. whatever. I don’t think you want to reinvent = the wheel here but I won’t argue about that. =

 

The issue is defining what set of data from a called party increases = the level of trust in the session establishment process that the = consumer generally would understand and can the network validate that = data in a reasonable manner that does not increase costs or = significantly increase post dial delay.  

 

Oh ..how would it be displayed … what would Google and Apple = need to do to put the data on the devices?  WebRTC for that matter = since IMHO its going to end up being used as a SIP client quite often. =

 

And again I think a in band solution will not work and never actually = be used by..sort of like VIPR.

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Brian Rosen
Sent: Thursday, November 07, 2013 12:10 = PM
To: Richard Shockey
Cc: stir@ietf.org List; = Gorman, Pierce A [NTK]; Fernando Mousinho (fmousinh); = cnit@ietf.org
Subject: Re: [stir] [cnit] = draft-peterson-stir-threats-00.txt

 

We’re = agreeing CNAM doesn’t work, it lies, and we have to fix = that.

 

Billing relationships are useful, but only give you = return routability properties.  Not very interesting, and billing = addresses aren’t often what is wanted.  Given various = corporate relationships that are tolerated by carriers, it would be = trivial to make the billing name be anything you wanted it to be and get = service from most carriers.  

 

I = think it IS possible to validate a name, as long as you allow a = probability of that validation to be carried, because the techniques we = have aren’t definitive.  

 

See prior reply on the category idea, which I think is = workable.

 

FWIW, I am in favor of an in band solution for CNAM - = display name of From.

 

You proposed a VCARD.  I think that is = unworkable.  Name is hard enough.  We might be able to get an = address.  All the other fields in a VCARD are pretty = dicey.

 

 

On Nov 7, 2013, at 7:16 AM, Richard Shockey <richard@shockey.us> = wrote:



 

Like CNAM is so accurate today… ??  When certain companies = get the data from scanning phone books that are not even printed = anymore?

 

The carrier has the billing relationship. As you well know that is = where the data comes from now but it is not = granular. 

 

The carrier permits the customer to create the record(s). What are = you trying to validate? The Accuracy of the data?  … In any = event none of that is our problem.   We make the tools. = Someone else worries about policy.

 

You are making this way too complicated thus defeating the basic use = case.  

 

Well from time to time I’ve discovered I’m not a big fan = of the end to end principal.  It just doesn’t work for every = use case.  This is a carrier service or in certain cases = hosted.

 

Much like I’m convinced the out of band solution in STIR is = total fantasy and like VIPR will almost never actually be used in = practice.

 

As for encoding I mentioned JCARD since there seems to be a faction = in the IETF that is anti-XML

 

From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Thursday, November 07, 2013 = 12:59 AM
To: Richard = Shockey
Cc: stir@ietf.org List; Gorman, Pierce A = [NTK]; cnit@ietf.org; Fernando = Mousinho (fmousinh)
Subject: Re: [cnit] [stir] = draft-peterson-stir-threats-00.txt

 

I think this would be a heavy = lift.

 

If the responsible entity was a carrier, then it would = have to validate the data, which it has very little basis to validate. =  It could get a 3rd party to do the validation, but then it’s = putting its reputation on the back of some hired hand = validator.

 

If the responsibility is the end user/device, then the = signature has no value.

 

I do not argue that Call-Info is suitable,  it = is.

 

I do question JCARD vs xCard, but that’s an = encoding detail.  All of SIP Is XML described by schema, not = json.

 

Brian

 

On Nov 6, 2013, at 1:10 PM, Richard Shockey <richard@shockey.us> = wrote:




URI for a JCARD in the CALL INFO header provisioned by the calling = party and ultimately signed by the responsible entity.  The carrier = could provision this for their mobile or hosted customers.  = Enterprises could do this themselves.  This also has advantages in = Enterprise to Enterprise UC as well where the data is derived from the = Enterprise “directory” and could facilitate end to end PPX = to PBX communications especially in point to point video = communications.

 

There are certainly privacy and security issues to be = addressed.  The Push vs Pull model.  This really would be PII = in the clear but then its done = voluntarily.

 

There would have to be some work around restructuring the Header and = adding some parameters but it’s underutilized right now and this = Use Case is a perfectly appropriate = use.

 

 

Obviously it would need to be signed but we don’t need to worry = about that ..yet.

 

From 3261

 

20.9 Call-Info

 

   The Call-Info header field provides additional = information about the

   caller or callee, depending on whether it is found in a = request or

   response.  The purpose of the URI is described by = the "purpose"

   parameter.  The "icon" parameter = designates an image suitable as an

   iconic representation of the caller or callee.  The = "info" parameter

   describes the caller or callee in general, for example, = through a web

   page.  The "card" parameter provides a = business card, for example, in

   vCard [36] or LDIF [37] formats.  Additional tokens = can be registered

   using IANA and the procedures in Section = 27.

 

   Use of the Call-Info header field can pose a security = risk.  If a

   callee fetches the URIs provided by a malicious caller, = the callee

   may be at risk for displaying inappropriate or offensive = content,

   dangerous or illegal content, and so on.  = Therefore, it is

   RECOMMENDED that a UA only render the information in the = Call-Info

   header field if it can verify the authenticity of the = element that

   originated the header field and trusts that = element.  This need not

   be the peer UA; a proxy can insert this header field = into requests.

 

   Example:

 

   Call-Info: <http://wwww.example.com/alice/photo.jpg= > ;purpose=3Dicon,

     <http://www.example.com/alice/> = ;purpose=3Dinfo

 

From: Brian = Rosen [mailto:br@brianrosen.net] 
Sent: Wednesday, November 06, 2013 = 3:41 PM
To: Richard = Shockey
Cc: Fernando Mousinho (fmousinh); = Gorman, Pierce A [NTK]; stir@ietf.org List
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

We’ve considered adding some information that is = not number and is not name, but is something like “bank”, = which might have some sort of validation behind = it.

 

Is that along the lines you were = thinking?

 

Brian

On Nov 6, 2013, at 5:25 AM, Richard Shockey <richard@shockey.us> = wrote:





I agree with Pierce here and respectfully disagree that STIR might = eliminate the need for other forms of caller identification.  = Though your use case of credit card validation is a useful one and you = are right there are still applications that use SS7 for things that have = nothing to do with call setup. I agree with you STIR may have more = applications beyond the obvious ones of realtime session = validation.

 

It’s been my experience recently that there is a use case for = something MORE in the identification of the session as it is presented = to the called party. This is the CNAM + idea we are kicking around on = the CNIT list.

 

_______________________________________________

<= /div>

cnit mailing list

 

But your use case of a bank wanting to make sure they could properly = identify themselves to the consumer before establishing a conversation = is exactly what this process is about.  STIR is essential but = it’s a multi-faceted problem that may require multi-faceted = solutions.. and enhanced CNAM + being only one of them.   Its = not unreasonable to discuss = those.

 

The obviously analogy is I would want to see some real identification = of a utility worker before I let them into my house to make repairs. =  I would want some validation that the call to me to reconfirm the = appointments was in fact from the utility in = question.

 

 

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Fernando Mousinho = (fmousinh)
Sent: Tuesday, November 05, 2013 = 6:26 PM
To: Gorman, Pierce A [NTK]; stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

Let me = rephrase it… it may eliminate the need for other forms of caller = identification beyond what STIR will provide, depending on the specific = use case. For example, a credit card company may choose to rely entirely = on STIR before allowing a card to be unblocked by an IVR (and as I said = earlier, many companies do it today). In other use cases, the TN alone = is not sufficient information – my health care provider will want = to know which member of the family is = calling.

 

I agree = that ANI is already broadly used to improve customer service today. = However, it is not usually deemed as a secure enough mechanism to = validate the caller (therefore this WG!), except if you are a large = organization that can leverage things like SS7. STIR would make this = type of validation available to a broader number of = companies.

 

 

Going on a = tangent… perhaps this is out of scope, but there is not a lot of = discussion about called party hijacking. Couldn’t a = man-in-the-middle try to answer calls on my behalf? If my bank is = calling me, I want to make sure it’s really them before carrying a = conversation, but wouldn’t they want the = same? 

 

 

From: <Gorman&= gt;, "Pierce A [NTK]" <Pierce.Gorman@sprint.com>
Dat= e: Tuesday, November = 5, 2013 at 6:05 PM
To: Fernando Mousinho <fmousinh@cisco.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] = draft-peterson-stir-threats-00.txt

=

 

I agree with your characterization of businesses as victim of caller ID = fraud however contact centers also use TN as a key to improve = information available to call agents to reduce average time-per-call and = increase capacity of the call center.  So I don’t agree that = STIR would “eliminate the need for caller identification from = known TNs.”

 

But perhaps I misunderstood your last = sentence?

 

 

From:=  Fernando = Mousinho (fmousinh) [mailto:fmousinh@cisco.com] 
Sent: November 05, 2013 4:34 = PM
To: stir@ietf.org
Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

 

I would = suggest we add a new attack type to section 3. More and more companies = are using the caller ID for account validation. For example, if I call = my credit card provider from my office number, they ask me for = identification. If I call from my home phone number, I’m informed = that I don’t need to provide any further identification because my = number is on file. Some (all?) companies that implement this type of = validation rely on SS7 = today.

 

Ultimately,= this is yet another variation of impersonation – but in this = case, the “victim” is a business, unlike the other two = scenarios we’ve listed so = far.

 

Addressing = this scenario would actually turn STIR into a feature, given it would = enable contact centers of all sizes to eliminate the need for caller = identification from known = TNs.

 

 

 

From: Alex = Bobotek <alex@bobotek.net>
Date: Tuesday, October 1, 2013 = at 12:51 PM
To: Brian Rosen <br@brianrosen.net>, = "Peterson, Jon" <jon.peterson@neustar.biz>
Cc:=  "stir@ietf.org" <stir@ietf.org>, Richard Shockey = <richard@shockey.us>, "'DOLLY, = MARTIN C'" <md3135@att.com>, 'Robert Sparks' = <rjsparks@nostrum.com>
Subject= : Re: [stir] = draft-peterson-stir-threats-00.txt

=

 

Jon,=

 

Thanks for = the response.  The intention in #1 below is to clarify the = following sentence:

 

The primary attack vector = is

  = ; therefore one where the attacker contrives for the calling = telephone

  = ; number in signaling to be a particular chosen number, one that = the

  = ; attacker does not have the authority to call from, in order for = that

  = ; number to be rendered on the terminating side. 

 

This might = be misconstrued as indicating that the objective of spoofing is simply = the rendering of a spoofed number on the receiving display, causing = mistaken conclusions that defenses might be limited to securing the = rendered information.  No issues with leaving this as it’s a = valid point.  Another (increasing) motivation is to evade network = and/or endpoint defenses that may block based on = CPN. 

 

So however = it’s worded, I think it’s important to allow for both attack = objectives of a spoofed presentation at the endpoint and in = transit.   

 

Regards,

 

Alex=

 

> = -----Original Message-----

> Brian = Rosen

> Sent: = Tuesday, October 01, 2013 9:29 = AM

> To: = Peterson, Jon

> = Cc: stir@ietf.org; Alex Bobotek; 'Robert = Sparks'; 'DOLLY, MARTIN C'; = Richard

> = Shockey

> = Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> <= /span>

> Don't = think there is much MESSAGE.  MSRP is about all we see, and XMPP = is

> more = likely than that.

> <= /span>

> = Brian

> <= /span>

> On = Oct 1, 2013, at 12:24 PM, "Peterson, Jon" <jon.peterson@neustar.biz<= /span>>

> = wrote:

> <= /span>

> > = Thanks for these notes, Alex. Some responses = below.

> = >

> = >> Here are several comments that should feed into the IETF = Peterson draft:

> = >>

> = >> *   Remove any assumptions that the solution cannot = be in-network

> = [IMO,

> = >> both endpoint and in-network solutions should be = facilitated]

> = >

> > = Agreed that both in-band and out-of-band solutions can usually = be

> > = implemented in either endpoints or in intermediaries of various = kinds.

> > = If I see text that implies otherwise, I'll certainly change = it.

> = >

> = >> *   Add a sessionless attack scenario.  A spam = payload may be carried in

> = a

> = >> SIP INVITE or MESSAGE, which might contain stock market advice = even

> = >> in a display name field.  These attacks do NOT require = session

> = establishment.

> = >> More generally, we should be mindful of the fact that SIP is = used in

> = >> telephony form more than voice session = setup.

> = >

> > = Probably if we were going to include a sessionless attack scenario, = it

> > = would be with regular text messages (whether carried on the PSTN = over

> > = TCAP or with some Internet protocol, including MESSAGE) rather = than

> > = with an INVITE, which typically wouldn't result in a payload = being

> > = immediately rendered to a user. More on this below with your = suggested

> = text.

> = >

> = >> Here's some suggested = markup:

> = >>

> = >>

> = >> 1.    Replace 2nd sentence of 2nd paragraph of = 1.0 Introduction with:

> = >>

> = >> The primary attack vector = is

> = >>  therefore one where the attacker contrives for the = calling telephone

> = >> number in signaling to be a particular chosen number that = the

> = >> attacker does not have the authority to call = from.

> = >

> > = What you want here is to remove the implication that the number = will

> > = be rendered on the terminating side? While there are some = attacks

> > = where that isn't significant, perhaps, I would say it is = significant

> > = in the primary attack vectors that concern = us.

> = >

> = >> 2.  Replace 3rd paragraph of 2.1 Endpoints = with:

> = >>

> = >>     Smart devices are generally based on = computers with some degree

> = >> of programmability, the capacity to access the Internet, = and

> = >> capabilities of rendering text, audio and/or images.  This = includes

> = >> smart phones, telephone applications on desktop and laptop = computers,

> = >> IP private branch exchanges, and so = on.

> = >

> > = I can add the notion that smart devices can render text, audio = and/or

> > = images as you suggest.

> = >

> = >> 3.  Add to 3.3 Attack = Scenarios:

> = >>

> = >>       Impersonation, IP-Mobile Text = Message

> = >>

> = >>        An attacker with an = computer sends a high volume of SIP = MESSAGE

> = >> spam message to IP-enabled smart phones using randomized = calling

> = >> party numbers.

> = >>

> = >>       Countermeasure: in-band = authenticated identity

> = >

> > = Provided we're talking about end-to-end SIP use of MESSAGE, = agreed

> > = that in-band would be the right countermeasure. I am curious = though

> > = whether practically speaking there is enough use of MESSAGE in = this

> > = fashion that we're actually seeing high-volume spam over = MESSAGE

> > = today. Either way, no problem having an attack scenario of this form in = the

> = document.

> = >

> > = Jon Peterson

> > = Neustar, Inc.

> = >

> = >> Regards,

> = >>

> = >> Alex

> = >>

> = >>> -----Original = Message-----

> = >>> Of Richard = Shockey

> = >>> Sent: Monday, September 30, 2013 1:11 = PM

> = >>> To: 'DOLLY, MARTIN C'; 'Robert = Sparks'

> = >>> Cc: stir@ietf.org<= /span>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> = >>>

> = >>> +1

> = >>>

> = >>> -----Original = Message-----

> = >>> Of DOLLY, MARTIN = C

> = >>> Sent: Monday, September 30, 2013 12:58 = PM

> = >>> To: Robert = Sparks

> = >>> Cc: stir@ietf.org<= /span>

> = >>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> = >>>

> = >>> Yes, ok

> = >>>

> = >>> Martin Dolly

> = >>> Lead Member of Technical = Staff

> = >>> Core Network & Gov't/Regulatory Standards AT&T Labs = - Network

> = >>> Technology

> = >>> = +1-609-903-3360

> = >>> md3135@att.com=

> = >>>

> = >>>> On Sep 30, 2013, at 12:47 PM, "Robert = Sparks"

> = >>> wrote:

> = >>>>

> = >>>>> On 9/26/13 3:42 PM, DOLLY, MARTIN C = wrote:

> = >>>>> With Hadriel comments incorporated, it is a = start

> = >>>> Hi Martin = -

> = >>>>

> = >>>> Just to make sure - I think you're referring to = Hadriel's comments

> = >>>> on the

> = >>> problem statement = document?

> = >>>> I don't think Hadriel's commented directly on = stir-threats yet.

> = >>>>

> = >>>> In any case, we _are_ talking about a starting place, = not a

> = >>>> finished

> = >>> product.

> = >>>>

> = >>>> If there's no other objection, I'd like to get Jon to = submit the

> = >>>> threats

> = >>> document as a WG -00 as soon as it's = convenient.

> = >>>>

> = >>>> RjS

> = >>>>>

> = >>>>> -----Original = Message-----

> = >>>>> Behalf Of Russ = Housley

> = >>>>> Sent: Thursday, September 26, 2013 4:37 = PM

> = >>>>> To: IETF STIR Mail = List

> = >>>>> Subject: Re: [stir] = draft-peterson-stir-threats-00.txt

=

> = >>>>>

> = >>>>> It has been six days, I'd like to hear from more = people about this

> = >>> document.  Martin asked for an additional week, so I'm = sure we will

> = >>> hear from him = soon.

> = >>>>>

> = >>>>> Russ

> = >>>>>

> = >>>>>

> = >>>>>> On Sep 20, 2013, at 5:23 PM, Russ Housley = wrote:

> = >>>>>>

> = >>>>>>

> = >>>>>> Should the working group adopt this I-D as the = starting point for

> = >>>>>> = the

> = >>> STIR threat = docuent?

> = >>>>>>

> = >>>>>> = Russ

> = >>>>> = _______________________________________________

> = >>>>> stir mailing = list

> = >>>>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >>>>

> = >>>> = _______________________________________________

> = >>>> stir mailing = list

> = >>>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >>> = _______________________________________________

> = >>> stir mailing = list

> = >>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >>>

> = >>> = _______________________________________________

> = >>> stir mailing = list

> = >>> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >> = _______________________________________________

> = >> stir mailing list

> = >> stir@ietf.org<= /span>

<= p class=3DMsoNormal>> = >

> > = _______________________________________________

> > = stir mailing list

> = > stir@ietf.org<= /span>

<= p class=3DMsoNormal>> <= /span>

> = _______________________________________________

> stir = mailing list

> stir@ietf.org<= /span>

 

This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

__________= _____________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir<= /a>

 

------=_NextPart_000_0384_01CEDBE7.C56B8790-- From wolfgang.beck01@googlemail.com Thu Nov 7 16:12:24 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D23911E828F for ; Thu, 7 Nov 2013 16:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVnzF5awbwRI for ; Thu, 7 Nov 2013 16:12:22 -0800 (PST) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 060B621E80E6 for ; Thu, 7 Nov 2013 16:12:12 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id oy12so955499veb.11 for ; Thu, 07 Nov 2013 16:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LNTHbexUryyNxj/EPr78pTLpR+dt0dEqPQIeLUH4E+o=; b=luHpE0JBfjgVd/zLmEH8C70emEtzY2umA+7qrjpI7ECFvVHivcXvuAuLqf0zdZggn3 ZGjdD1JUIYlBooAY99WOLTE71a42qx2COCLUOrpx+4iuL+p4WWWSDMAK82KVk+bbNyIG ITTxNAWQBuB3/dxVSLwYSuVnoAY9CmB/PC8PsatNbq5Sr2uaB2VE4hkVo1wqkIcp/K/q WT2BFNbtbNx0xjxJ4C9CEQGZjWkyYgWH0m2NCwn0qpwckcd0aoyZO9AV1uL7QlPLJlbi a1ZCYnN9UTtpv1MLo6nOGwLczPRbBtv0oT//GxqGvXaZIiskt5nOKVLVpMwWgKTfKq8C ck8A== MIME-Version: 1.0 X-Received: by 10.52.30.104 with SMTP id r8mr3029915vdh.18.1383869527303; Thu, 07 Nov 2013 16:12:07 -0800 (PST) Received: by 10.58.45.169 with HTTP; Thu, 7 Nov 2013 16:12:07 -0800 (PST) Received: by 10.58.45.169 with HTTP; Thu, 7 Nov 2013 16:12:07 -0800 (PST) In-Reply-To: <596979554D802045BBD45C051A4399E40D40C6EE@STNTEXMB10.cis.neustar.com> References: <596979554D802045BBD45C051A4399E40D40C6EE@STNTEXMB10.cis.neustar.com> Date: Fri, 8 Nov 2013 01:12:07 +0100 Message-ID: From: Wolfgang Beck To: Jon Peterson Content-Type: multipart/alternative; boundary=20cf3079c09a972aec04ea9f3bdc Cc: stir@ietf.org Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:12:24 -0000 --20cf3079c09a972aec04ea9f3bdc Content-Type: text/plain; charset=ISO-8859-1 VIPR, whatsapp, iMessage all use the phone network for verification. Public ENUM registrars used it. The principle seems to be working for sufficiently large number of cases. Am 07.11.2013 14:38 schrieb "Peterson, Jon" : > > I believe that SIP messages routed to telephone numbers today are mostly > frequently dropped to the PSTN, and may eventually re-enter the Internet or > not. In cases where requests targeting telephone numbers do travel > end-to-end over the Internet, various flat files and private databases are > consulted to forward requests hop-by-hop until they reach a destination. > The relationships of those mechanisms to numbering authorities can be > tenuous today, precisely because of the absence of the authority > architecture this working group is considering. > > There's no free lunch here. > > Jon Peterson > Neustar, Inc. > > > > Sent with Good (www.good.com) > > > -----Original Message----- > *From: *Wolfgang Beck [wolfgang.beck01@googlemail.com] > *Sent: *Thursday, November 07, 2013 05:23 PM Eastern Standard Time > *To: *Peterson, Jon > *Cc: *stir@ietf.org > *Subject: *RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' > > Would you agree that such a SIP message would arrive at an element of a > party that has delegated the number to its current user? Solving the > problem 'who owns this number?' seems easier to me inside the system than > in a separate one. > Am 07.11.2013 13:26 schrieb "Peterson, Jon" : > >> Various "callback" mechanisms along these lines have been considered, and >> there are known limitations of these mechanisms, most of which result from >> the fact that placing a call from a number does not guarantee that a >> returned call would reach the same endpoint instance. Gateways, call >> centers, users with multiple concurrently registered devices, all of our >> "doctor's office" use cases and related configurations show why approaches >> along these lines are insufficient. >> >> Jon Peterson >> Neustar, inc. >> >> >> >> Sent with Good (www.good.com) >> >> >> -----Original Message----- >> *From: *Wolfgang Beck [wolfgang.beck01@googlemail.com] >> *Sent: *Thursday, November 07, 2013 04:18 PM Eastern Standard Time >> *To: *stir@ietf.org >> *Subject: *[stir] new SIP Method DYPTC 'Did You Place This Call?' >> >> Here's a half-baked idea: when a call c1 arives from , I send a >> DYPTC SIP request message outside of this call back to . The DYPTC >> request carries some headers that describe c1, eg. the original from and to. >> >> - if the receiving UA is indeed , it responds with 200 OK. The origin >> of call c1 is now verified. >> >> - if was spoofed by somebody, the request will arrive at a UA that >> does not know about the call described by DYPTC. It responds with 404 Not >> Found >> >> - if was spoofed and there is no UA reachable, the request will time >> out or the network will generate a 404 Not found. >> >> Whenever I dont receive a 200 OK on a DYPTC, the calling number could >> not be verified. >> >> So far all methods to determine a party that can verify a number seem >> to boil down to one of the two groups: >> >> 1. create a new database, replicated from the telcos' databases, that >> can be accessed by end devices. That's what iMessage, whatsapp, and VIPR >> try to do. Accurately replicating a fairly dynamic database without its >> cooperation is a challenge. >> >> 2. create a way so that end devices can directly query the telcos' >> databases. DNS is an obvious candidate for this. >> >> However, accessing the database itself is not enough. The end device >> would have to replicate all routing decisions the telcos make. All >> discussions about PBXs and number portability are essentially about the >> routing inside the telcos. >> >> Why not just use the existing platform to verify calling numbers? >> >> >> Wolfgang Beck >> > --20cf3079c09a972aec04ea9f3bdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

VIPR, whatsapp, iMessage all use the phone network for verif= ication. Public ENUM registrars used it. The principle seems to be working = for sufficiently large number of cases.

Am 07.11.2013 14:38 schrieb "Peterson, Jon&= quot; <jon.peterson@neustar.= biz>:

I believe that SIP messages routed to telephone numbers today are mostly fr= equently dropped to the PSTN, and may eventually re-enter the Internet or n= ot. In cases where requests targeting telephone numbers do travel end-to-en= d over the Internet, various flat files and private databases are consulted to forward requests hop-by-hop u= ntil they reach a destination. The relationships of those mechanisms to num= bering authorities can be tenuous today, precisely because of the absence o= f the authority architecture this working group is considering.

There's no free lunch here.

Jon Peterson
Neustar, Inc.



Sent with Good (www.good.= com)


-----Original Message-----
From:=A0Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent:=A0Thursday, November 07, 2013 05:23 PM Eastern Standard Time To:=A0Peterson, Jon
Cc:=A0stir@ietf.o= rg
Subject:=A0RE: [stir] new SIP Method DYPTC 'Did You Place This C= all?'

Would you agree that such a SIP message would arrive at an e= lement of a party that has delegated the number to its current user? Solvin= g the problem 'who owns this number?' seems easier to me inside the= system than in a separate one.

Am 07.11.2013 13:26 schrieb "Peterson, Jon&= quot; <jon= .peterson@neustar.biz>:
Various "callback" mechanisms along these lines have been co= nsidered, and there are known limitations of these mechanisms, most of whic= h result from the fact that placing a call from a number does not guarantee= that a returned call would reach the same endpoint instance. Gateways, call centers, users with multiple concurrentl= y registered devices, all of our "doctor's office" use cases = and related configurations show why approaches along these lines are insuff= icient.

Jon Peterson
Neustar, inc.



Sent with Good (www.good.= com)


-----Original Message-----
From:=A0Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent:=A0Thursday, November 07, 2013 04:18 PM Eastern Standard Time To:=A0stir@ietf.o= rg
Subject:=A0[stir] new SIP Method DYPTC 'Did You Place This Call?= '

Here's a half-baked idea: when a call c1 arives from <a>, I = send a DYPTC SIP request message outside of this call back to <a>. Th= e DYPTC request carries some headers that describe c1, eg. the original fro= m and to.

- if the receiving UA is indeed <a>, it responds with 200 OK. The ori= gin of call c1 is now verified.

- if <a> was spoofed by somebody, the request will arrive at a UA tha= t does not know about the call described by DYPTC. It responds with 404 Not= Found

- if <a> was spoofed and there is no UA reachable, the request will t= ime out or the network will generate a 404 Not found.

Whenever I dont receive a 200 OK on a DYPTC, the calling number could = not be verified.

So far all methods to determine a party that can verify a number seem = to boil down to one of the two groups:

1. create a new database, replicated from the telcos' databases, that c= an be accessed by end devices. That's what iMessage, whatsapp, and VIPR= try to do. Accurately replicating a fairly dynamic database without its co= operation is a challenge.

2. create a way so that end devices can directly query the telcos' data= bases. DNS is an obvious candidate for this.

However, accessing the database itself is not enough. The end device would = have to replicate all routing decisions the telcos make. All discussions ab= out PBXs and number portability are essentially about the routing inside th= e telcos.

Why not just use the existing platform to verify calling numbers?


Wolfgang Beck
--20cf3079c09a972aec04ea9f3bdc-- From jon.peterson@neustar.biz Thu Nov 7 16:24:35 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBBD21E81A7 for ; Thu, 7 Nov 2013 16:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.323 X-Spam-Level: X-Spam-Status: No, score=-106.323 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkK5U23-oT4P for ; Thu, 7 Nov 2013 16:24:31 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id DB2C921E81C8 for ; Thu, 7 Nov 2013 16:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383870873; x=1699222765; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=SanWFa6AEhStc9gUJcNeQYkqAMOrq9CYkGI3wbItpDw=; b=YTlzasL03KG6o4Or8NpqS/493xM9JmQG7kiQRJq61h6vC+bzFGJWszOyADhCHx NBEoQhd2sk6VHGx/35MBku6Q== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.35161394; Thu, 07 Nov 2013 19:34:32 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.5]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 7 Nov 2013 19:24:27 -0500 From: "Peterson, Jon" To: 'Wolfgang Beck' Thread-Topic: [stir] new SIP Method DYPTC 'Did You Place This Call?' Thread-Index: AQHO2/759gVKPWtkUE25HikC9AzlgJoaSAi0gABjqYD//7BZ0oAAbhuA//+voQ8= Date: Fri, 8 Nov 2013 00:24:27 +0000 Message-ID: <596979554D802045BBD45C051A4399E40D40C829@STNTEXMB10.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.15.96] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: SGap4+oUIjvtlMthUUbXBg== Content-Type: multipart/alternative; boundary="_000_596979554D802045BBD45C051A4399E40D40C829STNTEXMB10cisne_" MIME-Version: 1.0 Cc: "'stir@ietf.org'" Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:24:35 -0000 --_000_596979554D802045BBD45C051A4399E40D40C829STNTEXMB10cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhvc2UgdmVyaWZpY2F0aW9uIHN5c3RlbXMgbGlrZSBWSVBSIGFuZCBXaGF0c2FwcCBhcmUgcmVs aWFibGUgb25seSBpbiBzbyBmYXIgYXMgdGhlaXIgY2FsbCBzaWduYWxpbmcgZ29lcyBleGNsdXNp dmVseSB0aHJvdWdoIHRoZSBQU1ROIC0gdGhlIERZUFRDIG1ldGhvZCB3b3VsZG4ndCBnbyBvdmVy IFNTNyB1bmZvcnR1bmF0ZWx5Lg0KDQpKb24gUGV0ZXJzb24NCk5ldXN0YXIsIEluYy4NCg0KDQoN ClNlbnQgd2l0aCBHb29kICh3d3cuZ29vZC5jb20pDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFdvbGZnYW5nIEJlY2sgW3dvbGZnYW5nLmJlY2swMUBnb29nbGVtYWlsLmNv bTxtYWlsdG86d29sZmdhbmcuYmVjazAxQGdvb2dsZW1haWwuY29tPl0NClNlbnQ6IFRodXJzZGF5 LCBOb3ZlbWJlciAwNywgMjAxMyAwNzoxMiBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOiBQ ZXRlcnNvbiwgSm9uDQpDYzogc3RpckBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzdGlyXSBuZXcg U0lQIE1ldGhvZCBEWVBUQyAnRGlkIFlvdSBQbGFjZSBUaGlzIENhbGw/Jw0KDQoNClZJUFIsIHdo YXRzYXBwLCBpTWVzc2FnZSBhbGwgdXNlIHRoZSBwaG9uZSBuZXR3b3JrIGZvciB2ZXJpZmljYXRp b24uIFB1YmxpYyBFTlVNIHJlZ2lzdHJhcnMgdXNlZCBpdC4gVGhlIHByaW5jaXBsZSBzZWVtcyB0 byBiZSB3b3JraW5nIGZvciBzdWZmaWNpZW50bHkgbGFyZ2UgbnVtYmVyIG9mIGNhc2VzLg0KDQpB bSAwNy4xMS4yMDEzIDE0OjM4IHNjaHJpZWIgIlBldGVyc29uLCBKb24iIDxqb24ucGV0ZXJzb25A bmV1c3Rhci5iaXo8bWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpej4+Og0KDQpJIGJlbGll dmUgdGhhdCBTSVAgbWVzc2FnZXMgcm91dGVkIHRvIHRlbGVwaG9uZSBudW1iZXJzIHRvZGF5IGFy ZSBtb3N0bHkgZnJlcXVlbnRseSBkcm9wcGVkIHRvIHRoZSBQU1ROLCBhbmQgbWF5IGV2ZW50dWFs bHkgcmUtZW50ZXIgdGhlIEludGVybmV0IG9yIG5vdC4gSW4gY2FzZXMgd2hlcmUgcmVxdWVzdHMg dGFyZ2V0aW5nIHRlbGVwaG9uZSBudW1iZXJzIGRvIHRyYXZlbCBlbmQtdG8tZW5kIG92ZXIgdGhl IEludGVybmV0LCB2YXJpb3VzIGZsYXQgZmlsZXMgYW5kIHByaXZhdGUgZGF0YWJhc2VzIGFyZSBj b25zdWx0ZWQgdG8gZm9yd2FyZCByZXF1ZXN0cyBob3AtYnktaG9wIHVudGlsIHRoZXkgcmVhY2gg YSBkZXN0aW5hdGlvbi4gVGhlIHJlbGF0aW9uc2hpcHMgb2YgdGhvc2UgbWVjaGFuaXNtcyB0byBu dW1iZXJpbmcgYXV0aG9yaXRpZXMgY2FuIGJlIHRlbnVvdXMgdG9kYXksIHByZWNpc2VseSBiZWNh dXNlIG9mIHRoZSBhYnNlbmNlIG9mIHRoZSBhdXRob3JpdHkgYXJjaGl0ZWN0dXJlIHRoaXMgd29y a2luZyBncm91cCBpcyBjb25zaWRlcmluZy4NCg0KVGhlcmUncyBubyBmcmVlIGx1bmNoIGhlcmUu DQoNCkpvbiBQZXRlcnNvbg0KTmV1c3RhciwgSW5jLg0KDQoNCg0KU2VudCB3aXRoIEdvb2QgKHd3 dy5nb29kLmNvbTxodHRwOi8vd3d3Lmdvb2QuY29tPikNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogV29sZmdhbmcgQmVjayBbd29sZmdhbmcuYmVjazAxQGdvb2dsZW1haWwu Y29tPG1haWx0bzp3b2xmZ2FuZy5iZWNrMDFAZ29vZ2xlbWFpbC5jb20+XQ0KU2VudDogVGh1cnNk YXksIE5vdmVtYmVyIDA3LCAyMDEzIDA1OjIzIFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86 IFBldGVyc29uLCBKb24NCkNjOiBzdGlyQGlldGYub3JnPG1haWx0bzpzdGlyQGlldGYub3JnPg0K U3ViamVjdDogUkU6IFtzdGlyXSBuZXcgU0lQIE1ldGhvZCBEWVBUQyAnRGlkIFlvdSBQbGFjZSBU aGlzIENhbGw/Jw0KDQoNCldvdWxkIHlvdSBhZ3JlZSB0aGF0IHN1Y2ggYSBTSVAgbWVzc2FnZSB3 b3VsZCBhcnJpdmUgYXQgYW4gZWxlbWVudCBvZiBhIHBhcnR5IHRoYXQgaGFzIGRlbGVnYXRlZCB0 aGUgbnVtYmVyIHRvIGl0cyBjdXJyZW50IHVzZXI/IFNvbHZpbmcgdGhlIHByb2JsZW0gJ3dobyBv d25zIHRoaXMgbnVtYmVyPycgc2VlbXMgZWFzaWVyIHRvIG1lIGluc2lkZSB0aGUgc3lzdGVtIHRo YW4gaW4gYSBzZXBhcmF0ZSBvbmUuDQoNCkFtIDA3LjExLjIwMTMgMTM6MjYgc2NocmllYiAiUGV0 ZXJzb24sIEpvbiIgPGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpejxtYWlsdG86am9uLnBldGVyc29u QG5ldXN0YXIuYml6Pj46DQpWYXJpb3VzICJjYWxsYmFjayIgbWVjaGFuaXNtcyBhbG9uZyB0aGVz ZSBsaW5lcyBoYXZlIGJlZW4gY29uc2lkZXJlZCwgYW5kIHRoZXJlIGFyZSBrbm93biBsaW1pdGF0 aW9ucyBvZiB0aGVzZSBtZWNoYW5pc21zLCBtb3N0IG9mIHdoaWNoIHJlc3VsdCBmcm9tIHRoZSBm YWN0IHRoYXQgcGxhY2luZyBhIGNhbGwgZnJvbSBhIG51bWJlciBkb2VzIG5vdCBndWFyYW50ZWUg dGhhdCBhIHJldHVybmVkIGNhbGwgd291bGQgcmVhY2ggdGhlIHNhbWUgZW5kcG9pbnQgaW5zdGFu Y2UuIEdhdGV3YXlzLCBjYWxsIGNlbnRlcnMsIHVzZXJzIHdpdGggbXVsdGlwbGUgY29uY3VycmVu dGx5IHJlZ2lzdGVyZWQgZGV2aWNlcywgYWxsIG9mIG91ciAiZG9jdG9yJ3Mgb2ZmaWNlIiB1c2Ug Y2FzZXMgYW5kIHJlbGF0ZWQgY29uZmlndXJhdGlvbnMgc2hvdyB3aHkgYXBwcm9hY2hlcyBhbG9u ZyB0aGVzZSBsaW5lcyBhcmUgaW5zdWZmaWNpZW50Lg0KDQpKb24gUGV0ZXJzb24NCk5ldXN0YXIs IGluYy4NCg0KDQoNClNlbnQgd2l0aCBHb29kICh3d3cuZ29vZC5jb208aHR0cDovL3d3dy5nb29k LmNvbT4pDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdvbGZnYW5nIEJl Y2sgW3dvbGZnYW5nLmJlY2swMUBnb29nbGVtYWlsLmNvbTxtYWlsdG86d29sZmdhbmcuYmVjazAx QGdvb2dsZW1haWwuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwNywgMjAxMyAwNDox OCBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOiBzdGlyQGlldGYub3JnPG1haWx0bzpzdGly QGlldGYub3JnPg0KU3ViamVjdDogW3N0aXJdIG5ldyBTSVAgTWV0aG9kIERZUFRDICdEaWQgWW91 IFBsYWNlIFRoaXMgQ2FsbD8nDQoNCkhlcmUncyBhIGhhbGYtYmFrZWQgaWRlYTogd2hlbiBhIGNh bGwgYzEgYXJpdmVzIGZyb20gPGE+LCBJIHNlbmQgYSBEWVBUQyBTSVAgcmVxdWVzdCBtZXNzYWdl IG91dHNpZGUgb2YgdGhpcyBjYWxsIGJhY2sgdG8gPGE+LiBUaGUgRFlQVEMgcmVxdWVzdCBjYXJy aWVzIHNvbWUgaGVhZGVycyB0aGF0IGRlc2NyaWJlIGMxLCBlZy4gdGhlIG9yaWdpbmFsIGZyb20g YW5kIHRvLg0KDQotIGlmIHRoZSByZWNlaXZpbmcgVUEgaXMgaW5kZWVkIDxhPiwgaXQgcmVzcG9u ZHMgd2l0aCAyMDAgT0suIFRoZSBvcmlnaW4gb2YgY2FsbCBjMSBpcyBub3cgdmVyaWZpZWQuDQoN Ci0gaWYgPGE+IHdhcyBzcG9vZmVkIGJ5IHNvbWVib2R5LCB0aGUgcmVxdWVzdCB3aWxsIGFycml2 ZSBhdCBhIFVBIHRoYXQgZG9lcyBub3Qga25vdyBhYm91dCB0aGUgY2FsbCBkZXNjcmliZWQgYnkg RFlQVEMuIEl0IHJlc3BvbmRzIHdpdGggNDA0IE5vdCBGb3VuZA0KDQotIGlmIDxhPiB3YXMgc3Bv b2ZlZCBhbmQgdGhlcmUgaXMgbm8gVUEgcmVhY2hhYmxlLCB0aGUgcmVxdWVzdCB3aWxsIHRpbWUg b3V0IG9yIHRoZSBuZXR3b3JrIHdpbGwgZ2VuZXJhdGUgYSA0MDQgTm90IGZvdW5kLg0KDQpXaGVu ZXZlciBJIGRvbnQgcmVjZWl2ZSBhIDIwMCBPSyBvbiBhIERZUFRDLCB0aGUgY2FsbGluZyBudW1i ZXIgY291bGQgbm90IGJlIHZlcmlmaWVkLg0KDQpTbyBmYXIgYWxsIG1ldGhvZHMgdG8gZGV0ZXJt aW5lIGEgcGFydHkgdGhhdCBjYW4gdmVyaWZ5IGEgbnVtYmVyIHNlZW0gdG8gYm9pbCBkb3duIHRv IG9uZSBvZiB0aGUgdHdvIGdyb3VwczoNCg0KMS4gY3JlYXRlIGEgbmV3IGRhdGFiYXNlLCByZXBs aWNhdGVkIGZyb20gdGhlIHRlbGNvcycgZGF0YWJhc2VzLCB0aGF0IGNhbiBiZSBhY2Nlc3NlZCBi eSBlbmQgZGV2aWNlcy4gVGhhdCdzIHdoYXQgaU1lc3NhZ2UsIHdoYXRzYXBwLCBhbmQgVklQUiB0 cnkgdG8gZG8uIEFjY3VyYXRlbHkgcmVwbGljYXRpbmcgYSBmYWlybHkgZHluYW1pYyBkYXRhYmFz ZSB3aXRob3V0IGl0cyBjb29wZXJhdGlvbiBpcyBhIGNoYWxsZW5nZS4NCg0KMi4gY3JlYXRlIGEg d2F5IHNvIHRoYXQgZW5kIGRldmljZXMgY2FuIGRpcmVjdGx5IHF1ZXJ5IHRoZSB0ZWxjb3MnIGRh dGFiYXNlcy4gRE5TIGlzIGFuIG9idmlvdXMgY2FuZGlkYXRlIGZvciB0aGlzLg0KDQpIb3dldmVy LCBhY2Nlc3NpbmcgdGhlIGRhdGFiYXNlIGl0c2VsZiBpcyBub3QgZW5vdWdoLiBUaGUgZW5kIGRl dmljZSB3b3VsZCBoYXZlIHRvIHJlcGxpY2F0ZSBhbGwgcm91dGluZyBkZWNpc2lvbnMgdGhlIHRl bGNvcyBtYWtlLiBBbGwgZGlzY3Vzc2lvbnMgYWJvdXQgUEJYcyBhbmQgbnVtYmVyIHBvcnRhYmls aXR5IGFyZSBlc3NlbnRpYWxseSBhYm91dCB0aGUgcm91dGluZyBpbnNpZGUgdGhlIHRlbGNvcy4N Cg0KV2h5IG5vdCBqdXN0IHVzZSB0aGUgZXhpc3RpbmcgcGxhdGZvcm0gdG8gdmVyaWZ5IGNhbGxp bmcgbnVtYmVycz8NCg0KDQpXb2xmZ2FuZyBCZWNrDQo= --_000_596979554D802045BBD45C051A4399E40D40C829STNTEXMB10cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVu dD0iSFRNTCBUaWR5IGZvciBXaW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3Lncz Lm9yZyI+DQo8dGl0bGU+PC90aXRsZT4NCjwvaGVhZD4NCjxib2R5Pg0KVGhvc2UgdmVyaWZpY2F0 aW9uIHN5c3RlbXMgbGlrZSBWSVBSIGFuZCBXaGF0c2FwcCBhcmUgcmVsaWFibGUgb25seSBpbiBz byBmYXIgYXMgdGhlaXIgY2FsbCBzaWduYWxpbmcgZ29lcyBleGNsdXNpdmVseSB0aHJvdWdoIHRo ZSBQU1ROIC0gdGhlIERZUFRDIG1ldGhvZCB3b3VsZG4ndCBnbyBvdmVyIFNTNyB1bmZvcnR1bmF0 ZWx5Ljxicj4NCjxicj4NCkpvbiBQZXRlcnNvbjxicj4NCk5ldXN0YXIsIEluYy48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQpTZW50IHdpdGggR29vZCAod3d3Lmdvb2QuY29tKTxicj4NCjxicj4NCjxi cj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KPGI+RnJvbTombmJzcDs8L2I+V29s ZmdhbmcgQmVjayBbPGEgaHJlZj0ibWFpbHRvOndvbGZnYW5nLmJlY2swMUBnb29nbGVtYWlsLmNv bSI+d29sZmdhbmcuYmVjazAxQGdvb2dsZW1haWwuY29tPC9hPl08YnI+DQo8Yj5TZW50OiZuYnNw OzwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMDcsIDIwMTMgMDc6MTIgUE0gRWFzdGVybiBTdGFuZGFy ZCBUaW1lPGJyPg0KPGI+VG86Jm5ic3A7PC9iPlBldGVyc29uLCBKb248YnI+DQo8Yj5DYzombmJz cDs8L2I+c3RpckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6Jm5ic3A7PC9iPlJFOiBbc3Rpcl0g bmV3IFNJUCBNZXRob2QgRFlQVEMgJ0RpZCBZb3UgUGxhY2UgVGhpcyBDYWxsPyc8YnI+DQo8YnI+ DQo8cCBkaXI9Imx0ciI+VklQUiwgd2hhdHNhcHAsIGlNZXNzYWdlIGFsbCB1c2UgdGhlIHBob25l IG5ldHdvcmsgZm9yIHZlcmlmaWNhdGlvbi4gUHVibGljIEVOVU0gcmVnaXN0cmFycyB1c2VkIGl0 LiBUaGUgcHJpbmNpcGxlIHNlZW1zIHRvIGJlIHdvcmtpbmcgZm9yIHN1ZmZpY2llbnRseSBsYXJn ZSBudW1iZXIgb2YgY2FzZXMuPC9wPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkFtIDA3LjEx LjIwMTMgMTQ6Mzggc2NocmllYiAmcXVvdDtQZXRlcnNvbiwgSm9uJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86am9uLnBldGVyc29uQG5ldXN0YXIuYml6Ij5qb24ucGV0ZXJzb25AbmV1c3Rhci5i aXo8L2E+Jmd0Ozo8YnIgdHlwZT0iYXR0cmlidXRpb24iPg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pjxicj4NCkkgYmVsaWV2ZSB0aGF0IFNJUCBt ZXNzYWdlcyByb3V0ZWQgdG8gdGVsZXBob25lIG51bWJlcnMgdG9kYXkgYXJlIG1vc3RseSBmcmVx dWVudGx5IGRyb3BwZWQgdG8gdGhlIFBTVE4sIGFuZCBtYXkgZXZlbnR1YWxseSByZS1lbnRlciB0 aGUgSW50ZXJuZXQgb3Igbm90LiBJbiBjYXNlcyB3aGVyZSByZXF1ZXN0cyB0YXJnZXRpbmcgdGVs ZXBob25lIG51bWJlcnMgZG8gdHJhdmVsIGVuZC10by1lbmQgb3ZlciB0aGUgSW50ZXJuZXQsIHZh cmlvdXMgZmxhdA0KIGZpbGVzIGFuZCBwcml2YXRlIGRhdGFiYXNlcyBhcmUgY29uc3VsdGVkIHRv IGZvcndhcmQgcmVxdWVzdHMgaG9wLWJ5LWhvcCB1bnRpbCB0aGV5IHJlYWNoIGEgZGVzdGluYXRp b24uIFRoZSByZWxhdGlvbnNoaXBzIG9mIHRob3NlIG1lY2hhbmlzbXMgdG8gbnVtYmVyaW5nIGF1 dGhvcml0aWVzIGNhbiBiZSB0ZW51b3VzIHRvZGF5LCBwcmVjaXNlbHkgYmVjYXVzZSBvZiB0aGUg YWJzZW5jZSBvZiB0aGUgYXV0aG9yaXR5IGFyY2hpdGVjdHVyZSB0aGlzDQogd29ya2luZyBncm91 cCBpcyBjb25zaWRlcmluZy48YnI+DQo8YnI+DQpUaGVyZSdzIG5vIGZyZWUgbHVuY2ggaGVyZS48 YnI+DQo8YnI+DQpKb24gUGV0ZXJzb248YnI+DQpOZXVzdGFyLCBJbmMuPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KU2VudCB3aXRoIEdvb2QgKDxhIGhyZWY9Imh0dHA6Ly93d3cuZ29vZC5jb20iIHRh cmdldD0iX2JsYW5rIj53d3cuZ29vZC5jb208L2E+KTxicj4NCjxicj4NCjxicj4NCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KPGI+RnJvbTombmJzcDs8L2I+V29sZmdhbmcgQmVjayBb PGEgaHJlZj0ibWFpbHRvOndvbGZnYW5nLmJlY2swMUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPndvbGZnYW5nLmJlY2swMUBnb29nbGVtYWlsLmNvbTwvYT5dPGJyPg0KPGI+U2VudDom bmJzcDs8L2I+VGh1cnNkYXksIE5vdmVtYmVyIDA3LCAyMDEzIDA1OjIzIFBNIEVhc3Rlcm4gU3Rh bmRhcmQgVGltZTxicj4NCjxiPlRvOiZuYnNwOzwvYj5QZXRlcnNvbiwgSm9uPGJyPg0KPGI+Q2M6 Jm5ic3A7PC9iPjxhIGhyZWY9Im1haWx0bzpzdGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ c3RpckBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OiZuYnNwOzwvYj5SRTogW3N0aXJdIG5l dyBTSVAgTWV0aG9kIERZUFRDICdEaWQgWW91IFBsYWNlIFRoaXMgQ2FsbD8nPGJyPg0KPGJyPg0K PHAgZGlyPSJsdHIiPldvdWxkIHlvdSBhZ3JlZSB0aGF0IHN1Y2ggYSBTSVAgbWVzc2FnZSB3b3Vs ZCBhcnJpdmUgYXQgYW4gZWxlbWVudCBvZiBhIHBhcnR5IHRoYXQgaGFzIGRlbGVnYXRlZCB0aGUg bnVtYmVyIHRvIGl0cyBjdXJyZW50IHVzZXI/IFNvbHZpbmcgdGhlIHByb2JsZW0gJ3dobyBvd25z IHRoaXMgbnVtYmVyPycgc2VlbXMgZWFzaWVyIHRvIG1lIGluc2lkZSB0aGUgc3lzdGVtIHRoYW4g aW4gYSBzZXBhcmF0ZSBvbmUuPC9wPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkFtIDA3LjEx LjIwMTMgMTM6MjYgc2NocmllYiAmcXVvdDtQZXRlcnNvbiwgSm9uJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86am9uLnBldGVyc29uQG5ldXN0YXIuYml6IiB0YXJnZXQ9Il9ibGFuayI+am9uLnBl dGVyc29uQG5ldXN0YXIuYml6PC9hPiZndDs6PGJyIHR5cGU9ImF0dHJpYnV0aW9uIj4NCjxibG9j a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRl ci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdj5WYXJpb3VzICZx dW90O2NhbGxiYWNrJnF1b3Q7IG1lY2hhbmlzbXMgYWxvbmcgdGhlc2UgbGluZXMgaGF2ZSBiZWVu IGNvbnNpZGVyZWQsIGFuZCB0aGVyZSBhcmUga25vd24gbGltaXRhdGlvbnMgb2YgdGhlc2UgbWVj aGFuaXNtcywgbW9zdCBvZiB3aGljaCByZXN1bHQgZnJvbSB0aGUgZmFjdCB0aGF0IHBsYWNpbmcg YSBjYWxsIGZyb20gYSBudW1iZXIgZG9lcyBub3QgZ3VhcmFudGVlIHRoYXQgYSByZXR1cm5lZCBj YWxsIHdvdWxkIHJlYWNoIHRoZSBzYW1lDQogZW5kcG9pbnQgaW5zdGFuY2UuIEdhdGV3YXlzLCBj YWxsIGNlbnRlcnMsIHVzZXJzIHdpdGggbXVsdGlwbGUgY29uY3VycmVudGx5IHJlZ2lzdGVyZWQg ZGV2aWNlcywgYWxsIG9mIG91ciAmcXVvdDtkb2N0b3IncyBvZmZpY2UmcXVvdDsgdXNlIGNhc2Vz IGFuZCByZWxhdGVkIGNvbmZpZ3VyYXRpb25zIHNob3cgd2h5IGFwcHJvYWNoZXMgYWxvbmcgdGhl c2UgbGluZXMgYXJlIGluc3VmZmljaWVudC48YnI+DQo8YnI+DQpKb24gUGV0ZXJzb248YnI+DQpO ZXVzdGFyLCBpbmMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KU2VudCB3aXRoIEdvb2QgKDxhIGhy ZWY9Imh0dHA6Ly93d3cuZ29vZC5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cuZ29vZC5jb208L2E+ KTxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KPGI+RnJv bTombmJzcDs8L2I+V29sZmdhbmcgQmVjayBbPGEgaHJlZj0ibWFpbHRvOndvbGZnYW5nLmJlY2sw MUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndvbGZnYW5nLmJlY2swMUBnb29nbGVt YWlsLmNvbTwvYT5dPGJyPg0KPGI+U2VudDombmJzcDs8L2I+VGh1cnNkYXksIE5vdmVtYmVyIDA3 LCAyMDEzIDA0OjE4IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZTxicj4NCjxiPlRvOiZuYnNwOzwv Yj48YSBocmVmPSJtYWlsdG86c3RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnN0aXJAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDombmJzcDs8L2I+W3N0aXJdIG5ldyBTSVAgTWV0aG9k IERZUFRDICdEaWQgWW91IFBsYWNlIFRoaXMgQ2FsbD8nPGJyPg0KPGJyPg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5IZXJlJ3MgYSBoYWxmLWJha2Vk IGlkZWE6IHdoZW4gYSBjYWxsIGMxIGFyaXZlcyBmcm9tICZsdDthJmd0OywgSSBzZW5kIGEgRFlQ VEMgU0lQIHJlcXVlc3QgbWVzc2FnZSBvdXRzaWRlIG9mIHRoaXMgY2FsbCBiYWNrIHRvICZsdDth Jmd0Oy4gVGhlIERZUFRDIHJlcXVlc3QgY2FycmllcyBzb21lIGhlYWRlcnMgdGhhdCBkZXNjcmli ZSBjMSwgZWcuIHRoZSBvcmlnaW5hbCBmcm9tIGFuZCB0by48YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KLSBpZiB0aGUgcmVjZWl2aW5nIFVBIGlzIGluZGVlZCAmbHQ7YSZndDssIGl0IHJlc3BvbmRz IHdpdGggMjAwIE9LLiBUaGUgb3JpZ2luIG9mIGNhbGwgYzEgaXMgbm93IHZlcmlmaWVkLjxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQotIGlmICZsdDthJmd0OyB3YXMgc3Bvb2ZlZCBieSBzb21lYm9k eSwgdGhlIHJlcXVlc3Qgd2lsbCBhcnJpdmUgYXQgYSBVQSB0aGF0IGRvZXMgbm90IGtub3cgYWJv dXQgdGhlIGNhbGwgZGVzY3JpYmVkIGJ5IERZUFRDLiBJdCByZXNwb25kcyB3aXRoIDQwNCBOb3Qg Rm91bmQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KLSBpZiAmbHQ7YSZndDsgd2FzIHNwb29mZWQg YW5kIHRoZXJlIGlzIG5vIFVBIHJlYWNoYWJsZSwgdGhlIHJlcXVlc3Qgd2lsbCB0aW1lIG91dCBv ciB0aGUgbmV0d29yayB3aWxsIGdlbmVyYXRlIGEgNDA0IE5vdCBmb3VuZC48YnI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXY+V2hlbmV2ZXIgSSBkb250IHJlY2VpdmUgYSAyMDAgT0sgb24gYSBEWVBUQywg dGhlIGNhbGxpbmcgbnVtYmVyIGNvdWxkIG5vdCBiZSB2ZXJpZmllZC48YnI+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNvIGZhciBhbGwgbWV0aG9kcyB0byBkZXRlcm1pbmUgYSBw YXJ0eSB0aGF0IGNhbiB2ZXJpZnkgYSBudW1iZXIgc2VlbSB0byBib2lsIGRvd24gdG8gb25lIG9m IHRoZSB0d28gZ3JvdXBzOjxicj4NCjxicj4NCjwvZGl2Pg0KMS4gY3JlYXRlIGEgbmV3IGRhdGFi YXNlLCByZXBsaWNhdGVkIGZyb20gdGhlIHRlbGNvcycgZGF0YWJhc2VzLCB0aGF0IGNhbiBiZSBh Y2Nlc3NlZCBieSBlbmQgZGV2aWNlcy4gVGhhdCdzIHdoYXQgaU1lc3NhZ2UsIHdoYXRzYXBwLCBh bmQgVklQUiB0cnkgdG8gZG8uIEFjY3VyYXRlbHkgcmVwbGljYXRpbmcgYSBmYWlybHkgZHluYW1p YyBkYXRhYmFzZSB3aXRob3V0IGl0cyBjb29wZXJhdGlvbiBpcyBhIGNoYWxsZW5nZS48YnI+DQo8 YnI+DQo8L2Rpdj4NCjIuIGNyZWF0ZSBhIHdheSBzbyB0aGF0IGVuZCBkZXZpY2VzIGNhbiBkaXJl Y3RseSBxdWVyeSB0aGUgdGVsY29zJyBkYXRhYmFzZXMuIEROUyBpcyBhbiBvYnZpb3VzIGNhbmRp ZGF0ZSBmb3IgdGhpcy48YnI+DQo8YnI+DQo8L2Rpdj4NCkhvd2V2ZXIsIGFjY2Vzc2luZyB0aGUg ZGF0YWJhc2UgaXRzZWxmIGlzIG5vdCBlbm91Z2guIFRoZSBlbmQgZGV2aWNlIHdvdWxkIGhhdmUg dG8gcmVwbGljYXRlIGFsbCByb3V0aW5nIGRlY2lzaW9ucyB0aGUgdGVsY29zIG1ha2UuIEFsbCBk aXNjdXNzaW9ucyBhYm91dCBQQlhzIGFuZCBudW1iZXIgcG9ydGFiaWxpdHkgYXJlIGVzc2VudGlh bGx5IGFib3V0IHRoZSByb3V0aW5nIGluc2lkZSB0aGUgdGVsY29zLjxicj4NCjxicj4NCjwvZGl2 Pg0KV2h5IG5vdCBqdXN0IHVzZSB0aGUgZXhpc3RpbmcgcGxhdGZvcm0gdG8gdmVyaWZ5IGNhbGxp bmcgbnVtYmVycz88YnI+DQo8YnI+DQo8L2Rpdj4NCjxicj4NCldvbGZnYW5nIEJlY2s8YnI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_596979554D802045BBD45C051A4399E40D40C829STNTEXMB10cisne_-- From sanjay.mishra@verizon.com Thu Nov 7 16:36:53 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CE321E8156 for ; Thu, 7 Nov 2013 16:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5toXA0bdTDQ for ; Thu, 7 Nov 2013 16:36:38 -0800 (PST) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id DD63811E812A for ; Thu, 7 Nov 2013 16:36:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe03.verizonbusiness.com with ESMTP; 08 Nov 2013 00:36:31 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="4.93,655,1378857600"; d="scan'208,217";a="587888175" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 08 Nov 2013 00:36:31 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([169.254.3.98]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Thu, 7 Nov 2013 19:36:30 -0500 To: "Peterson, Jon" , 'Wolfgang Beck' Date: Thu, 7 Nov 2013 19:36:28 -0500 Thread-Topic: [stir] new SIP Method DYPTC 'Did You Place This Call?' Thread-Index: AQHO2/759gVKPWtkUE25HikC9AzlgJoaSAi0gABjqYD//7BZ0oAAbhuA//+voQ+AAAHz8A== Message-ID: <900A1E2059ADB149B905E3C8FA0046A62C80400CB6@FHDP1LUMXC7V23.us.one.verizon.com> References: <596979554D802045BBD45C051A4399E40D40C829@STNTEXMB10.cis.neustar.com> In-Reply-To: <596979554D802045BBD45C051A4399E40D40C829@STNTEXMB10.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_900A1E2059ADB149B905E3C8FA0046A62C80400CB6FHDP1LUMXC7V2_" MIME-Version: 1.0 Cc: "'stir@ietf.org'" Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:36:53 -0000 --_000_900A1E2059ADB149B905E3C8FA0046A62C80400CB6FHDP1LUMXC7V2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V29sZmdhbmcsIEpvbiDigJMgSXMgdGhlIHJlZmVyZW5jZSBiZWxvdyBpcyBmb3IgIOKAnFZJUFLi gJ0gaXMgYXMgaW4gdGhlIHZvaWNlIHNlcnZpY2Ugb2ZmZXJlZCBieSDigJxWSUJFUuKAnSBvciBp cyB0aGUgcmVmZXJlbmNlIGhlcmUgaXMgdG8g4oCcVmVyaWZpY2F0aW9uIEludm9sdmluZyBQU1RO IFJlYWNoYWJpbGl0eSAoVklQUik/DQoNCkl0IHNvdW5kcyB0byBtZSBXb2ZmZ2FuZyBpcyByZWZl cmVuY2luZyBWSUJFUiBidXQgSSBjYW4gYmUgd3JvbmcuDQoNClNhbmpheQ0KDQpGcm9tOiBzdGly LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBQZXRlcnNvbiwgSm9uDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDcsIDIwMTMgNDoy NCBQTQ0KVG86ICdXb2xmZ2FuZyBCZWNrJw0KQ2M6ICdzdGlyQGlldGYub3JnJw0KU3ViamVjdDog UmU6IFtzdGlyXSBuZXcgU0lQIE1ldGhvZCBEWVBUQyAnRGlkIFlvdSBQbGFjZSBUaGlzIENhbGw/ Jw0KDQpUaG9zZSB2ZXJpZmljYXRpb24gc3lzdGVtcyBsaWtlIFZJUFIgYW5kIFdoYXRzYXBwIGFy ZSByZWxpYWJsZSBvbmx5IGluIHNvIGZhciBhcyB0aGVpciBjYWxsIHNpZ25hbGluZyBnb2VzIGV4 Y2x1c2l2ZWx5IHRocm91Z2ggdGhlIFBTVE4gLSB0aGUgRFlQVEMgbWV0aG9kIHdvdWxkbid0IGdv IG92ZXIgU1M3IHVuZm9ydHVuYXRlbHkuDQoNCkpvbiBQZXRlcnNvbg0KTmV1c3RhciwgSW5jLg0K DQoNCg0KU2VudCB3aXRoIEdvb2QgKHd3dy5nb29kLmNvbTxodHRwOi8vd3d3Lmdvb2QuY29tPikN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV29sZmdhbmcgQmVjayBbd29s ZmdhbmcuYmVjazAxQGdvb2dsZW1haWwuY29tPG1haWx0bzp3b2xmZ2FuZy5iZWNrMDFAZ29vZ2xl bWFpbC5jb20+XQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDA3LCAyMDEzIDA3OjEyIFBNIEVh c3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IFBldGVyc29uLCBKb24NCkNjOiBzdGlyQGlldGYub3Jn PG1haWx0bzpzdGlyQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtzdGlyXSBuZXcgU0lQIE1ldGhv ZCBEWVBUQyAnRGlkIFlvdSBQbGFjZSBUaGlzIENhbGw/Jw0KDQpWSVBSLCB3aGF0c2FwcCwgaU1l c3NhZ2UgYWxsIHVzZSB0aGUgcGhvbmUgbmV0d29yayBmb3IgdmVyaWZpY2F0aW9uLiBQdWJsaWMg RU5VTSByZWdpc3RyYXJzIHVzZWQgaXQuIFRoZSBwcmluY2lwbGUgc2VlbXMgdG8gYmUgd29ya2lu ZyBmb3Igc3VmZmljaWVudGx5IGxhcmdlIG51bWJlciBvZiBjYXNlcy4NCkFtIDA3LjExLjIwMTMg MTQ6Mzggc2NocmllYiAiUGV0ZXJzb24sIEpvbiIgPGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpejxt YWlsdG86am9uLnBldGVyc29uQG5ldXN0YXIuYml6Pj46DQoNCkkgYmVsaWV2ZSB0aGF0IFNJUCBt ZXNzYWdlcyByb3V0ZWQgdG8gdGVsZXBob25lIG51bWJlcnMgdG9kYXkgYXJlIG1vc3RseSBmcmVx dWVudGx5IGRyb3BwZWQgdG8gdGhlIFBTVE4sIGFuZCBtYXkgZXZlbnR1YWxseSByZS1lbnRlciB0 aGUgSW50ZXJuZXQgb3Igbm90LiBJbiBjYXNlcyB3aGVyZSByZXF1ZXN0cyB0YXJnZXRpbmcgdGVs ZXBob25lIG51bWJlcnMgZG8gdHJhdmVsIGVuZC10by1lbmQgb3ZlciB0aGUgSW50ZXJuZXQsIHZh cmlvdXMgZmxhdCBmaWxlcyBhbmQgcHJpdmF0ZSBkYXRhYmFzZXMgYXJlIGNvbnN1bHRlZCB0byBm b3J3YXJkIHJlcXVlc3RzIGhvcC1ieS1ob3AgdW50aWwgdGhleSByZWFjaCBhIGRlc3RpbmF0aW9u LiBUaGUgcmVsYXRpb25zaGlwcyBvZiB0aG9zZSBtZWNoYW5pc21zIHRvIG51bWJlcmluZyBhdXRo b3JpdGllcyBjYW4gYmUgdGVudW91cyB0b2RheSwgcHJlY2lzZWx5IGJlY2F1c2Ugb2YgdGhlIGFi c2VuY2Ugb2YgdGhlIGF1dGhvcml0eSBhcmNoaXRlY3R1cmUgdGhpcyB3b3JraW5nIGdyb3VwIGlz IGNvbnNpZGVyaW5nLg0KDQpUaGVyZSdzIG5vIGZyZWUgbHVuY2ggaGVyZS4NCg0KSm9uIFBldGVy c29uDQpOZXVzdGFyLCBJbmMuDQoNCg0KDQpTZW50IHdpdGggR29vZCAod3d3Lmdvb2QuY29tPGh0 dHA6Ly93d3cuZ29vZC5jb20+KQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBXb2xmZ2FuZyBCZWNrIFt3b2xmZ2FuZy5iZWNrMDFAZ29vZ2xlbWFpbC5jb208bWFpbHRvOndv bGZnYW5nLmJlY2swMUBnb29nbGVtYWlsLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIg MDcsIDIwMTMgMDU6MjMgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzogUGV0ZXJzb24sIEpv bg0KQ2M6IHN0aXJAaWV0Zi5vcmc8bWFpbHRvOnN0aXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTog W3N0aXJdIG5ldyBTSVAgTWV0aG9kIERZUFRDICdEaWQgWW91IFBsYWNlIFRoaXMgQ2FsbD8nDQoN CldvdWxkIHlvdSBhZ3JlZSB0aGF0IHN1Y2ggYSBTSVAgbWVzc2FnZSB3b3VsZCBhcnJpdmUgYXQg YW4gZWxlbWVudCBvZiBhIHBhcnR5IHRoYXQgaGFzIGRlbGVnYXRlZCB0aGUgbnVtYmVyIHRvIGl0 cyBjdXJyZW50IHVzZXI/IFNvbHZpbmcgdGhlIHByb2JsZW0gJ3dobyBvd25zIHRoaXMgbnVtYmVy Pycgc2VlbXMgZWFzaWVyIHRvIG1lIGluc2lkZSB0aGUgc3lzdGVtIHRoYW4gaW4gYSBzZXBhcmF0 ZSBvbmUuDQpBbSAwNy4xMS4yMDEzIDEzOjI2IHNjaHJpZWIgIlBldGVyc29uLCBKb24iIDxqb24u cGV0ZXJzb25AbmV1c3Rhci5iaXo8bWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpej4+Og0K VmFyaW91cyAiY2FsbGJhY2siIG1lY2hhbmlzbXMgYWxvbmcgdGhlc2UgbGluZXMgaGF2ZSBiZWVu IGNvbnNpZGVyZWQsIGFuZCB0aGVyZSBhcmUga25vd24gbGltaXRhdGlvbnMgb2YgdGhlc2UgbWVj aGFuaXNtcywgbW9zdCBvZiB3aGljaCByZXN1bHQgZnJvbSB0aGUgZmFjdCB0aGF0IHBsYWNpbmcg YSBjYWxsIGZyb20gYSBudW1iZXIgZG9lcyBub3QgZ3VhcmFudGVlIHRoYXQgYSByZXR1cm5lZCBj YWxsIHdvdWxkIHJlYWNoIHRoZSBzYW1lIGVuZHBvaW50IGluc3RhbmNlLiBHYXRld2F5cywgY2Fs bCBjZW50ZXJzLCB1c2VycyB3aXRoIG11bHRpcGxlIGNvbmN1cnJlbnRseSByZWdpc3RlcmVkIGRl dmljZXMsIGFsbCBvZiBvdXIgImRvY3RvcidzIG9mZmljZSIgdXNlIGNhc2VzIGFuZCByZWxhdGVk IGNvbmZpZ3VyYXRpb25zIHNob3cgd2h5IGFwcHJvYWNoZXMgYWxvbmcgdGhlc2UgbGluZXMgYXJl IGluc3VmZmljaWVudC4NCg0KSm9uIFBldGVyc29uDQpOZXVzdGFyLCBpbmMuDQoNCg0KDQpTZW50 IHdpdGggR29vZCAod3d3Lmdvb2QuY29tPGh0dHA6Ly93d3cuZ29vZC5jb20+KQ0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXb2xmZ2FuZyBCZWNrIFt3b2xmZ2FuZy5iZWNr MDFAZ29vZ2xlbWFpbC5jb208bWFpbHRvOndvbGZnYW5nLmJlY2swMUBnb29nbGVtYWlsLmNvbT5d DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDcsIDIwMTMgMDQ6MTggUE0gRWFzdGVybiBTdGFu ZGFyZCBUaW1lDQpUbzogc3RpckBpZXRmLm9yZzxtYWlsdG86c3RpckBpZXRmLm9yZz4NClN1Ympl Y3Q6IFtzdGlyXSBuZXcgU0lQIE1ldGhvZCBEWVBUQyAnRGlkIFlvdSBQbGFjZSBUaGlzIENhbGw/ Jw0KSGVyZSdzIGEgaGFsZi1iYWtlZCBpZGVhOiB3aGVuIGEgY2FsbCBjMSBhcml2ZXMgZnJvbSA8 YT4sIEkgc2VuZCBhIERZUFRDIFNJUCByZXF1ZXN0IG1lc3NhZ2Ugb3V0c2lkZSBvZiB0aGlzIGNh bGwgYmFjayB0byA8YT4uIFRoZSBEWVBUQyByZXF1ZXN0IGNhcnJpZXMgc29tZSBoZWFkZXJzIHRo YXQgZGVzY3JpYmUgYzEsIGVnLiB0aGUgb3JpZ2luYWwgZnJvbSBhbmQgdG8uDQoNCi0gaWYgdGhl IHJlY2VpdmluZyBVQSBpcyBpbmRlZWQgPGE+LCBpdCByZXNwb25kcyB3aXRoIDIwMCBPSy4gVGhl IG9yaWdpbiBvZiBjYWxsIGMxIGlzIG5vdyB2ZXJpZmllZC4NCg0KLSBpZiA8YT4gd2FzIHNwb29m ZWQgYnkgc29tZWJvZHksIHRoZSByZXF1ZXN0IHdpbGwgYXJyaXZlIGF0IGEgVUEgdGhhdCBkb2Vz IG5vdCBrbm93IGFib3V0IHRoZSBjYWxsIGRlc2NyaWJlZCBieSBEWVBUQy4gSXQgcmVzcG9uZHMg d2l0aCA0MDQgTm90IEZvdW5kDQoNCi0gaWYgPGE+IHdhcyBzcG9vZmVkIGFuZCB0aGVyZSBpcyBu byBVQSByZWFjaGFibGUsIHRoZSByZXF1ZXN0IHdpbGwgdGltZSBvdXQgb3IgdGhlIG5ldHdvcmsg d2lsbCBnZW5lcmF0ZSBhIDQwNCBOb3QgZm91bmQuDQpXaGVuZXZlciBJIGRvbnQgcmVjZWl2ZSBh IDIwMCBPSyBvbiBhIERZUFRDLCB0aGUgY2FsbGluZyBudW1iZXIgY291bGQgbm90IGJlIHZlcmlm aWVkLg0KDQpTbyBmYXIgYWxsIG1ldGhvZHMgdG8gZGV0ZXJtaW5lIGEgcGFydHkgdGhhdCBjYW4g dmVyaWZ5IGEgbnVtYmVyIHNlZW0gdG8gYm9pbCBkb3duIHRvIG9uZSBvZiB0aGUgdHdvIGdyb3Vw czoNCjEuIGNyZWF0ZSBhIG5ldyBkYXRhYmFzZSwgcmVwbGljYXRlZCBmcm9tIHRoZSB0ZWxjb3Mn IGRhdGFiYXNlcywgdGhhdCBjYW4gYmUgYWNjZXNzZWQgYnkgZW5kIGRldmljZXMuIFRoYXQncyB3 aGF0IGlNZXNzYWdlLCB3aGF0c2FwcCwgYW5kIFZJUFIgdHJ5IHRvIGRvLiBBY2N1cmF0ZWx5IHJl cGxpY2F0aW5nIGEgZmFpcmx5IGR5bmFtaWMgZGF0YWJhc2Ugd2l0aG91dCBpdHMgY29vcGVyYXRp b24gaXMgYSBjaGFsbGVuZ2UuDQoyLiBjcmVhdGUgYSB3YXkgc28gdGhhdCBlbmQgZGV2aWNlcyBj YW4gZGlyZWN0bHkgcXVlcnkgdGhlIHRlbGNvcycgZGF0YWJhc2VzLiBETlMgaXMgYW4gb2J2aW91 cyBjYW5kaWRhdGUgZm9yIHRoaXMuDQpIb3dldmVyLCBhY2Nlc3NpbmcgdGhlIGRhdGFiYXNlIGl0 c2VsZiBpcyBub3QgZW5vdWdoLiBUaGUgZW5kIGRldmljZSB3b3VsZCBoYXZlIHRvIHJlcGxpY2F0 ZSBhbGwgcm91dGluZyBkZWNpc2lvbnMgdGhlIHRlbGNvcyBtYWtlLiBBbGwgZGlzY3Vzc2lvbnMg YWJvdXQgUEJYcyBhbmQgbnVtYmVyIHBvcnRhYmlsaXR5IGFyZSBlc3NlbnRpYWxseSBhYm91dCB0 aGUgcm91dGluZyBpbnNpZGUgdGhlIHRlbGNvcy4NCldoeSBub3QganVzdCB1c2UgdGhlIGV4aXN0 aW5nIHBsYXRmb3JtIHRvIHZlcmlmeSBjYWxsaW5nIG51bWJlcnM/DQoNCldvbGZnYW5nIEJlY2sN Cg== --_000_900A1E2059ADB149B905E3C8FA0046A62C80400CB6FHDP1LUMXC7V2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGlu az1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Xb2xmZ2FuZywgSm9uIOKAkyBJcyB0aGUgcmVm ZXJlbmNlIGJlbG93IGlzIGZvciDCoOKAnFZJUFLigJ0gaXMgYXMgaW4gdGhlIHZvaWNlIHNlcnZp Y2Ugb2ZmZXJlZCBieSDigJxWSUJFUuKAnSBvciBpcyB0aGUgcmVmZXJlbmNlIGhlcmUgaXMgdG8g 4oCcVmVyaWZpY2F0aW9uIEludm9sdmluZyBQU1ROIFJlYWNoYWJpbGl0eSAoVklQUik/PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5JdCBzb3VuZHMgdG8gbWUgV29mZmdhbmcgaXMgcmVmZXJlbmNpbmcgVklC RVIgYnV0IEkgY2FuIGJlIHdyb25nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+IFNhbmpheTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+ PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHN0 aXItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZ10gPGI+T24g QmVoYWxmIE9mIDwvYj5QZXRlcnNvbiwgSm9uPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92 ZW1iZXIgMDcsIDIwMTMgNDoyNCBQTTxicj48Yj5Ubzo8L2I+ICdXb2xmZ2FuZyBCZWNrJzxicj48 Yj5DYzo8L2I+ICdzdGlyQGlldGYub3JnJzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzdGlyXSBu ZXcgU0lQIE1ldGhvZCBEWVBUQyAnRGlkIFlvdSBQbGFjZSBUaGlzIENhbGw/JzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+VGhv c2UgdmVyaWZpY2F0aW9uIHN5c3RlbXMgbGlrZSBWSVBSIGFuZCBXaGF0c2FwcCBhcmUgcmVsaWFi bGUgb25seSBpbiBzbyBmYXIgYXMgdGhlaXIgY2FsbCBzaWduYWxpbmcgZ29lcyBleGNsdXNpdmVs eSB0aHJvdWdoIHRoZSBQU1ROIC0gdGhlIERZUFRDIG1ldGhvZCB3b3VsZG4ndCBnbyBvdmVyIFNT NyB1bmZvcnR1bmF0ZWx5Ljxicj48YnI+Sm9uIFBldGVyc29uPGJyPk5ldXN0YXIsIEluYy48YnI+ PGJyPjxicj48YnI+U2VudCB3aXRoIEdvb2QgKDxhIGhyZWY9Imh0dHA6Ly93d3cuZ29vZC5jb20i Pnd3dy5nb29kLmNvbTwvYT4pPGJyPjxicj48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+PGI+RnJvbTombmJzcDs8L2I+V29sZmdhbmcgQmVjayBbPGEgaHJlZj0ibWFpbHRvOndvbGZn YW5nLmJlY2swMUBnb29nbGVtYWlsLmNvbSI+d29sZmdhbmcuYmVjazAxQGdvb2dsZW1haWwuY29t PC9hPl08YnI+PGI+U2VudDombmJzcDs8L2I+VGh1cnNkYXksIE5vdmVtYmVyIDA3LCAyMDEzIDA3 OjEyIFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZTxicj48Yj5UbzombmJzcDs8L2I+UGV0ZXJzb24s IEpvbjxicj48Yj5DYzombmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRvOnN0aXJAaWV0Zi5vcmciPnN0 aXJAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6Jm5ic3A7PC9iPlJFOiBbc3Rpcl0gbmV3IFNJ UCBNZXRob2QgRFlQVEMgJ0RpZCBZb3UgUGxhY2UgVGhpcyBDYWxsPyc8bzpwPjwvbzpwPjwvcD48 cD5WSVBSLCB3aGF0c2FwcCwgaU1lc3NhZ2UgYWxsIHVzZSB0aGUgcGhvbmUgbmV0d29yayBmb3Ig dmVyaWZpY2F0aW9uLiBQdWJsaWMgRU5VTSByZWdpc3RyYXJzIHVzZWQgaXQuIFRoZSBwcmluY2lw bGUgc2VlbXMgdG8gYmUgd29ya2luZyBmb3Igc3VmZmljaWVudGx5IGxhcmdlIG51bWJlciBvZiBj YXNlcy48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BbSAwNy4xMS4yMDEz IDE0OjM4IHNjaHJpZWIgJnF1b3Q7UGV0ZXJzb24sIEpvbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpeiI+am9uLnBldGVyc29uQG5ldXN0YXIuYml6PC9h PiZndDs6PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1ib3R0b206MTIuMHB0Jz48YnI+SSBiZWxpZXZlIHRoYXQgU0lQIG1lc3NhZ2VzIHJvdXRlZCB0 byB0ZWxlcGhvbmUgbnVtYmVycyB0b2RheSBhcmUgbW9zdGx5IGZyZXF1ZW50bHkgZHJvcHBlZCB0 byB0aGUgUFNUTiwgYW5kIG1heSBldmVudHVhbGx5IHJlLWVudGVyIHRoZSBJbnRlcm5ldCBvciBu b3QuIEluIGNhc2VzIHdoZXJlIHJlcXVlc3RzIHRhcmdldGluZyB0ZWxlcGhvbmUgbnVtYmVycyBk byB0cmF2ZWwgZW5kLXRvLWVuZCBvdmVyIHRoZSBJbnRlcm5ldCwgdmFyaW91cyBmbGF0IGZpbGVz IGFuZCBwcml2YXRlIGRhdGFiYXNlcyBhcmUgY29uc3VsdGVkIHRvIGZvcndhcmQgcmVxdWVzdHMg aG9wLWJ5LWhvcCB1bnRpbCB0aGV5IHJlYWNoIGEgZGVzdGluYXRpb24uIFRoZSByZWxhdGlvbnNo aXBzIG9mIHRob3NlIG1lY2hhbmlzbXMgdG8gbnVtYmVyaW5nIGF1dGhvcml0aWVzIGNhbiBiZSB0 ZW51b3VzIHRvZGF5LCBwcmVjaXNlbHkgYmVjYXVzZSBvZiB0aGUgYWJzZW5jZSBvZiB0aGUgYXV0 aG9yaXR5IGFyY2hpdGVjdHVyZSB0aGlzIHdvcmtpbmcgZ3JvdXAgaXMgY29uc2lkZXJpbmcuPGJy Pjxicj5UaGVyZSdzIG5vIGZyZWUgbHVuY2ggaGVyZS48YnI+PGJyPkpvbiBQZXRlcnNvbjxicj5O ZXVzdGFyLCBJbmMuPGJyPjxicj48YnI+PGJyPlNlbnQgd2l0aCBHb29kICg8YSBocmVmPSJodHRw Oi8vd3d3Lmdvb2QuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3Lmdvb2QuY29tPC9hPik8YnI+PGJy Pjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj48Yj5Gcm9tOiZuYnNwOzwvYj5Xb2xm Z2FuZyBCZWNrIFs8YSBocmVmPSJtYWlsdG86d29sZmdhbmcuYmVjazAxQGdvb2dsZW1haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+d29sZmdhbmcuYmVjazAxQGdvb2dsZW1haWwuY29tPC9hPl08YnI+ PGI+U2VudDombmJzcDs8L2I+VGh1cnNkYXksIE5vdmVtYmVyIDA3LCAyMDEzIDA1OjIzIFBNIEVh c3Rlcm4gU3RhbmRhcmQgVGltZTxicj48Yj5UbzombmJzcDs8L2I+UGV0ZXJzb24sIEpvbjxicj48 Yj5DYzombmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRvOnN0aXJAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zdGlyQGlldGYub3JnPC9hPjxicj48Yj5TdWJqZWN0OiZuYnNwOzwvYj5SRTogW3N0aXJd IG5ldyBTSVAgTWV0aG9kIERZUFRDICdEaWQgWW91IFBsYWNlIFRoaXMgQ2FsbD8nPG86cD48L286 cD48L3A+PHA+V291bGQgeW91IGFncmVlIHRoYXQgc3VjaCBhIFNJUCBtZXNzYWdlIHdvdWxkIGFy cml2ZSBhdCBhbiBlbGVtZW50IG9mIGEgcGFydHkgdGhhdCBoYXMgZGVsZWdhdGVkIHRoZSBudW1i ZXIgdG8gaXRzIGN1cnJlbnQgdXNlcj8gU29sdmluZyB0aGUgcHJvYmxlbSAnd2hvIG93bnMgdGhp cyBudW1iZXI/JyBzZWVtcyBlYXNpZXIgdG8gbWUgaW5zaWRlIHRoZSBzeXN0ZW0gdGhhbiBpbiBh IHNlcGFyYXRlIG9uZS48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BbSAw Ny4xMS4yMDEzIDEzOjI2IHNjaHJpZWIgJnF1b3Q7UGV0ZXJzb24sIEpvbiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpeiIgdGFyZ2V0PSJfYmxhbmsiPmpv bi5wZXRlcnNvbkBuZXVzdGFyLmJpejwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+VmFyaW91cyAmcXVvdDtj YWxsYmFjayZxdW90OyBtZWNoYW5pc21zIGFsb25nIHRoZXNlIGxpbmVzIGhhdmUgYmVlbiBjb25z aWRlcmVkLCBhbmQgdGhlcmUgYXJlIGtub3duIGxpbWl0YXRpb25zIG9mIHRoZXNlIG1lY2hhbmlz bXMsIG1vc3Qgb2Ygd2hpY2ggcmVzdWx0IGZyb20gdGhlIGZhY3QgdGhhdCBwbGFjaW5nIGEgY2Fs bCBmcm9tIGEgbnVtYmVyIGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IGEgcmV0dXJuZWQgY2FsbCB3 b3VsZCByZWFjaCB0aGUgc2FtZSBlbmRwb2ludCBpbnN0YW5jZS4gR2F0ZXdheXMsIGNhbGwgY2Vu dGVycywgdXNlcnMgd2l0aCBtdWx0aXBsZSBjb25jdXJyZW50bHkgcmVnaXN0ZXJlZCBkZXZpY2Vz LCBhbGwgb2Ygb3VyICZxdW90O2RvY3RvcidzIG9mZmljZSZxdW90OyB1c2UgY2FzZXMgYW5kIHJl bGF0ZWQgY29uZmlndXJhdGlvbnMgc2hvdyB3aHkgYXBwcm9hY2hlcyBhbG9uZyB0aGVzZSBsaW5l cyBhcmUgaW5zdWZmaWNpZW50Ljxicj48YnI+Sm9uIFBldGVyc29uPGJyPk5ldXN0YXIsIGluYy48 YnI+PGJyPjxicj48YnI+U2VudCB3aXRoIEdvb2QgKDxhIGhyZWY9Imh0dHA6Ly93d3cuZ29vZC5j b20iIHRhcmdldD0iX2JsYW5rIj53d3cuZ29vZC5jb208L2E+KTxicj48YnI+PGJyPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPjxiPkZyb206Jm5ic3A7PC9iPldvbGZnYW5nIEJlY2sgWzxh IGhyZWY9Im1haWx0bzp3b2xmZ2FuZy5iZWNrMDFAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj53b2xmZ2FuZy5iZWNrMDFAZ29vZ2xlbWFpbC5jb208L2E+XTxicj48Yj5TZW50OiZuYnNw OzwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMDcsIDIwMTMgMDQ6MTggUE0gRWFzdGVybiBTdGFuZGFy ZCBUaW1lPGJyPjxiPlRvOiZuYnNwOzwvYj48YSBocmVmPSJtYWlsdG86c3RpckBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnN0aXJAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6Jm5ic3A7PC9i PltzdGlyXSBuZXcgU0lQIE1ldGhvZCBEWVBUQyAnRGlkIFlvdSBQbGFjZSBUaGlzIENhbGw/Jzxv OnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5IZXJlJ3MgYSBoYWxmLWJha2VkIGlkZWE6IHdoZW4gYSBjYWxsIGMxIGFyaXZlcyBmcm9t ICZsdDthJmd0OywgSSBzZW5kIGEgRFlQVEMgU0lQIHJlcXVlc3QgbWVzc2FnZSBvdXRzaWRlIG9m IHRoaXMgY2FsbCBiYWNrIHRvICZsdDthJmd0Oy4gVGhlIERZUFRDIHJlcXVlc3QgY2FycmllcyBz b21lIGhlYWRlcnMgdGhhdCBkZXNjcmliZSBjMSwgZWcuIHRoZSBvcmlnaW5hbCBmcm9tIGFuZCB0 by48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+LSBpZiB0 aGUgcmVjZWl2aW5nIFVBIGlzIGluZGVlZCAmbHQ7YSZndDssIGl0IHJlc3BvbmRzIHdpdGggMjAw IE9LLiBUaGUgb3JpZ2luIG9mIGNhbGwgYzEgaXMgbm93IHZlcmlmaWVkLjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj4tIGlmICZsdDthJmd0OyB3YXMgc3Bv b2ZlZCBieSBzb21lYm9keSwgdGhlIHJlcXVlc3Qgd2lsbCBhcnJpdmUgYXQgYSBVQSB0aGF0IGRv ZXMgbm90IGtub3cgYWJvdXQgdGhlIGNhbGwgZGVzY3JpYmVkIGJ5IERZUFRDLiBJdCByZXNwb25k cyB3aXRoIDQwNCBOb3QgRm91bmQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj4tIGlmICZsdDthJmd0OyB3 YXMgc3Bvb2ZlZCBhbmQgdGhlcmUgaXMgbm8gVUEgcmVhY2hhYmxlLCB0aGUgcmVxdWVzdCB3aWxs IHRpbWUgb3V0IG9yIHRoZSBuZXR3b3JrIHdpbGwgZ2VuZXJhdGUgYSA0MDQgTm90IGZvdW5kLjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldoZW5ldmVyIEkgZG9u dCByZWNlaXZlIGEgMjAwIE9LIG9uIGEgRFlQVEMsIHRoZSBjYWxsaW5nIG51bWJlciBjb3VsZCBu b3QgYmUgdmVyaWZpZWQuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5TbyBmYXIgYWxsIG1ldGhvZHMgdG8gZGV0ZXJtaW5l IGEgcGFydHkgdGhhdCBjYW4gdmVyaWZ5IGEgbnVtYmVyIHNlZW0gdG8gYm9pbCBkb3duIHRvIG9u ZSBvZiB0aGUgdHdvIGdyb3Vwczo8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz4xLiBjcmVhdGUgYSBuZXcgZGF0YWJhc2Us IHJlcGxpY2F0ZWQgZnJvbSB0aGUgdGVsY29zJyBkYXRhYmFzZXMsIHRoYXQgY2FuIGJlIGFjY2Vz c2VkIGJ5IGVuZCBkZXZpY2VzLiBUaGF0J3Mgd2hhdCBpTWVzc2FnZSwgd2hhdHNhcHAsIGFuZCBW SVBSIHRyeSB0byBkby4gQWNjdXJhdGVseSByZXBsaWNhdGluZyBhIGZhaXJseSBkeW5hbWljIGRh dGFiYXNlIHdpdGhvdXQgaXRzIGNvb3BlcmF0aW9uIGlzIGEgY2hhbGxlbmdlLjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn PjIuIGNyZWF0ZSBhIHdheSBzbyB0aGF0IGVuZCBkZXZpY2VzIGNhbiBkaXJlY3RseSBxdWVyeSB0 aGUgdGVsY29zJyBkYXRhYmFzZXMuIEROUyBpcyBhbiBvYnZpb3VzIGNhbmRpZGF0ZSBmb3IgdGhp cy48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0Jz5Ib3dldmVyLCBhY2Nlc3NpbmcgdGhlIGRhdGFiYXNlIGl0c2VsZiBpcyBu b3QgZW5vdWdoLiBUaGUgZW5kIGRldmljZSB3b3VsZCBoYXZlIHRvIHJlcGxpY2F0ZSBhbGwgcm91 dGluZyBkZWNpc2lvbnMgdGhlIHRlbGNvcyBtYWtlLiBBbGwgZGlzY3Vzc2lvbnMgYWJvdXQgUEJY cyBhbmQgbnVtYmVyIHBvcnRhYmlsaXR5IGFyZSBlc3NlbnRpYWxseSBhYm91dCB0aGUgcm91dGlu ZyBpbnNpZGUgdGhlIHRlbGNvcy48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5XaHkgbm90IGp1c3QgdXNlIHRoZSBleGlz dGluZyBwbGF0Zm9ybSB0byB2ZXJpZnkgY2FsbGluZyBudW1iZXJzPzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+V29sZmdhbmcgQmVjazxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_900A1E2059ADB149B905E3C8FA0046A62C80400CB6FHDP1LUMXC7V2_-- From wolfgang.beck01@googlemail.com Thu Nov 7 18:01:46 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A504511E8101 for ; Thu, 7 Nov 2013 18:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BJEL85WKfKz for ; Thu, 7 Nov 2013 18:01:45 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 569C911E8202 for ; Thu, 7 Nov 2013 18:01:41 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id ld13so968730vcb.33 for ; Thu, 07 Nov 2013 18:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rTlUNfqKyFRb2ZgnDeukpHFPZthEFa/34+IK55hsl+g=; b=K2bbmsMkv0T9BcUIovwp5urAN6IXCtVoSEggbf10TRpHx1RXgROoCyqAyAHcP0yH3e 1cpQsqM/DTWno4xgQP/cqSpWDX+sMzqPDdwrDDHJio8c6xy9fJD/l8RFihs/uxnrDDdU aZ0t/QzA8jtT60wXLqABghEeZDpFGh2DzwZqBOcZSJ7Q3ZxxMls0DjBGO37PmE/Z9ffu x2XNqCb3wH6FOQBqu8odkkYYvPLVPmWvxRZ2u/kvvzOusIdDUmCGnVTzqsLTHn4tQHHt s9phN5xioyMOx0XBNk4Lqe5DuR+ei3KCAaS4z0VGkg5JtakEaGUlQU9SbBBkPHcBphHo pQrQ== MIME-Version: 1.0 X-Received: by 10.58.133.77 with SMTP id pa13mr9392977veb.21.1383876100582; Thu, 07 Nov 2013 18:01:40 -0800 (PST) Received: by 10.58.45.169 with HTTP; Thu, 7 Nov 2013 18:01:40 -0800 (PST) Received: by 10.58.45.169 with HTTP; Thu, 7 Nov 2013 18:01:40 -0800 (PST) In-Reply-To: <900A1E2059ADB149B905E3C8FA0046A62C80400CB6@FHDP1LUMXC7V23.us.one.verizon.com> References: <596979554D802045BBD45C051A4399E40D40C829@STNTEXMB10.cis.neustar.com> <900A1E2059ADB149B905E3C8FA0046A62C80400CB6@FHDP1LUMXC7V23.us.one.verizon.com> Date: Fri, 8 Nov 2013 03:01:40 +0100 Message-ID: From: Wolfgang Beck To: "Mishra, Sanjay" Content-Type: multipart/alternative; boundary=047d7b67339863781304eaa0c318 Cc: stir@ietf.org, Jon Peterson Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 02:01:46 -0000 --047d7b67339863781304eaa0c318 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The two are completely different things, but use a similar mechanism to verify e164 numbers. VIPR was an attempt to replicate the telcos' number databases into a P2P DB that would be filled by making calls through the phone network. The idea was that one day all numbers would be in the P2P DB and calls through the phone network would rarely be necessary. Am 07.11.2013 16:36 schrieb "Mishra, Sanjay" : > Wolfgang, Jon =96 Is the reference below is for =93VIPR=94 is as in the = voice > service offered by =93VIBER=94 or is the reference here is to =93Verifica= tion > Involving PSTN Reachability (VIPR)? > > > > It sounds to me Woffgang is referencing VIBER but I can be wrong. > > > > Sanjay > > > > *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf > Of *Peterson, Jon > *Sent:* Thursday, November 07, 2013 4:24 PM > *To:* 'Wolfgang Beck' > *Cc:* 'stir@ietf.org' > *Subject:* Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' > > > > Those verification systems like VIPR and Whatsapp are reliable only in so > far as their call signaling goes exclusively through the PSTN - the DYPTC > method wouldn't go over SS7 unfortunately. > > Jon Peterson > Neustar, Inc. > > > > Sent with Good (www.good.com) > > > -----Original Message----- > *From: *Wolfgang Beck [wolfgang.beck01@googlemail.com] > *Sent: *Thursday, November 07, 2013 07:12 PM Eastern Standard Time > *To: *Peterson, Jon > *Cc: *stir@ietf.org > *Subject: *RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' > > VIPR, whatsapp, iMessage all use the phone network for verification. > Public ENUM registrars used it. The principle seems to be working for > sufficiently large number of cases. > > Am 07.11.2013 14:38 schrieb "Peterson, Jon" : > > > I believe that SIP messages routed to telephone numbers today are mostly > frequently dropped to the PSTN, and may eventually re-enter the Internet = or > not. In cases where requests targeting telephone numbers do travel > end-to-end over the Internet, various flat files and private databases ar= e > consulted to forward requests hop-by-hop until they reach a destination. > The relationships of those mechanisms to numbering authorities can be > tenuous today, precisely because of the absence of the authority > architecture this working group is considering. > > There's no free lunch here. > > Jon Peterson > Neustar, Inc. > > > > Sent with Good (www.good.com) > > > -----Original Message----- > *From: *Wolfgang Beck [wolfgang.beck01@googlemail.com] > *Sent: *Thursday, November 07, 2013 05:23 PM Eastern Standard Time > *To: *Peterson, Jon > *Cc: *stir@ietf.org > *Subject: *RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' > > Would you agree that such a SIP message would arrive at an element of a > party that has delegated the number to its current user? Solving the > problem 'who owns this number?' seems easier to me inside the system than > in a separate one. > > Am 07.11.2013 13:26 schrieb "Peterson, Jon" : > > Various "callback" mechanisms along these lines have been considered, and > there are known limitations of these mechanisms, most of which result fro= m > the fact that placing a call from a number does not guarantee that a > returned call would reach the same endpoint instance. Gateways, call > centers, users with multiple concurrently registered devices, all of our > "doctor's office" use cases and related configurations show why approache= s > along these lines are insufficient. > > Jon Peterson > Neustar, inc. > > > > Sent with Good (www.good.com) > > > -----Original Message----- > *From: *Wolfgang Beck [wolfgang.beck01@googlemail.com] > *Sent: *Thursday, November 07, 2013 04:18 PM Eastern Standard Time > *To: *stir@ietf.org > *Subject: *[stir] new SIP Method DYPTC 'Did You Place This Call?' > > Here's a half-baked idea: when a call c1 arives from , I send a DYPTC > SIP request message outside of this call back to . The DYPTC request > carries some headers that describe c1, eg. the original from and to. > > > - if the receiving UA is indeed , it responds with 200 OK. The origin > of call c1 is now verified. > > > - if was spoofed by somebody, the request will arrive at a UA that > does not know about the call described by DYPTC. It responds with 404 Not > Found > > > - if was spoofed and there is no UA reachable, the request will time > out or the network will generate a 404 Not found. > > Whenever I dont receive a 200 OK on a DYPTC, the calling number could not > be verified. > > > > So far all methods to determine a party that can verify a number seem to > boil down to one of the two groups: > > 1. create a new database, replicated from the telcos' databases, that can > be accessed by end devices. That's what iMessage, whatsapp, and VIPR try = to > do. Accurately replicating a fairly dynamic database without its > cooperation is a challenge. > > 2. create a way so that end devices can directly query the telcos' > databases. DNS is an obvious candidate for this. > > However, accessing the database itself is not enough. The end device woul= d > have to replicate all routing decisions the telcos make. All discussions > about PBXs and number portability are essentially about the routing insid= e > the telcos. > > Why not just use the existing platform to verify calling numbers? > > > Wolfgang Beck > --047d7b67339863781304eaa0c318 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

The two are completely different things, but use a similar m= echanism to verify e164 numbers. VIPR was an attempt to replicate the telco= s' number databases into a P2P DB that would be filled by making calls = through the phone network. The idea was that one day all numbers would be i= n the P2P DB and calls through the phone network would rarely be necessary.= =A0

Am 07.11.2013 16:36 schrieb "Mishra, Sanjay= " <sanjay.mishra@veriz= on.com>:

Wolfgang, Jon =96 Is the reference below is = for =A0=93VIPR=94 is as in the voice service offered by =93VIBER=94 or is t= he reference here is to =93Verification Involving PSTN Reachability (VIPR)?=

=A0<= /p>

It sounds to me Woffga= ng is referencing VIBER but I can be wrong.

=A0<= /p>

Sanjay<= /span>

=A0<= /p>

From: stir-bounces@ietf.org [mailto:stir-= bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Thursday, November 07, 2013 4:24 PM
To: 'Wolfgan= g Beck'
Cc: 'stir@ietf.org'
Subject: Re: [stir] new SIP Method = DYPTC 'Did You Place This Call?'

=A0

Those verification systems like VIPR and= Whatsapp are reliable only in so far as their call signaling goes exclusiv= ely through the PSTN - the DYPTC method wouldn't go over SS7 unfortunat= ely.

Jon Peterson
Neustar, Inc.



Sent with Good (www.good.com)


-----O= riginal Message-----
From:=A0Wolfgang Beck [wolfgang.beck01@googlemail.c= om]
Sent:=A0Thursday, November 07, 2013 07:12 PM Eastern Standard TimeTo:=A0Peterson, Jon
Cc:=A0stir@ietf.org
Subject:=A0RE: [stir] new = SIP Method DYPTC 'Did You Place This Call?'

VIPR, whatsapp, iMessage all use the phone network for verification. Pub= lic ENUM registrars used it. The principle seems to be working for sufficie= ntly large number of cases.

Am 07.11.2013 14:38 schrieb "Peterson, Jon" <jon.peterson@neustar.biz&g= t;:


I believe that SIP messages routed to telephone numbers today are mostl= y frequently dropped to the PSTN, and may eventually re-enter the Internet = or not. In cases where requests targeting telephone numbers do travel end-t= o-end over the Internet, various flat files and private databases are consu= lted to forward requests hop-by-hop until they reach a destination. The rel= ationships of those mechanisms to numbering authorities can be tenuous toda= y, precisely because of the absence of the authority architecture this work= ing group is considering.

There's no free lunch here.

Jon Peterson
Neustar, Inc.


Sent with Good (www.good.com)


-----Original Message-----
From:=A0<= /b>Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent:=A0Thursday, November 07, 2013 05:23 PM Eastern Standard TimeTo:=A0Peterson, Jon
Cc:=A0stir@ietf.org
Subject:=A0RE: [stir] new = SIP Method DYPTC 'Did You Place This Call?'

Would you agree that such a SIP message would arrive at an element of a = party that has delegated the number to its current user? Solving the proble= m 'who owns this number?' seems easier to me inside the system than= in a separate one.

Am 07.11.2013 13:26 schrieb "Peterson, Jon= " <jo= n.peterson@neustar.biz>:

Various "callback" mechanisms along these lines have been conside= red, and there are known limitations of these mechanisms, most of which res= ult from the fact that placing a call from a number does not guarantee that= a returned call would reach the same endpoint instance. Gateways, call cen= ters, users with multiple concurrently registered devices, all of our "= ;doctor's office" use cases and related configurations show why ap= proaches along these lines are insufficient.

Jon Peterson
Neustar, inc.



Sent with Good (www.good.com)


-----O= riginal Message-----
From:=A0Wolfgang Beck [wolfgang.beck01@googlemail.c= om]
Sent:=A0Thursday, November 07, 2013 04:18 PM Eastern Standard TimeTo:=A0stir@ietf= .org
Subject:=A0[stir] new SIP Method DYPTC 'Did You Plac= e This Call?'

Here's a half-bake= d idea: when a call c1 arives from <a>, I send a DYPTC SIP request me= ssage outside of this call back to <a>. The DYPTC request carries som= e headers that describe c1, eg. the original from and to.


- if the receiving UA is indeed <a= >, it responds with 200 OK. The origin of call c1 is now verified.


- if <a> was spoofe= d by somebody, the request will arrive at a UA that does not know about the= call described by DYPTC. It responds with 404 Not Found


- if &= lt;a> was spoofed and there is no UA reachable, the request will time ou= t or the network will generate a 404 Not found.

Whenever I dont receive a 200 OK on a DYPTC, the cal= ling number could not be verified.

=A0

So far all methods to determine a party that can verify a number seem to bo= il down to one of the two groups:

1. create a new database, replicated fr= om the telcos' databases, that can be accessed by end devices. That'= ;s what iMessage, whatsapp, and VIPR try to do. Accurately replicating a fa= irly dynamic database without its cooperation is a challenge.=

2. create a way= so that end devices can directly query the telcos' databases. DNS is a= n obvious candidate for this.

However, accessing the database itself is not enough. The end device would = have to replicate all routing decisions the telcos make. All discussions ab= out PBXs and number portability are essentially about the routing inside th= e telcos.

Why not just us= e the existing platform to verify calling numbers?

<= p class=3D"MsoNormal">
Wolfgang Beck

=
--047d7b67339863781304eaa0c318-- From wolfgang.beck01@googlemail.com Thu Nov 7 18:12:31 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AC611E8101 for ; Thu, 7 Nov 2013 18:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe9fbbhf9HrY for ; Thu, 7 Nov 2013 18:12:29 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7EE11E8170 for ; Thu, 7 Nov 2013 18:12:24 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id jx11so273558veb.40 for ; Thu, 07 Nov 2013 18:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vw5+Iz6hW7OvfKDH6RQMbc8GlqFEiap35Rq/HlRtC4o=; b=YP3Qd5YPP25krVwEP4sTYwss7ARhlc9akPBFlwyi/r8OoeaGXJj9rNAdOHTYlQwS9S VtNC/XX3YdoCUiKMF0Qgveag5w/d70/hjUCuScXtMyWPU/OpbZytgQbv2wCdB4jsNUbZ X5UlvwdsatybGGnUzbvO7oNEjpGFsHdQ8eT6deQFPqvV36R3llCd7CrMCniDxWfQPTjx L8ER9UKzPVAMdAjE9/rToGf2PotHMwzPh3rFnjTECE8gd/WefNd7Xo6+0wlvKzLOQSIp N/slNisVO743SHheLUqp4P0RO4rN+Ej9BbWt/LLTrZ17OEZNxtJJ5p7aRty5KAQVLTsl UdhA== MIME-Version: 1.0 X-Received: by 10.52.243.138 with SMTP id wy10mr7993800vdc.2.1383876740514; Thu, 07 Nov 2013 18:12:20 -0800 (PST) Received: by 10.58.45.169 with HTTP; Thu, 7 Nov 2013 18:12:20 -0800 (PST) Received: by 10.58.45.169 with HTTP; Thu, 7 Nov 2013 18:12:20 -0800 (PST) In-Reply-To: <596979554D802045BBD45C051A4399E40D40C829@STNTEXMB10.cis.neustar.com> References: <596979554D802045BBD45C051A4399E40D40C829@STNTEXMB10.cis.neustar.com> Date: Fri, 8 Nov 2013 03:12:20 +0100 Message-ID: From: Wolfgang Beck To: Jon Peterson Content-Type: multipart/alternative; boundary=001a11c1c4a68809b504eaa0e9d0 Cc: stir@ietf.org Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 02:12:31 -0000 --001a11c1c4a68809b504eaa0e9d0 Content-Type: text/plain; charset=ISO-8859-1 So you dont trust the SIP networks to *deliver* a call to the correct destination? The difference between DYPTC and whatsapp is that whatsapp uses the payload of an sms for signalling. The public enum registrars used an automatic voice that read a code - payload again - that the user entered into a web form. Wolfgang Beck Am 07.11.2013 16:24 schrieb "Peterson, Jon" : > Those verification systems like VIPR and Whatsapp are reliable only in so > far as their call signaling goes exclusively through the PSTN - the DYPTC > method wouldn't go over SS7 unfortunately. > > Jon Peterson > Neustar, Inc. > > > > Sent with Good (www.good.com) > > > -----Original Message----- > *From: *Wolfgang Beck [wolfgang.beck01@googlemail.com] > *Sent: *Thursday, November 07, 2013 07:12 PM Eastern Standard Time > *To: *Peterson, Jon > *Cc: *stir@ietf.org > *Subject: *RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' > > VIPR, whatsapp, iMessage all use the phone network for verification. > Public ENUM registrars used it. The principle seems to be working for > sufficiently large number of cases. > Am 07.11.2013 14:38 schrieb "Peterson, Jon" : > >> >> I believe that SIP messages routed to telephone numbers today are mostly >> frequently dropped to the PSTN, and may eventually re-enter the Internet or >> not. In cases where requests targeting telephone numbers do travel >> end-to-end over the Internet, various flat files and private databases are >> consulted to forward requests hop-by-hop until they reach a destination. >> The relationships of those mechanisms to numbering authorities can be >> tenuous today, precisely because of the absence of the authority >> architecture this working group is considering. >> >> There's no free lunch here. >> >> Jon Peterson >> Neustar, Inc. >> >> >> >> Sent with Good (www.good.com) >> >> >> -----Original Message----- >> *From: *Wolfgang Beck [wolfgang.beck01@googlemail.com] >> *Sent: *Thursday, November 07, 2013 05:23 PM Eastern Standard Time >> *To: *Peterson, Jon >> *Cc: *stir@ietf.org >> *Subject: *RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' >> >> Would you agree that such a SIP message would arrive at an element of a >> party that has delegated the number to its current user? Solving the >> problem 'who owns this number?' seems easier to me inside the system than >> in a separate one. >> Am 07.11.2013 13:26 schrieb "Peterson, Jon" : >> >>> Various "callback" mechanisms along these lines have been considered, >>> and there are known limitations of these mechanisms, most of which result >>> from the fact that placing a call from a number does not guarantee that a >>> returned call would reach the same endpoint instance. Gateways, call >>> centers, users with multiple concurrently registered devices, all of our >>> "doctor's office" use cases and related configurations show why approaches >>> along these lines are insufficient. >>> >>> Jon Peterson >>> Neustar, inc. >>> >>> >>> >>> Sent with Good (www.good.com) >>> >>> >>> -----Original Message----- >>> *From: *Wolfgang Beck [wolfgang.beck01@googlemail.com] >>> *Sent: *Thursday, November 07, 2013 04:18 PM Eastern Standard Time >>> *To: *stir@ietf.org >>> *Subject: *[stir] new SIP Method DYPTC 'Did You Place This Call?' >>> >>> Here's a half-baked idea: when a call c1 arives from , I send a >>> DYPTC SIP request message outside of this call back to . The DYPTC >>> request carries some headers that describe c1, eg. the original from and to. >>> >>> - if the receiving UA is indeed , it responds with 200 OK. The origin >>> of call c1 is now verified. >>> >>> - if was spoofed by somebody, the request will arrive at a UA that >>> does not know about the call described by DYPTC. It responds with 404 Not >>> Found >>> >>> - if was spoofed and there is no UA reachable, the request will time >>> out or the network will generate a 404 Not found. >>> >>> Whenever I dont receive a 200 OK on a DYPTC, the calling number could >>> not be verified. >>> >>> So far all methods to determine a party that can verify a number seem >>> to boil down to one of the two groups: >>> >>> 1. create a new database, replicated from the telcos' databases, that >>> can be accessed by end devices. That's what iMessage, whatsapp, and VIPR >>> try to do. Accurately replicating a fairly dynamic database without its >>> cooperation is a challenge. >>> >>> 2. create a way so that end devices can directly query the telcos' >>> databases. DNS is an obvious candidate for this. >>> >>> However, accessing the database itself is not enough. The end device >>> would have to replicate all routing decisions the telcos make. All >>> discussions about PBXs and number portability are essentially about the >>> routing inside the telcos. >>> >>> Why not just use the existing platform to verify calling numbers? >>> >>> >>> Wolfgang Beck >>> >> --001a11c1c4a68809b504eaa0e9d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

So you dont trust the SIP networks to *deliver* a call to th= e correct destination? The difference between DYPTC and whatsapp is that wh= atsapp uses the payload of an sms for signalling. The public enum registrar= s used an automatic voice that read a code - payload again - that the user = entered into a web form.

Wolfgang Beck

Am 07.11.2013 16:24 schrieb "Peterson, Jon&= quot; <jon.peterson@neustar.= biz>:
Those verification systems like VIPR and Whatsapp are reliable only in so f= ar as their call signaling goes exclusively through the PSTN - the DYPTC me= thod wouldn't go over SS7 unfortunately.

Jon Peterson
Neustar, Inc.



Sent with Good (www.good.= com)


-----Original Message-----
From:=A0Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent:=A0Thursday, November 07, 2013 07:12 PM Eastern Standard Time To:=A0Peterson, Jon
Cc:=A0stir@ietf.o= rg
Subject:=A0RE: [stir] new SIP Method DYPTC 'Did You Place This C= all?'

VIPR, whatsapp, iMessage all use the phone network for verif= ication. Public ENUM registrars used it. The principle seems to be working = for sufficiently large number of cases.

Am 07.11.2013 14:38 schrieb "Peterson, Jon&= quot; <jon= .peterson@neustar.biz>:

I believe that SIP messages routed to telephone numbers today are mostly fr= equently dropped to the PSTN, and may eventually re-enter the Internet or n= ot. In cases where requests targeting telephone numbers do travel end-to-en= d over the Internet, various flat files and private databases are consulted to forward requests hop-by-hop u= ntil they reach a destination. The relationships of those mechanisms to num= bering authorities can be tenuous today, precisely because of the absence o= f the authority architecture this working group is considering.

There's no free lunch here.

Jon Peterson
Neustar, Inc.



Sent with Good (www.good.= com)


-----Original Message-----
From:=A0Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent:=A0Thursday, November 07, 2013 05:23 PM Eastern Standard Time To:=A0Peterson, Jon
Cc:=A0stir@ietf.o= rg
Subject:=A0RE: [stir] new SIP Method DYPTC 'Did You Place This C= all?'

Would you agree that such a SIP message would arrive at an e= lement of a party that has delegated the number to its current user? Solvin= g the problem 'who owns this number?' seems easier to me inside the= system than in a separate one.

Am 07.11.2013 13:26 schrieb "Peterson, Jon&= quot; <jon= .peterson@neustar.biz>:
Various "callback" mechanisms along these lines have been co= nsidered, and there are known limitations of these mechanisms, most of whic= h result from the fact that placing a call from a number does not guarantee= that a returned call would reach the same endpoint instance. Gateways, call centers, users with multiple concurrentl= y registered devices, all of our "doctor's office" use cases = and related configurations show why approaches along these lines are insuff= icient.

Jon Peterson
Neustar, inc.



Sent with Good (www.good.= com)


-----Original Message-----
From:=A0Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent:=A0Thursday, November 07, 2013 04:18 PM Eastern Standard Time To:=A0stir@ietf.o= rg
Subject:=A0[stir] new SIP Method DYPTC 'Did You Place This Call?= '

Here's a half-baked idea: when a call c1 arives from <a>, I = send a DYPTC SIP request message outside of this call back to <a>. Th= e DYPTC request carries some headers that describe c1, eg. the original fro= m and to.

- if the receiving UA is indeed <a>, it responds with 200 OK. The ori= gin of call c1 is now verified.

- if <a> was spoofed by somebody, the request will arrive at a UA tha= t does not know about the call described by DYPTC. It responds with 404 Not= Found

- if <a> was spoofed and there is no UA reachable, the request will t= ime out or the network will generate a 404 Not found.

Whenever I dont receive a 200 OK on a DYPTC, the calling number could = not be verified.

So far all methods to determine a party that can verify a number seem = to boil down to one of the two groups:

1. create a new database, replicated from the telcos' databases, that c= an be accessed by end devices. That's what iMessage, whatsapp, and VIPR= try to do. Accurately replicating a fairly dynamic database without its co= operation is a challenge.

2. create a way so that end devices can directly query the telcos' data= bases. DNS is an obvious candidate for this.

However, accessing the database itself is not enough. The end device would = have to replicate all routing decisions the telcos make. All discussions ab= out PBXs and number portability are essentially about the routing inside th= e telcos.

Why not just use the existing platform to verify calling numbers?


Wolfgang Beck
--001a11c1c4a68809b504eaa0e9d0-- From sanjay.mishra@verizon.com Thu Nov 7 18:29:14 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EDF21E80D2 for ; Thu, 7 Nov 2013 18:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCQsh-xVn-qa for ; Thu, 7 Nov 2013 18:29:07 -0800 (PST) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4A07821E8119 for ; Thu, 7 Nov 2013 18:29:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 08 Nov 2013 02:29:05 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="4.93,656,1378857600"; d="scan'208,217";a="588186173" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 08 Nov 2013 02:29:05 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([169.254.3.98]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Thu, 7 Nov 2013 21:29:05 -0500 To: Wolfgang Beck Date: Thu, 7 Nov 2013 21:29:03 -0500 Thread-Topic: [stir] new SIP Method DYPTC 'Did You Place This Call?' Thread-Index: Ac7cJnqStmquK3sOTwGnFSmEv8z06AAA12BQ Message-ID: <900A1E2059ADB149B905E3C8FA0046A62C80400CCF@FHDP1LUMXC7V23.us.one.verizon.com> References: <596979554D802045BBD45C051A4399E40D40C829@STNTEXMB10.cis.neustar.com> <900A1E2059ADB149B905E3C8FA0046A62C80400CB6@FHDP1LUMXC7V23.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_900A1E2059ADB149B905E3C8FA0046A62C80400CCFFHDP1LUMXC7V2_" MIME-Version: 1.0 Cc: "stir@ietf.org" , Jon Peterson Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 02:29:14 -0000 --_000_900A1E2059ADB149B905E3C8FA0046A62C80400CCFFHDP1LUMXC7V2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, understand the two are different and since VIPR was paired in email be= low with WhatsApp, I was asking if you indeed meant VIPR and that you were = not talking about services like WhatsAPP AND VIBER. But, I see you were ind= eed referencing VIPR in the e.164 context along with verification used by s= ervices like WhatsApp. I am good. Thanks Sanjay From: Wolfgang Beck [mailto:wolfgang.beck01@googlemail.com] Sent: Thursday, November 07, 2013 6:02 PM To: Mishra, Sanjay Cc: Jon Peterson; stir@ietf.org Subject: RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' The two are completely different things, but use a similar mechanism to ver= ify e164 numbers. VIPR was an attempt to replicate the telcos' number datab= ases into a P2P DB that would be filled by making calls through the phone n= etwork. The idea was that one day all numbers would be in the P2P DB and ca= lls through the phone network would rarely be necessary. Am 07.11.2013 16:36 schrieb "Mishra, Sanjay" >: Wolfgang, Jon - Is the reference below is for "VIPR" is as in the voice se= rvice offered by "VIBER" or is the reference here is to "Verification Invol= ving PSTN Reachability (VIPR)? It sounds to me Woffgang is referencing VIBER but I can be wrong. Sanjay From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Peterson, Jon Sent: Thursday, November 07, 2013 4:24 PM To: 'Wolfgang Beck' Cc: 'stir@ietf.org' Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' Those verification systems like VIPR and Whatsapp are reliable only in so f= ar as their call signaling goes exclusively through the PSTN - the DYPTC me= thod wouldn't go over SS7 unfortunately. Jon Peterson Neustar, Inc. Sent with Good (www.good.com) -----Original Message----- From: Wolfgang Beck [wolfgang.beck01@googlemail.com] Sent: Thursday, November 07, 2013 07:12 PM Eastern Standard Time To: Peterson, Jon Cc: stir@ietf.org Subject: RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' VIPR, whatsapp, iMessage all use the phone network for verification. Public= ENUM registrars used it. The principle seems to be working for sufficientl= y large number of cases. Am 07.11.2013 14:38 schrieb "Peterson, Jon" >: I believe that SIP messages routed to telephone numbers today are mostly fr= equently dropped to the PSTN, and may eventually re-enter the Internet or n= ot. In cases where requests targeting telephone numbers do travel end-to-en= d over the Internet, various flat files and private databases are consulted= to forward requests hop-by-hop until they reach a destination. The relatio= nships of those mechanisms to numbering authorities can be tenuous today, p= recisely because of the absence of the authority architecture this working = group is considering. There's no free lunch here. Jon Peterson Neustar, Inc. Sent with Good (www.good.com) -----Original Message----- From: Wolfgang Beck [wolfgang.beck01@googlemail.com] Sent: Thursday, November 07, 2013 05:23 PM Eastern Standard Time To: Peterson, Jon Cc: stir@ietf.org Subject: RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' Would you agree that such a SIP message would arrive at an element of a par= ty that has delegated the number to its current user? Solving the problem '= who owns this number?' seems easier to me inside the system than in a separ= ate one. Am 07.11.2013 13:26 schrieb "Peterson, Jon" >: Various "callback" mechanisms along these lines have been considered, and t= here are known limitations of these mechanisms, most of which result from t= he fact that placing a call from a number does not guarantee that a returne= d call would reach the same endpoint instance. Gateways, call centers, user= s with multiple concurrently registered devices, all of our "doctor's offic= e" use cases and related configurations show why approaches along these lin= es are insufficient. Jon Peterson Neustar, inc. Sent with Good (www.good.com) -----Original Message----- From: Wolfgang Beck [wolfgang.beck01@googlemail.com] Sent: Thursday, November 07, 2013 04:18 PM Eastern Standard Time To: stir@ietf.org Subject: [stir] new SIP Method DYPTC 'Did You Place This Call?' Here's a half-baked idea: when a call c1 arives from , I send a DYPTC SI= P request message outside of this call back to . The DYPTC request carri= es some headers that describe c1, eg. the original from and to. - if the receiving UA is indeed , it responds with 200 OK. The origin of= call c1 is now verified. - if was spoofed by somebody, the request will arrive at a UA that does= not know about the call described by DYPTC. It responds with 404 Not Found - if was spoofed and there is no UA reachable, the request will time ou= t or the network will generate a 404 Not found. Whenever I dont receive a 200 OK on a DYPTC, the calling number could not b= e verified. So far all methods to determine a party that can verify a number seem to bo= il down to one of the two groups: 1. create a new database, replicated from the telcos' databases, that can b= e accessed by end devices. That's what iMessage, whatsapp, and VIPR try to = do. Accurately replicating a fairly dynamic database without its cooperatio= n is a challenge. 2. create a way so that end devices can directly query the telcos' database= s. DNS is an obvious candidate for this. However, accessing the database itself is not enough. The end device would = have to replicate all routing decisions the telcos make. All discussions ab= out PBXs and number portability are essentially about the routing inside th= e telcos. Why not just use the existing platform to verify calling numbers? Wolfgang Beck --_000_900A1E2059ADB149B905E3C8FA0046A62C80400CCFFHDP1LUMXC7V2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, unde= rstand the two are different and since VIPR was paired in email below with = WhatsApp, I was asking if you indeed meant VIPR and that you were not talki= ng about services like WhatsAPP AND VIBER. But, I see you were indeed refer= encing VIPR in the e.164 context along with verification used by services l= ike WhatsApp. I am good.

<= o:p> 

Thanks

Sanjay

 

= From:= Wolfgang Beck [mailto:wolfgang.beck01@googlemail.com]
Sent: = Thursday, November 07, 2013 6:02 PM
To: Mishra, Sanjay
Cc:<= /b> Jon Peterson; stir@ietf.org
Subject: RE: [stir] new SIP Metho= d DYPTC 'Did You Place This Call?'

 

The two are completely different things, bu= t use a similar mechanism to verify e164 numbers. VIPR was an attempt to re= plicate the telcos' number databases into a P2P DB that would be filled by = making calls through the phone network. The idea was that one day all numbe= rs would be in the P2P DB and calls through the phone network would rarely = be necessary. 

Am 07.11.2013 = 16:36 schrieb "Mishra, Sanjay" <sanjay.mishra@verizon.com>:

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>Wolfgang, Jon – Is the reference below is for  R= 20;VIPR” is as in the voice service offered by “VIBER” or= is the reference here is to “Verification Involving PSTN Reachabilit= y (VIPR)?

 

It sounds to me Woffgang is referencing VIBER but I can be wron= g.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Sanjay

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Thursday, November 07, 2013 4:24 PM
T= o: 'Wolfgang Beck'
Cc: 'stir@ietf.org'
Subject: Re: [stir] new SIP Meth= od DYPTC 'Did You Place This Call?'

 

Those verification systems like VIPR and Whatsapp ar= e reliable only in so far as their call signaling goes exclusively through = the PSTN - the DYPTC method wouldn't go over SS7 unfortunately.

Jon = Peterson
Neustar, Inc.



Sent with Good (www.good.com)


-----Original = Message-----
From: Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent: Thursday, November 07, 2013 07:12 PM Eastern Standa= rd Time
To: Peterson, Jon
Cc: stir@ietf.org
Subject: <= /b>RE: [stir] new SIP Method DYPTC 'Did You Place This Call?'

VIPR, whatsapp, iMessage all use the phone network for verification. Pu= blic ENUM registrars used it. The principle seems to be working for suffici= ently large number of cases.

Am 07.11.2013 14:38= schrieb "Peterson, Jon" <jon.peterson@neustar.biz>:

<= div>


I believe that SIP messages routed to telephone numbers today are = mostly frequently dropped to the PSTN, and may eventually re-enter the Inte= rnet or not. In cases where requests targeting telephone numbers do travel = end-to-end over the Internet, various flat files and private databases are = consulted to forward requests hop-by-hop until they reach a destination. Th= e relationships of those mechanisms to numbering authorities can be tenuous= today, precisely because of the absence of the authority architecture this= working group is considering.

There's no free lunch here.

Jo= n Peterson
Neustar, Inc.



Sent with Good (www.good.com)


-----Origina= l Message-----
From: Wolfgang Beck [wolfgang.beck01@googlemail.com<= /a>]
Sent: Thursday, November 07, 2013 05:23 PM Eastern Stan= dard Time
To: Peterson, Jon
Cc: stir@ietf.org
Subject: = ;RE: [stir] new SIP Method DYPTC 'Did You Place This Call?'<= /p>

Would you agree that such a SIP message would arrive at an element of= a party that has delegated the number to its current user? Solving the pro= blem 'who owns this number?' seems easier to me inside the system than in a= separate one.

Am 07.11.2013 13:26 schrieb "= Peterson, Jon" <jon.peterson@neustar.biz>:

Various= "callback" mechanisms along these lines have been considered, an= d there are known limitations of these mechanisms, most of which result fro= m the fact that placing a call from a number does not guarantee that a retu= rned call would reach the same endpoint instance. Gateways, call centers, u= sers with multiple concurrently registered devices, all of our "doctor= 's office" use cases and related configurations show why approaches al= ong these lines are insufficient.

Jon Peterson
Neustar, inc.
<= br>

Sent with Good (www.good.com)


-----Original Message-----
From: = Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent: Thursd= ay, November 07, 2013 04:18 PM Eastern Standard Time
To: stir@ietf.org
Sub= ject: [stir] new SIP Method DYPTC 'Did You Place This Call?'<= /o:p>

Here's a half-baked idea: whe= n a call c1 arives from <a>, I send a DYPTC SIP request message outsi= de of this call back to <a>. The DYPTC request carries some headers t= hat describe c1, eg. the original from and to.


- if the receiving UA is indeed <a>, it responds with 200 OK.= The origin of call c1 is now verified.

<= br>- if <a> was spoofed by somebody, the request will arrive at a UA = that does not know about the call described by DYPTC. It responds with 404 = Not Found


- if <a> was spoofed and ther= e is no UA reachable, the request will time out or the network will generat= e a 404 Not found.

Whenever I dont receive = a 200 OK on a DYPTC, the calling number could not be verified.

 

So far all methods to = determine a party that can verify a number seem to boil down to one of the = two groups:

1. create a new database, replicated from = the telcos' databases, that can be accessed by end devices. That's what iMe= ssage, whatsapp, and VIPR try to do. Accurately replicating a fairly dynami= c database without its cooperation is a challenge.

2. = create a way so that end devices can directly query the telcos' databases. = DNS is an obvious candidate for this.

However, accessi= ng the database itself is not enough. The end device would have to replicat= e all routing decisions the telcos make. All discussions about PBXs and num= ber portability are essentially about the routing inside the telcos.

Why not just use the existing platform to verify calling num= bers?


Wolfgang Beck

= --_000_900A1E2059ADB149B905E3C8FA0046A62C80400CCFFHDP1LUMXC7V2_-- From richard@shockey.us Fri Nov 8 06:49:42 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA98221E819C for ; Fri, 8 Nov 2013 06:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.982 X-Spam-Level: X-Spam-Status: No, score=-99.982 tagged_above=-999 required=5 tests=[AWL=-1.782, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZmipDS86OCM for ; Fri, 8 Nov 2013 06:49:38 -0800 (PST) Received: from alt-proxy19.mail.unifiedlayer.com (unknown [69.89.20.141]) by ietfa.amsl.com (Postfix) with SMTP id E045D21E8191 for ; Fri, 8 Nov 2013 06:49:37 -0800 (PST) Received: (qmail 21898 invoked by uid 0); 8 Nov 2013 14:49:33 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy19.mail.unifiedlayer.com with SMTP; 8 Nov 2013 14:49:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=ahDV+Q+UAWSebUCNRwUUkgZjYPnNcqOUhZ0+/rifg7I=; b=H4ixdGkGr2iDfDclA91b4Y9Aek4gPrGtbsrMzoBShdG+24LUplflnOmV6jd6o54IkrB4Ld7CQMoJ7j2XWKI73PzedLMMXsmBQ+199aNzuKrqbBSY3N6yztaniZG60YlS; Received: from [173.79.179.104] (port=49483 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VenNN-00075s-Gf; Fri, 08 Nov 2013 07:49:33 -0700 From: "Richard Shockey" To: "'Wolfgang Beck'" , "'Mishra, Sanjay'" References: <596979554D802045BBD45C051A4399E40D40C829@STNTEXMB10.cis.neustar.com> <900A1E2059ADB149B905E3C8FA0046A62C80400CB6@FHDP1LUMXC7V23.us.one.verizon.com> In-Reply-To: Date: Fri, 8 Nov 2013 09:49:31 -0500 Message-ID: <009701cedc91$bc624ad0$3526e070$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01CEDC67.D38DF080" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKJkVni1CgZfEhNhwwii2hW92z01wIPECgdAcg6h7qYh0ZE0A== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: stir@ietf.org, 'Jon Peterson' Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 14:49:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0098_01CEDC67.D38DF080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Exactly and we all know what happened to that idea. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Wolfgang Beck Sent: Thursday, November 07, 2013 9:02 PM To: Mishra, Sanjay Cc: stir@ietf.org; Jon Peterson Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' The two are completely different things, but use a similar mechanism to verify e164 numbers. VIPR was an attempt to replicate the telcos' number databases into a P2P DB that would be filled by making calls through the phone network. The idea was that one day all numbers would be in the P2P DB and calls through the phone network would rarely be necessary. Am 07.11.2013 16:36 schrieb "Mishra, Sanjay" >: Wolfgang, Jon - Is the reference below is for "VIPR" is as in the voice service offered by "VIBER" or is the reference here is to "Verification Involving PSTN Reachability (VIPR)? It sounds to me Woffgang is referencing VIBER but I can be wrong. Sanjay From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org ] On Behalf Of Peterson, Jon Sent: Thursday, November 07, 2013 4:24 PM To: 'Wolfgang Beck' Cc: 'stir@ietf.org ' Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?' Those verification systems like VIPR and Whatsapp are reliable only in so far as their call signaling goes exclusively through the PSTN - the DYPTC method wouldn't go over SS7 unfortunately. Jon Peterson Neustar, Inc. Sent with Good (www.good.com ) -----Original Message----- From: Wolfgang Beck [wolfgang.beck01@googlemail.com ] Sent: Thursday, November 07, 2013 07:12 PM Eastern Standard Time To: Peterson, Jon Cc: stir@ietf.org Subject: RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' VIPR, whatsapp, iMessage all use the phone network for verification. Public ENUM registrars used it. The principle seems to be working for sufficiently large number of cases. Am 07.11.2013 14:38 schrieb "Peterson, Jon" >: I believe that SIP messages routed to telephone numbers today are mostly frequently dropped to the PSTN, and may eventually re-enter the Internet or not. In cases where requests targeting telephone numbers do travel end-to-end over the Internet, various flat files and private databases are consulted to forward requests hop-by-hop until they reach a destination. The relationships of those mechanisms to numbering authorities can be tenuous today, precisely because of the absence of the authority architecture this working group is considering. There's no free lunch here. Jon Peterson Neustar, Inc. Sent with Good (www.good.com ) -----Original Message----- From: Wolfgang Beck [wolfgang.beck01@googlemail.com ] Sent: Thursday, November 07, 2013 05:23 PM Eastern Standard Time To: Peterson, Jon Cc: stir@ietf.org Subject: RE: [stir] new SIP Method DYPTC 'Did You Place This Call?' Would you agree that such a SIP message would arrive at an element of a party that has delegated the number to its current user? Solving the problem 'who owns this number?' seems easier to me inside the system than in a separate one. Am 07.11.2013 13:26 schrieb "Peterson, Jon" >: Various "callback" mechanisms along these lines have been considered, and there are known limitations of these mechanisms, most of which result from the fact that placing a call from a number does not guarantee that a returned call would reach the same endpoint instance. Gateways, call centers, users with multiple concurrently registered devices, all of our "doctor's office" use cases and related configurations show why approaches along these lines are insufficient. Jon Peterson Neustar, inc. Sent with Good (www.good.com ) -----Original Message----- From: Wolfgang Beck [wolfgang.beck01@googlemail.com ] Sent: Thursday, November 07, 2013 04:18 PM Eastern Standard Time To: stir@ietf.org Subject: [stir] new SIP Method DYPTC 'Did You Place This Call?' Here's a half-baked idea: when a call c1 arives from , I send a DYPTC SIP request message outside of this call back to . The DYPTC request carries some headers that describe c1, eg. the original from and to. - if the receiving UA is indeed , it responds with 200 OK. The origin of call c1 is now verified. - if was spoofed by somebody, the request will arrive at a UA that does not know about the call described by DYPTC. It responds with 404 Not Found - if was spoofed and there is no UA reachable, the request will time out or the network will generate a 404 Not found. Whenever I dont receive a 200 OK on a DYPTC, the calling number could not be verified. So far all methods to determine a party that can verify a number seem to boil down to one of the two groups: 1. create a new database, replicated from the telcos' databases, that can be accessed by end devices. That's what iMessage, whatsapp, and VIPR try to do. Accurately replicating a fairly dynamic database without its cooperation is a challenge. 2. create a way so that end devices can directly query the telcos' databases. DNS is an obvious candidate for this. However, accessing the database itself is not enough. The end device would have to replicate all routing decisions the telcos make. All discussions about PBXs and number portability are essentially about the routing inside the telcos. Why not just use the existing platform to verify calling numbers? Wolfgang Beck ------=_NextPart_000_0098_01CEDC67.D38DF080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Exactly and we all know what happened to that idea. =

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Wolfgang Beck
Sent: Thursday, November 07, 2013 9:02 = PM
To: Mishra, Sanjay
Cc: stir@ietf.org; Jon = Peterson
Subject: Re: [stir] new SIP Method DYPTC 'Did You = Place This Call?'

 

The two are completely = different things, but use a similar mechanism to verify e164 numbers. = VIPR was an attempt to replicate the telcos' number databases into a P2P = DB that would be filled by making calls through the phone network. The = idea was that one day all numbers would be in the P2P DB and calls = through the phone network would rarely be necessary.  =

Am 07.11.2013 16:36 schrieb = "Mishra, Sanjay" <sanjay.mishra@verizon.com&g= t;:

Wolfgang, Jon – Is the reference below is for =  “VIPR” is as in the voice service offered by = “VIBER” or is the reference here is to “Verification = Involving PSTN Reachability (VIPR)?

 

It sounds to me Woffgang is referencing VIBER but I can be = wrong.

 

Sanjay

 

From:= = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Peterson, Jon
Sent: Thursday, November 07, 2013 4:24 = PM
To: 'Wolfgang Beck'
Cc: 'stir@ietf.org'
Subject: Re: [stir] new = SIP Method DYPTC 'Did You Place This = Call?'

 <= /o:p>

Those = verification systems like VIPR and Whatsapp are reliable only in so far = as their call signaling goes exclusively through the PSTN - the DYPTC = method wouldn't go over SS7 unfortunately.

Jon = Peterson
Neustar, Inc.



Sent with Good (www.good.com)


-----Original = Message-----
From: Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent: Thursday, November 07, 2013 07:12 PM Eastern Standard = Time
To: Peterson, Jon
Cc: stir@ietf.org
Subject: RE: [stir] = new SIP Method DYPTC 'Did You Place This Call?'

VIPR, = whatsapp, iMessage all use the phone network for verification. Public = ENUM registrars used it. The principle seems to be working for = sufficiently large number of cases.

Am = 07.11.2013 14:38 schrieb "Peterson, Jon" <jon.peterson@neustar.biz>:


I believe = that SIP messages routed to telephone numbers today are mostly = frequently dropped to the PSTN, and may eventually re-enter the Internet = or not. In cases where requests targeting telephone numbers do travel = end-to-end over the Internet, various flat files and private databases = are consulted to forward requests hop-by-hop until they reach a = destination. The relationships of those mechanisms to numbering = authorities can be tenuous today, precisely because of the absence of = the authority architecture this working group is = considering.

There's no free lunch here.

Jon = Peterson
Neustar, Inc.



Sent with Good (www.good.com)


-----Original = Message-----
From: Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent: Thursday, November 07, 2013 05:23 PM Eastern Standard = Time
To: Peterson, Jon
Cc: stir@ietf.org
Subject: RE: [stir] = new SIP Method DYPTC 'Did You Place This Call?'

Would = you agree that such a SIP message would arrive at an element of a party = that has delegated the number to its current user? Solving the problem = 'who owns this number?' seems easier to me inside the system than in a = separate one.

Am = 07.11.2013 13:26 schrieb "Peterson, Jon" <jon.peterson@neustar.biz>:

Various = "callback" mechanisms along these lines have been considered, = and there are known limitations of these mechanisms, most of which = result from the fact that placing a call from a number does not = guarantee that a returned call would reach the same endpoint instance. = Gateways, call centers, users with multiple concurrently registered = devices, all of our "doctor's office" use cases and related = configurations show why approaches along these lines are = insufficient.

Jon Peterson
Neustar, inc.



Sent = with Good (www.good.com)


-----Original = Message-----
From: Wolfgang Beck [wolfgang.beck01@googlemail.com]
Sent: Thursday, November 07, 2013 04:18 PM Eastern Standard = Time
To: stir@ietf.org
Subject: [stir] new = SIP Method DYPTC 'Did You Place This = Call?'

Here's a = half-baked idea: when a call c1 arives from <a>, I send a DYPTC = SIP request message outside of this call back to <a>. The DYPTC = request carries some headers that describe c1, eg. the original from and = to.


- if = the receiving UA is indeed <a>, it responds with 200 OK. The = origin of call c1 is now verified.


- if = <a> was spoofed by somebody, the request will arrive at a UA that = does not know about the call described by DYPTC. It responds with 404 = Not Found


- if = <a> was spoofed and there is no UA reachable, the request will = time out or the network will generate a 404 Not = found.

Whenever I = dont receive a 200 OK on a DYPTC, the calling number could not be = verified.

 <= /o:p>

So far all = methods to determine a party that can verify a number seem to boil down = to one of the two groups:

1. create a new = database, replicated from the telcos' databases, that can be accessed by = end devices. That's what iMessage, whatsapp, and VIPR try to do. = Accurately replicating a fairly dynamic database without its cooperation = is a challenge.

2. create a way = so that end devices can directly query the telcos' databases. DNS is an = obvious candidate for this.

However, = accessing the database itself is not enough. The end device would have = to replicate all routing decisions the telcos make. All discussions = about PBXs and number portability are essentially about the routing = inside the telcos.

Why not just use = the existing platform to verify calling numbers?


Wolfgang= = Beck

------=_NextPart_000_0098_01CEDC67.D38DF080-- From rjsparks@nostrum.com Tue Nov 12 09:23:43 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D0C11E80FE for ; Tue, 12 Nov 2013 09:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-2BTljgw7iu for ; Tue, 12 Nov 2013 09:23:40 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5710421F9FA3 for ; Tue, 12 Nov 2013 09:23:37 -0800 (PST) Received: from unnumerable.local (pool-173-57-89-224.dllstx.fios.verizon.net [173.57.89.224]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rACHNad8003590 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Tue, 12 Nov 2013 11:23:36 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <52826418.9010009@nostrum.com> Date: Tue, 12 Nov 2013 11:23:36 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: stir@ietf.org Content-Type: multipart/mixed; boundary="------------080707050602020105070702" Received-SPF: pass (shaman.nostrum.com: 173.57.89.224 is authenticated by a trusted mechanism) Subject: [stir] Draft Minutes: STIR at IETF88 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:23:44 -0000 This is a multi-part message in MIME format. --------------080707050602020105070702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please send corrections to the list or the chairs ASAP: RjS --------------080707050602020105070702 Content-Type: text/plain; charset=UTF-8; name="stir-ietf88-draft-minutes.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="stir-ietf88-draft-minutes.txt" Minutes: STIR at IETF 88 Summary: We had a good discussion refining our understanding of requirements. We were pressed for time, and did not complete the agenda for our second session. Notable elements from the discussion: * A discussion of the problems related to call-forwarding will be added to the problem statement; * Discussion of applications like ViPR, iMessage, etc. will remain in the problem statement, but the text will be adjusted to reflect list discussion; * When discussing a more refined definition of in-band and out-of-band, there was a preference in the room for defining in-band to mean within the control protocol that sets up the media; * There is a preference to limit the number of bytes the solution adds to in-band messages, but no strong agreement on what that limit should be; * There was strong consensus to include an extension point in the solution to allow optional assertions to be made about other signaling elements; and * There was desire to support both delegation from above and proof of possession as enrollment models. We had two notetakers at each session. Session one: Shida Shubert and Jean Mahoney Session two: Dean Willis and Jean Mahoney Their notes appear below: ======================================================================== Session One: Notetaker: Jean Mahoney IETF-88 stir Tuesday, 5 November 2013: 1300-1400, Regency D ======================================================================== 10m Chairs/Administrivia Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-0.pptx Jabber Scribe - Dan York Jabber logs: Session One: http://www.ietf.org/jabber/logs/stir/2013-11-06.html Session Two: http://www.ietf.org/jabber/logs/stir/2013-11-07.html Note takers - Jean Mahoney and Shida Schubert Note well presented. Agenda presented. Robert Sparks asked Hadriel Kaplan about the status of the wiki version of draft-kaplan-stir-fried for the working group. It is still under development. ======================================================================== 20m Problem statement - Jon Peterson http://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-1.pptx Jon Peterson presented slides 1-7. Jon and Hadriel discussed the problem with call forwarding, which is legitimate and needs to be supported but allows ends to become malicious middles. ACTION: Add text to draft-ietf-stir-problem-statement discussing the call forwarding problem. slide - VIPR and iMessage No one on the room had issues with updating the draft with Andrew Allen's and Jon's updates. ACTION: Jon to incorporate Andrew Allen's text and Jon's followup into draft-ietf-stir-problem-statement. There was a discussion about whether VIPR should be referenced in the document. Although Martin Dolly and Hadriel didn't want much or any text referencing VIPR, since it may cause confusion, in the end the room decided that the text could stay. ACTION: Do not remove VIPR text from the draft. slide - Distinctions, distinctions Jon's tentative proposal for in-band and out-of-band definitions received pushback from Hadriel and Martin. Martin offered an alternate definition. A hum was taken on the two definitions and whether the room could live with either. There was a slight preference for the in-band definition to mean the control plane protocol that sets up the media, although many didn't care. ACTION: update in-band definition to mean control protocol that sets up the media. slide - More Open Issues There was a discussion about UDP bounds. Hadriel pointed out SBCs will delete SIP headers to reduce the size of the messages and larger messages would be less likely to make it end-to-end. Hadriel also did not want to move to TCP to make STIR work. Andrew Allen said the system has to support UDP. Eric Rescola mentioned that the smallest signing algorithms are patented. Steve Kent said there were lessons to learn from TLS and IKE on caching and fragmentation. Cullen described packet loss with size and that it was not linear, but a series of plateaus. He recommended keeping below the second plateau of 8K. ======================================================================== 30m Threats - Jon Peterson http://datatracker.ietf.org/doc/draft-ietf-stir-threats/ Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-1.pptx John presented slides 8-14. Robert asked who had read the draft. Many had. Of those who had not, many indicated that they would. Brian Rosen recommended not including threats against the solutions in this draft. ======================================================================== Session one: Notetaker: Shida Shubert WG : STIR Date : 2013.11.05 ******************************** 1). Agenda Bash - No ojbections. ******************************** 2). Problem Statement Presented by : Jon Peterson Slide : http://www.ietf.org/proceedings/88/slides/slides-88-stir-1.pptx Draft : draft-ietf-stir-problem-statement-00.txt * Text surrounding call forwarding - Can't distinguish legitimate and non-legitimate Call forwarding. (Hadriel Kaplan) We need to support call-forwarding BUT it breaks the solution.. - While admitting the problem exists we need to solve what we can. (Cullen Jennings) Conclusion / Action Item: Will add some text about the call-forwarding. (Jon Peterson) * Text surrounding ViPR / iMessage - The utltimate problem of solving what the target is, is difficult - Don't want to dwell into these iMessage/ViPR discussions. (Eric Rescola) - Not meant to propose any solutions, just an informational reference. (Jon Peterson) - Cullen and I are trying to finish ViPR, the end-result is the statement of why we failed. - Should have a privacy section with reference to ViPR. (Martin Dolly) - Has very little to with STIR problem. (Hadriel Kaplan) - Do you want to point to any other works that remotely tried to address the problem space? (Jon Peterson) - Used the PSTN, there is bunch of specs in ITU-T. (Hadriel Kaplan) - Feels like advertising ViPR. (Hadriel Kaplan) - It wasn't trying to solve the STIR problem. (Hadriel Kaplan) - It was trying to solve the SPIT problem, it tried to solve the subset of the problem. (Cullen Jennings) - Explained how VIPR tried to use the PSTN to ascertain the origin identity. (Jon Peterson) - It's standard practice to reference what we have done in the past. (Eric Rescola) - Can't we just explain that it was a big failure.. Why take it out? (Eric Rescola) - Because people who don't attend IETF read it, may get the wrong idea, I don't have an issue personally... (Hadriel Kaplan) Conclusion : It's fine to leave the text.. * In-band means SIP / Out-of-band means everything else - Debate over what the definition of in-band and out-of-band is. - Need something that clarifies the definitions. (Jon Peterson) - Out-of-band is signaling can't carry any definition that references the certificate/credential. (Eric Rescola) - In-band is it's in the call-control signaling, out-of-band is, it's not. (Martin Dolly) - As soon as it touches PSTN, it's an out-of-band. (Cullen Jennings) - If SIP stuff is done first and other stuff is done later, I am okay with the definition. (Brian Rosen) - By the time something is deployable, use of PSTN is going to be so miniscule that the cost/effort doesn't make sense. (Martin Dolly) - Oppose to the definition you have.. Any call-control-signaling is in-band.. (Hadriel Kaplan) - Hesitant to decouple it too much from SIP. (Jon Peterson) - It's always good to constraint the first work to do. (Brian Rosen) - I think we should take the Martin's definition. (Martin Dolly) HUM: 1. In the control protocol that sets up the media. 2. In SIP. 3. Don't care? Observation : Slightly more hum for 1. * How much message overhead are we willing to tolerate - Is add under 1K reasonable? (Cullen Jennings) - This allows us to eliminate some potential solution. (Cullen Jennings) - Agreed, this will limit some type of solution. (Hadriel Kaplan) - I think we need to keep it lower than 1K. (Hadriel Kaplan) - It rules out of carrying the credential itself. (Jon Peterson) - I thought it was ruled out a month ago. (Hadriel Kaplan) - Minimum size for keying material is 700K, with mata-data etc it's over 1K. (Eric Rescola) - System needs to be updated anyway to support this, so it will be fine if the system needs to support TCP. (Andrew Allen) - In order for the header to be kept when going through SBC, I suggested the smaller bytes. It wasn't about the problem with FW or NATs.. (Hadriel Kaplan) - Regarding the transport, this will not be a big enough feature for the carriers to move to TCP. I don't want that to be the barrier to have this deployed.. (Hadriel Kaplan) Conclusion : No clear consensus.. Limit needs to be set seems to be a consensus among the people at the mic. ******************************** 3). Threat document Slide : http://www.ietf.org/proceedings/88/slides/slides-88-stir-1.pptx Draft : draft-ietf-stir-threats-00.txt Issue : Should it include threats against the solution? - Don't do it in this draft. (Brian Rosen) * Regarding MitM - We can't protect against MiTM because we have valid intermedaries and we can't distinguish good one from another. (Hadriel Kaplan) - We will have the discussion about how we can extend the protocol to do this tomorrow. (Jon Peterson) Time's up. ======================================================================== Session two: Notetaker: Jean Mahoney IETF-88 stir Wednesday, 6 November 2013, 1550-1720, Georgia B ======================================================================== 5m Administrivia Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-0.pptx Jabber scribe: Ben Campbell Jabber logs: Session One: http://www.ietf.org/jabber/logs/stir/2013-11-06.html Session Two: http://www.ietf.org/jabber/logs/stir/2013-11-07.html Note takers: Jean Mahoney and Dean Willis Note well presented. Agenda bashing - No changes to the agenda. ======================================================================== 25m Constraints on signature construction and validation: Jon Peterson - what fields are included in the signature? - should that list be configurable? Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-2.pptx Cullen Jennings presented. Martin Dolly pointed out that the To header is changed in toll-free calls. Jon said that there would be use cases where this would not work. Hadriel Kaplan thought that this would break across domains most of the time because header fields are modified. And since it would break, it would not be deployed. Martin Dolly believed it would cause interoperability issues. Cullen said that this was an extensibility option. Dave Crocker said that this mechanism was almost a copy of DKIM but not quite. Cullen said that DKIM allowed flexibility for the sender but not the recipient. Jon said that DKIM and 4474 had different actors. Jon Peterson said that this was the only story that we have for encryption. Robert Sparks took a hum on including a tool to make assertions extensible. There were hums in the room, and no one was opposed. There was a discussion about whether the From header should be used. [Name not captured] said that mobile operators toss the From header and use PAI or PPI. Cullen and Jon said that was against RFCs. Martin said that in the United States, the FCC would just put something out for comment on whether the From should be signed. Martin didn't think it would be deployed if the FCC insisted that the From be signed. Eric Rescola wanted a statement about behavior when a From corresponds to a signature and behavior when it doesn't. Hadriel wanted this to work like Caller ID. Brian Rosen wanted some text about verifying enterprises that don't have E.164 equivalence. Eric Burger wanted to know if anyone had implemented RFC 4474. Jon said that they had created test implementations. =========================================================================== 40m Credential Acquisition: Jon Peterson and Hadriel Kaplan - how can signers and verifiers obtain the appropriate credentials? - what does a verifier need to access credentials (a number, a number range, some other hint)? - is access to the credentials public or private? - are credentials associated with a single number, a range, or an arbitrary set? Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-3.pptx Jon Peterson presented. Martin did not think that 'proof of possession' could be deployed earlier than carrier delegation. Cullen agreed that was the case for black phones, but companies like Google could roll out 'proof of possession' within two weeks. Cullen thought that both 'proof of possession' and delegation were needed. Jon thought that pressure in the marketplace would help carriers clarify how they want to position themselves with regard to identity. Martin said that there were privacy implications on opening up dialer apps. Eric Rescola said that dialer apps were easy to update but there were security questions. Eric Burger suggested that we ask the FCC. Jon pushed for modularity since there will be different requirements from different nation states. Jon asked the room if there opposition againt proof of possession. There was no opposition. Leif Johanson brought up OAuth as a delegation model. Jon asked him to send the idea to the list. Hadriel said that OAuth didn't fit because you are authorizing someone else to use your identity. You may be offline, and the delegate may be using the identity for months. Brian Rosen wanted to know how delegation would be implemented. Dave Crocker pointed out that DKIM has delegation. Richard asked that Hadriel put the delegation proposal on the list. ACTION: Discuss delegation models and implementation on the list. There was discussion about credentials for ranges. It was agreed that one credential per number was not a requirement. That there needed to be flexibility to handle discontiguous blocks. [Name not captured] wondered how number portability affected credentials. Jon thought that maybe a credential with a level of indirection would be useful. Martin recommended that in addition to identifying the originating party, passing information on who authenticated the originating party. Dave mentioned that Hadriel's original DKIM proposal covered credentials for ranges. Hadriel requested more time for the working group at the London meeting. Hadriel wanted to push out the Push method for acquiring credentials. Cullen said it didn't have to be decided today. Hadriel pointed out that if the database is publicly accessible, the carrier records could not be revealed because it would reveal company sensitive information. ======================================================================== 20m Gatewaying: Hadriel Kaplan - what constraints do we have on signature construction so that the signature is likely to survive transition through other protocols (can we build something that can be passed through UUI?) Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-4.ppt Hadriel Kaplan presented. Presentation was cut short due to time constraints. Brian was in favor of making it work. However, he wasn't sure what could make it through SS7. Martin didn't think it needed to be part of the base. It could be put in a user-user parameter. Martin also cautioned that the tech for PSTN gateways was developed in the 90s, and he was not sure the code could be touched. Hadriel said that SBCs could deal with this before it reached the gateway. End of meeting. ============================================================================ Session two: Notetaker: Dean Willis STIR IETF 88 Robert Sparks, Russ Housley Chairing 1550, 20131106, Vancouver BC Hyatt, Georgia B (Session 2) Note Well presented Agenda accepted as previously published Topic: STIR Signaling, Cullen Jennings Slides presented First principles (separation of signaling and enrollment) agreed by room. Issue: Signature Fields Martin Dolly notes that issue with To signing includes 800-number translation problem. John Peterson noted that all the high-level translation cases that affect To are quite probably in breach of the protocol. There may be no easy answer. Issue: Additional Protection Question: Is it the sender, or the recipient that verifies the signature? — Recipient, who also needs the credentials. Question: What happens when the Identity-Reliance header in the signature mismatches with the received call? What does it mean if it ALWAYS mismatches? - The service provider verifier has the option on what they want to check wrt I-R header. Hadriel suspects it will seldom survive intact in production so why bother? It might be a waste of time. Paul Kyzivat notes that this mechanism will work in some cases, so it can be used where needed. Hadriel continues to worry that this will create an obstacle for baseline deployment. Question: What does this protect against? — A call apparently comes from one person, and is really from another. But isn’t that the base function? — Yes, this is an extensibility point. Question: Since this is like DKIM, why did we break the fields out differently? Everything in DKIM is in the DKIM signature itself. — It seems harder to for the receiver to match the fields. But there are DKIM libraries that could be re-used, if they matched. Noted that its this way for matching to RFC 4474. John Peterson also noted that R-I could be used for verifying keying material, when media keying material is included in signaling, and that its the only story for such verification. Martin Dolly suggests that we need extensibility, but putting something in here thats going to get dropped is going to make for failures. Alternative: We could include the DTLS-SRTP fingerprint and other fields ALWAYS in the signature set if they are present in the request. Poll of the room: (loosely phrased) Do we want a point of extensibility that will optionally protect other signaling elements by linking them to identity? Major consensus. Issue: Canonicalization Question: Where should the source of identity be encoded? From, PAI, elsewhere? Noted that PAI may be suppressed in transit and not presented to end user. Noted that proposed rules treat number@domain identities differently from user@domain. Noted that some carriers do it differently. Question: How do we canonicalize? Eventually, the FCC is going to put out something for comment. Noted that what is being proposed here will not align with what is likely to be proposed to FCC by telephone carriers. Proposed that we do roughly what we did with ENUM. EKR notes this is all broken. Two possibilities ;either the From matches the signature, or it doesnt. We could move the verifier problem from the signaling to the lookup function. Martin notes that for calls originating from enterprises, the number typically gets majorly modified. But Hadriel notes that the fact that caller-ID gets delivered today is proof that the information is in there somewhere. Keith asks: In an enterprise, which number are you verifying? The lead? The DID? The extension? Brian Rosen notes that we will need some story for enterprises that do not have E.164 equivalents. Issue: Should STIR replace RFC 4474? - Proposed yes. Question: Does anybody implement RFC 4474 and care? — Probably not... Topic: Requirements Discussion, Jon Peterson Slides presented Issue: Enrollment, How do signers get credentials (two alternatives discussed, delegation vs proof of possession) Suggested that this isnt a first-tier problem. Jon answers that there are two potential credential systems under consideration. Selection between proposed alternatives will drive that choice. Noted that different carriers have conflicting positions here. Proposed that dialer application will be carrier driven. Eric Burger notes that the FCC is going to drive this, so we should just ask them what they want. Jon believes that different regulators will insist on each. Eric Rescorla notes that some phones have HTML5 dialers. Issue: Delegation Requirements Martin Dolly suggests that there are two major categories of temporary delegation; carrier knows, carrier doesnt know that is, delegation outside of carrier authority. There are also cross-carrier cases. Noted that we already have a very good delegation model in DNS, and that the doctors office model doesnt fit in there. Brian reminds us of the issues from PERPASS. How is this going to get implemented and used? We need to make it not a nightmare. Hadriel reports having looked at OAUTH for this a while back, and it didn't fit. Dave Crocker noted that the issue of delegation and the variety of ways in which people do delegation also has an along in DKIM. Its easy in DKIM because domain names are hierarchically scoped. Point is, theres an established base of experience and we should think about using it. Issue: Req: Credentials for Ranges Proposal that we dont have one one credential per each number; need some sort of aggregation system. Question: What is the question that the IETF needs to address? We need to explore how we deal with number ranges and aggregations of credentials. Suggested by Martin Dolly that neither extreme makes sense. Noted by Chris that it should be flexible; different sections of number allocations might need different key rotation policies, but having large ranges of numbers tied to a single key is not a problem. Question about number portability: this tends to break up ranges. A lot. This will lead to a need for real-time validation of credential scope. Test by ludicrous delegation proposed by RJS. Would we get things like delegating even numbers to A, odd numbers to B? Or should we restrict ourselves to disjoint sets of contiguous numbers? The latter seems to be preferred. Martin Dolly notes that typically a service provider will typically have a bunch of different certificates, and that there may be a back link to who did the authentication. Noted by Dan, a reseller, that they get completely discontiguous assignments, and dont want to have to track a credential each. Dave Crocker reminds us of the DKIM selector expression; an attribute under the name. We should look at this again. Noted by Chris that this illustrates the beauty of the domain name system. Issue: Expiry, Revocation, and Rollover No debate. Issue: Signer Provisioning No debate. Issue: Verifier Credential Acquisition Note to give Hadriel extra time in London. Push-vs-pull discussion deferred. Issue: Which credentials do verifiers need? Some debate, no conclusion. Issue: Public or Confidential database Some debate, no conclusion. Could always query the PSTN ... Topic: STIR In-Band Signature Transport, Hadriel Kaplan Slides presented (no time for all of the slides) Issue: Do we want anything besides SIP, like XMPP, SS7, H.323, etc. Noted that out of band is also a choice. Brian Rosen speaks in favor of making it work. Comes down to what can get through the SS7 network. Martin Dolly doesnt think it needs to be part of the base. Touching the gateway code base is really hard. But we could do it in SBCs ... ======================================================================== --------------080707050602020105070702-- From philippe.fouquart@orange.com Mon Nov 25 07:23:44 2013 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 11D071AD947 for ; Mon, 25 Nov 2013 07:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 mG-pzRRlKSrn for ; Mon, 25 Nov 2013 07:23:40 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id A06791AD8F1 for ; Mon, 25 Nov 2013 07:23:40 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 115673B4290; Mon, 25 Nov 2013 16:23:40 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id E8B2A384095; Mon, 25 Nov 2013 16:23:39 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 25 Nov 2013 16:23:39 +0100 From: To: "Peterson, Jon" Thread-Topic: [stir] I-D Action: draft-ietf-stir-threats-00.txt Thread-Index: AQHOx7y/JJVHKtdzVU+u1z4FVY7WRJo2N9qg Date: Mon, 25 Nov 2013 15:23:39 +0000 Message-ID: <14231_1385393020_52936B7B_14231_18433_3_B5939C6860701C49AA39C5DA5189448B11094351@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20131011233433.16052.66127.idtracker@ietfa.amsl.com> In-Reply-To: <20131011233433.16052.66127.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.25.14814 Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-00.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: Mon, 25 Nov 2013 15:23:44 -0000 Jon, Apologies for belated comments on this.=20 > 1. Introduction and Scope > [...] >therefore they impersonate numbers that are not > assigned to them. Being picky: maybe add "or unassigned."=20 > [...] > 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 te= nd to use for numbers instead).=20 > [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.=20 > 3.1. Voicemail Hacking via Impersonation=20 > >A voicemail service allows users calling from their mobile phones > access to their voicemail boxes on the basis of the calling party > number.=20=20=20 Section 3.1 seems to be focused on the most common case:=20 a) users accessing the mobile voicemail, and=20 b) users doing so only with their own phone. For a), it seems to me that this section also applies to non-mobile voicema= ils - including broadband voip voicemails. Maybe you want to remove "mobile= " in the first sentence. BB voicemails may actually be an interesting in-ne= t use case for this. For b) I was wondering whether the exclusion of remote access was deliberat= e: for most providers, users can actually check their voicemails calling wi= th a a phone different from their own, generally through dialling their reg= ular 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.=20 Maybe remote access shouldn't be included but if this is meant to be out of= scope, the text should probably say so.=20 > 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 wo= uldn't be uncommon to send a ring back tone to the caller during those nece= ssary 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: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Saturday, October 12, 2013 1:35 AM To: i-d-announce@ietf.org Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-threats-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Telephone Identity Revisited Worki= ng 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 stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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.