From richard@shockey.us Sat Nov 2 14:46:40 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC77921E80EE 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 j15ZEA+G0DOF for ; Sat, 2 Nov 2013 14:46:40 -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 D8BD021E80B7 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: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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 richard@shockey.us Wed Nov 6 05:29:59 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3F911E81B7 for ; Wed, 6 Nov 2013 05:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.268, 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 yKy0diDI9mtc for ; Wed, 6 Nov 2013 05:29:54 -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 5798F11E8197 for ; Wed, 6 Nov 2013 05:29:50 -0800 (PST) Received: (qmail 4313 invoked by uid 0); 6 Nov 2013 13:29:27 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.mail.unifiedlayer.com with SMTP; 6 Nov 2013 13:29:27 -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=iBKIyZwiZBuC+2IulKm6PETGDrpBlVIbwAoDJ7F8Cdw=; b=LokQUecljfhNnVQXiHNV9cWYomkuWo0kFv14nDEswKoz1/qbyjUVD6Ak9bcgLtbDjtlVxdE7KoTpN9L4yK1F9cKuU5+5zzGrVR7Vis/Eo5CjpXVr580XmEpYHyMJZshI; Received: from [173.79.179.104] (port=49307 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ve3Ak-0005mt-5k; Wed, 06 Nov 2013 06:29:26 -0700 From: "Richard Shockey" To: "'Dan York'" References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net>, <020a01ced680$caf4ec90$60dec5b0$@shockey.us> In-Reply-To: Date: Wed, 6 Nov 2013 08:29:24 -0500 Message-ID: <013b01cedaf4$367b2ac0$a3718040$@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: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjAB5gRUxAqM7HPqXlW65MA== 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: cnit@ietf.org, 'DISPATCH' , 'Brian Rosen' Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 13:29:59 -0000 -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Dan York Sent: Thursday, October 31, 2013 8:24 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH; Brian Rosen Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications Richard, > On Oct 31, 2013, at 5:34 PM, "Richard Shockey" wrote: > > I am very interested in working on improving caller name. > > [RS> ] So I'm not completely insane? :-) Welllllll... we can debate that! ;-) But... If you are insane then a number of us are because I, too, am interested in working on this. > Ok then it seams the > conversation is worth having and there is productive work here .. I will admit that when we started working on STIR, I had it in my head that when we talking about "secure origin identification" we were talking about BOTH the phone number and the displayed caller name. I don't think securing ONLY the phone number fully helps regular users, because the regular person out there usually looks at (and trusts!) the displayed "Caller ID". If we secure the phone number but not the display name, attackers/spammers are simply going to figure out ways to send a valid phone number but a confusing display name. Sure, the secured phone number may help track the attacker down, but in the meantime victims have been fooled into giving up information. [RS> ] I agree. We will have to do both eventually. So I think we have to look at how we secure both. > See you in > London. Why London? Are you not in Vancouver? Or were you just saying this is post-Vancouver work? [RS> ] Obviously not enough time to organize a Goals and Requirements or a draft charter etc. I'm not in Vancouver. Its something to properly organize and present in London. Dan _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From richard@shockey.us Wed Nov 6 13:11:16 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AE221E81C3 for ; Wed, 6 Nov 2013 13:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.184 X-Spam-Level: X-Spam-Status: No, score=-102.184 tagged_above=-999 required=5 tests=[AWL=0.414, 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 NI8LiognVT4w for ; Wed, 6 Nov 2013 13:11:07 -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 DDB9D21E8198 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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:11:16 -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:23 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1688D11E8152 for ; Wed, 6 Nov 2013 21:59:23 -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 H640pwRy1Pp4 for ; Wed, 6 Nov 2013 21:59:18 -0800 (PST) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9140011E813A for ; Wed, 6 Nov 2013 21:59:15 -0800 (PST) Received: by mail-qe0-f44.google.com with SMTP id 6so72105qeb.17 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=m+wUlpGMoetI6lJXZCLP0jNOlbEDtRa84LVMHJSYtHB1xUOfngcCSshlzNDGGR960l jVk0MIbUm7vvO/pa8HGAGyQQ7PBdLf7JbU6FedtSpJRZpnSgng74u+sFvlP4fNNHqnaj TDPHWlxQBeYxO4wgY4GvwMgLBhuirrkCVAQgAqPk/oZjz3UAKF09ob+BUK7x6f88IbIu EJzBamfABex4+cya6gi+iDYVk0RWczeCrc7pifHo3C0Uz/ipFU8Y0CLzN7YL0eH+2c+3 O4Tv78rxlQDe8C7qR2DIhJcK0cruZ39S8Hf/C/rpDDT8wlXd/NKrEY8NLn4dYvjaYA4u ae2A== X-Gm-Message-State: ALoCoQly2DyFxJChpnjDHKnGHcfW+4Z9i9fm/6oO6M5c2ThVLc/XSjq/NYDP7CYbwY4aA1BkH49X 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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 05:59:23 -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: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0165421E82A2 for ; Thu, 7 Nov 2013 07:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.143 X-Spam-Level: X-Spam-Status: No, score=-101.143 tagged_above=-999 required=5 tests=[AWL=-0.649, 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 yYji5BENwUFm 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 A52E521E82A5 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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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:44 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8441921E81ED for ; Thu, 7 Nov 2013 09:03:44 -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 3QBoUnNGEeZt for ; Thu, 7 Nov 2013 09:03:40 -0800 (PST) Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by ietfa.amsl.com (Postfix) with ESMTP id C608121E81D1 for ; Thu, 7 Nov 2013 09:03:33 -0800 (PST) Received: by mail-bk0-f41.google.com with SMTP id na10so414679bkb.0 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=OWydjC2EXyHwg7vVBRMmHZjoFY+Yd0Wngza1WST44mZxQexVFB+lDa7XKyAhBQd/0n mEOZnF/Vjag7U5KmsAaTTKbAFOnNKu3k4PCKL5XYIghYFBaELZjrOp7Y6hEg2gorAa1k Sno6cMumQexhCbv1iePt9cYwsso/abTrk5s99fdBL+jI1ES17Ejm+6wYc3kG3qIATH0S mmVbSSNxbte/a/93LYk4rGJndkmUp6EB/fTQYQPNVhLBuwJFvp8a3s0lmRVaovvu+2QY z3wOuskeKlgqifHm4E213tSozQD0LXNML+JLnkgUp3HNmJuUZnM9WrIUn5g47oIPOjOE iCCA== X-Gm-Message-State: ALoCoQmiawM+12zx+sXhWumFXly2awB1Czq0YLHe2+iLczhpqxrhtgNketTRp4MaSo33P84WojmV 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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:03:44 -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: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B874A21E81EA 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 49BGzXi+t+NR for ; Thu, 7 Nov 2013 09:10:47 -0800 (PST) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by ietfa.amsl.com (Postfix) with ESMTP id 07B2F21E820F for ; Thu, 7 Nov 2013 09:10:24 -0800 (PST) Received: by mail-bk0-f46.google.com with SMTP id e11so357164bkh.33 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=A6pvAf3a//Ogx3SFa+I9/FjiUF9GTGBbgCAxYOKIOT6o1WKClQ77qwLPX3Q1oyC/pV 0dzjUAuHgS7eeolhm1qe2+yaI8eIk0c227sJq1So/0pAZXyXd5iIL0jCE8928qMzio4N B5f0pMAYCmkC5L1ifTGq659DeceZcaZ8ySR64Bg+Asg8fxSedEsHdfk89pGJvY3rka5t 6150zJ4A420lci6gr8P2C5QkkBv/y8Y7mwPXudXoAYtmVj5vQQ9i6K3TmK5A/6SMp+9J t1ey7u/bDOa0qmiYO3IAIBq2zc3Mu28rcrlgm2lHThC6cqa26I+UhhUB5pbgUOE931nd QicQ== X-Gm-Message-State: ALoCoQlJAETjb95+rvfThq8R2AkhJ8GUPFo1J6IYScmau3lwAH4yKwkT3tQwLLPIjEXxrgcoiwQQ 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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D1511E8261 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=[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 bSVwKDMBEdyz for ; Thu, 7 Nov 2013 09:14:57 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A88E21E81D1 for ; Thu, 7 Nov 2013 09:14:56 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id mx11so355392bkb.31 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=AOCJ1gQY+txG7vx4yHaGYJe2xq9DKPHzynzVjft8jdYItjviJnfdRBjEMRG31/UjIh ebrPUGFsvZyaT6mzFLbXmiSa96Y5bxTBGwmznvzMulvLgzxG6SIrM7rlrl5TKJVw8RWW by9z1TqoG81YFqzAdAXA0rraNSRIL/EtoLLOKRnOSk6WkZ6QbRsnAEE62PjeY1aWeAVX u0OrvjG0RLOlAM3bHPbHnXogG8vreJIAofJ7BokdBifwzI5qz/4/ayRL62opnf/6Bbr3 huwp2YZxAE4WNXhhc8r0ctF+hHQwrhbTkS63tGG0jVCmv3gvj8nmRsLm3xF7a0KndAaS 6uKQ== X-Gm-Message-State: ALoCoQk0ajjuaGSt7x5mQhkKdCRDXQHRs027taz/IlB7Vdii0JiMyQ3bQc2uK8iCyPpwYqR/UMZZ 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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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 kent@bbn.com Thu Nov 7 09:18:46 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABB721E811D for ; Thu, 7 Nov 2013 09:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.063, 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 ZPKhK5HQx26g for ; Thu, 7 Nov 2013 09:18:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 563A121F9343 for ; Thu, 7 Nov 2013 09:18:26 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:34104 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VeTDs-000Glx-At for cnit@ietf.org; Thu, 07 Nov 2013 12:18:24 -0500 Message-ID: <527BCB5F.1080001@bbn.com> Date: Thu, 07 Nov 2013 12:18:23 -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: cnit@ietf.org 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: Content-Type: multipart/alternative; boundary="------------020501010107010508000703" Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:18:46 -0000 This is a multi-part message in MIME format. --------------020501010107010508000703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Henning, > 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. > The tricky part is ensuring that a certificate (using the term broadly) issued by some organization is not interpreted by relying parties as meaning more than it should. It is not clear to me that most entities are good choices for the binding of a name to a phone number. In part this is because these entities do not consider the phone number to be a critical aspect of the attributes for which they vouch. My dentist's diploma is valid irrespective of the location (much less the phone number) for his office. BTW, as the geographic boundaries for area code change, phone numbers change. My home didn't move and it took a while for many of the records held by other parties to be updated. So, no, I would not rely on many parties of the sort you seem to suggest, to issue a credential binding my name to a phone nmber Steve --------------020501010107010508000703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Henning,

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.

The tricky part is ensuring that a certificate (using the term broadly) issued by some
organization is not interpreted by relying parties as meaning more than it should.

It is not clear to me that most entities are good choices for the binding of a name
to a phone number. In part this is because these entities do not consider the phone
number to be a critical aspect of the attributes for which they vouch.

My dentist's diploma is valid irrespective of the location (much less the phone number)
for his office. BTW, as the geographic boundaries for area code change, phone numbers
change. My home didn't move and it took a while for many of the records held by other
parties to be updated. So, no, I would not rely on many parties of the sort you seem to suggest,
to issue a credential binding my name to a phone nmber

Steve
--------------020501010107010508000703-- From michael.hammer@yaanatech.com Thu Nov 7 09:21:44 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list 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 br@brianrosen.net Thu Nov 7 09:36:47 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FCB11E818D for ; Thu, 7 Nov 2013 09:36:47 -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 UqPcHLbWyP09 for ; Thu, 7 Nov 2013 09:36:43 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id D752E11E8149 for ; Thu, 7 Nov 2013 09:36:42 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id k18so698308qcv.24 for ; Thu, 07 Nov 2013 09:36:39 -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=x5uzqivUQfvyBiDhdBdIj6Oje9NxSD5KA+jXAlf+7nQ=; b=jdbDtoiXWdpDJtD6J/bMwLi04ct7YIfZHnrLre/eUAvP63Whmz9GeXAM1K/kcCgIku wiQ9RjzggW22m1LpjJ7z6ohv2Y7D/Sks4D/eo+7UMH19O4DRxfxs0aOeV2d4Lp8uSAhy g3bGcEdG5/9Q6OmNg/7Lk4m4QRdcDitLPs6BfoiIpv1XObJVzoVFlA7EOQpghPlogOpq FP79kWkgAZXfL0j4UtibHI1bpDJ67ZgY/wJmEFhdkZq8kvDniLlrmHkAAYcrkCZQ5uyZ 2gyqY8k5KITGGy+Btw/Ll97Xx2uSVPuCKTLEFPPehif5IMCVYkWSIHWyxySTr9Mu/oYI SO6Q== X-Gm-Message-State: ALoCoQk0yRH05fIYT7xPRI7QaVvOW0w/mqDlFTRP338GrvJr1ToAKtQulF6YrA4+8j8ywaOvzHK8 X-Received: by 10.49.17.98 with SMTP id n2mr14928353qed.61.1383845799482; Thu, 07 Nov 2013 09:36:39 -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 r5sm9638671qeh.1.2013.11.07.09.36.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 09:36:38 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BD7413B8-CF2E-46DB-BB3E-FFC9F29C022E" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: <527BCB5F.1080001@bbn.com> Date: Thu, 7 Nov 2013 09:36:34 -0800 Message-Id: <2E8BE11E-4010-4BFE-9FD1-3ABE04E2265B@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> <527BCB5F.1080001@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1816) Cc: cnit@ietf.org Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:36:47 -0000 --Apple-Mail=_BD7413B8-CF2E-46DB-BB3E-FFC9F29C022E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes, but we might be able to thread certification of various aspects to = a single identity that we can use to coalesce the information. That identity COULD be the phone number (using proof of possession), but = I suspect that isn=92t quite enough. Brian On Nov 7, 2013, at 9:18 AM, Stephen Kent wrote: > Henning, >=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. > The tricky part is ensuring that a certificate (using the term = broadly) issued by some > organization is not interpreted by relying parties as meaning more = than it should. >=20 > It is not clear to me that most entities are good choices for the = binding of a name > to a phone number. In part this is because these entities do not = consider the phone > number to be a critical aspect of the attributes for which they vouch. >=20 > My dentist's diploma is valid irrespective of the location (much less = the phone number) > for his office. BTW, as the geographic boundaries for area code = change, phone numbers > change. My home didn't move and it took a while for many of the = records held by other=20 > parties to be updated. So, no, I would not rely on many parties of the = sort you seem to suggest, > to issue a credential binding my name to a phone nmber >=20 > Steve > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit --Apple-Mail=_BD7413B8-CF2E-46DB-BB3E-FFC9F29C022E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes, = but we might be able to thread certification of various aspects to a = single identity that we can use to coalesce the = information.

That identity COULD be the phone number = (using proof of possession), but I suspect that isn=92t quite = enough.

Brian


Henning,

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.
The = tricky part is ensuring that a certificate (using the term broadly) = issued by some
organization is not interpreted by relying parties as = meaning more than it should.

It is not clear to me that most = entities are good choices for the binding of a name
to a phone = number. In part this is because these entities do not consider the = phone
number to be a critical aspect of the attributes for which they = vouch.

My dentist's diploma is valid irrespective of the location = (much less the phone number)
for his office. BTW, as the geographic = boundaries for area code change, phone numbers
change. My home didn't = move and it took a while for many of the records held by other 
parties to be updated. = So, no, I would not rely on many parties of the sort you seem to = suggest,
to issue a credential binding my name to a phone = nmber

Steve
_______________________________________________
c= nit mailing list
cnit@ietf.org
https://www.ietf.org/mailman/listinfo/cnit

= --Apple-Mail=_BD7413B8-CF2E-46DB-BB3E-FFC9F29C022E-- From Pierce.Gorman@sprint.com Thu Nov 7 10:40:53 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:40:56 -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 kent@bbn.com Thu Nov 7 10:44:58 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAA921E8233 for ; Thu, 7 Nov 2013 10:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 7u7Zdc1M2gAu for ; Thu, 7 Nov 2013 10:44:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8E82E21E820C for ; Thu, 7 Nov 2013 10:43:35 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:33833 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VeUY7-000HnQ-Du; Thu, 07 Nov 2013 13:43:23 -0500 Message-ID: <527BDF4A.8050008@bbn.com> Date: Thu, 07 Nov 2013 13:43:22 -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: 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> <527BCB5F.1080001@bbn.com> <2E8BE11E-4010-4BFE-9FD1-3ABE04E2265B@brianrosen.net> In-Reply-To: <2E8BE11E-4010-4BFE-9FD1-3ABE04E2265B@brianrosen.net> Content-Type: multipart/alternative; boundary="------------050605090400020607040300" Cc: cnit@ietf.org Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:44:59 -0000 This is a multi-part message in MIME format. --------------050605090400020607040300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > Yes, but we might be able to thread certification of various aspects > to a single identity that we can use to coalesce the information. > > That identity COULD be the phone number (using proof of possession), > but I suspect that isn't quite enough. The approach you suggest is used by various folks to establish identity, in several contexts. It's often viewed as "good enough" but it is also vulnerable to folks who want to game a system for fraud. What constitutes "good enough" is very much function of the value to an attacker if the system can be subverted. I'm a bit more comfortable with the group-level assertion that Henning later suggested, for groups where we believe the motivation to impersonate is high. But, I question how well the folks who manage the databases for these groups do their job wrt this piece of data. And, if they elect to outsource the generation of credentials, e.g., certificates, a whole new set of vulnerabilities will be introduced. Steve --------------050605090400020607040300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

Yes, but we might be able to thread certification of various aspects to a single identity that we can use to coalesce the information.

That identity COULD be the phone number (using proof of possession), but I suspect that isn’t quite enough.
The approach you suggest is used by various folks to establish identity, in several contexts.

It's often viewed as "good enough" but it is also vulnerable to folks who want to game
a system for fraud. What constitutes "good enough" is very much function of the value
to an attacker if the system can be subverted.

I'm a bit more comfortable with the group-level assertion that Henning later suggested, for
groups where we believe the motivation to impersonate is high. But, I question how well
the folks who manage the databases for these groups do their job wrt this piece of
data. And, if they elect to outsource the generation of credentials, e.g., certificates,
a whole new set of vulnerabilities will be introduced.

Steve
--------------050605090400020607040300-- From Henning.Schulzrinne@fcc.gov Thu Nov 7 10:52:01 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF5211E8118 for ; Thu, 7 Nov 2013 10:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 M4bLATvKnG0B for ; Thu, 7 Nov 2013 10:51:56 -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 A75BA21E8132 for ; Thu, 7 Nov 2013 10:51:54 -0800 (PST) Message-ID: From: Henning Schulzrinne To: 'Stephen Kent' , Brian Rosen Thread-Topic: [cnit] [stir] draft-peterson-stir-threats-00.txt Thread-Index: AQHO28lBm7MQs/E/Y0C8yrTGiGFz45oZ21rggAB7noCAAAUVAIAAEqoA//+tHeA= Date: Thu, 7 Nov 2013 18:51:53 +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> <527BCB5F.1080001@bbn.com> <2E8BE11E-4010-4BFE-9FD1-3ABE04E2265B@brianrosen.net> <527BDF4A.8050008@bbn.com> In-Reply-To: <527BDF4A.8050008@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D01FC23C3Dp2pxmb13fccnetw_" MIME-Version: 1.0 Cc: "cnit@ietf.org" Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:52:01 -0000 --_000_E6A16181E5FD2F46B962315BB05962D01FC23C3Dp2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm sure somebody has managed to pretend to be a licensed financial institu= tion and is a fraud (see Madoff), but my main objective is to raise the bar= . If some dicey charity has to convince a state registrar that they are leg= it, that's a significant hurdle. Plus, after the first few fraud attempts, = they'd likely be blacklisted immediately. Plus, they'd be committing fraud = along the way, which has much higher (and criminal) penalties than just rob= ocalling. Also, there is a feedback loop - after NJ had issued a bunch of d= river's licenses based on bribery, the press coverage got the governor's at= tention. I suspect that headlines of "State licensed charity defrauded gran= dmothers" would similarly yield results. From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Ste= phen Kent Sent: Thursday, November 07, 2013 1:43 PM To: Brian Rosen Cc: cnit@ietf.org Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt Brian, Yes, but we might be able to thread certification of various aspects to a s= ingle identity that we can use to coalesce the information. That identity COULD be the phone number (using proof of possession), but I = suspect that isn't quite enough. The approach you suggest is used by various folks to establish identity, in= several contexts. It's often viewed as "good enough" but it is also vulnerable to folks who w= ant to game a system for fraud. What constitutes "good enough" is very much function of= the value to an attacker if the system can be subverted. I'm a bit more comfortable with the group-level assertion that Henning late= r suggested, for groups where we believe the motivation to impersonate is high. But, I quest= ion how well the folks who manage the databases for these groups do their job wrt this p= iece of data. And, if they elect to outsource the generation of credentials, e.g., = certificates, a whole new set of vulnerabilities will be introduced. Steve --_000_E6A16181E5FD2F46B962315BB05962D01FC23C3Dp2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m sure somebody h= as managed to pretend to be a licensed financial institution and is a fraud= (see Madoff), but my main objective is to raise the bar. If some dicey charity has to convince a state registrar that they are legit, that&= #8217;s a significant hurdle. Plus, after the first few fraud attempts, the= y’d likely be blacklisted immediately. Plus, they’d be committi= ng fraud along the way, which has much higher (and criminal) penalties than just robocalling. Also, there is a feedback loop = – after NJ had issued a bunch of driver’s licenses based on bri= bery, the press coverage got the governor’s attention. I suspect that= headlines of “State licensed charity defrauded grandmothers” would similarly yield results.

 <= /p>

From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.o= rg] On Behalf Of Stephen Kent
Sent: Thursday, November 07, 2013 1:43 PM
To: Brian Rosen
Cc: cnit@ietf.org
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

 

Brian,


Yes, but we might be able to thread certification of= various aspects to a single identity that we can use to coalesce the infor= mation.

 

That identity COULD be the phone number (using proof= of possession), but I suspect that isn’t quite enough.

The approach you suggest is used by various folks to= establish identity, in several contexts.

It's often viewed as "good enough" but it is also vulnerable to f= olks who want to game
a system for fraud. What constitutes "good enough" is very much f= unction of the value
to an attacker if the system can be subverted.

I'm a bit more comfortable with the group-level assertion that Henning late= r suggested, for
groups where we believe the motivation to impersonate is high. But, I quest= ion how well
the folks who manage the databases for these groups do their job wrt this p= iece of
data. And, if they elect to outsource the generation of credentials, e.g., = certificates,
a whole new set of vulnerabilities will be introduced.

Steve

--_000_E6A16181E5FD2F46B962315BB05962D01FC23C3Dp2pxmb13fccnetw_-- From br@brianrosen.net Thu Nov 7 11:02:55 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ED721E8219 for ; Thu, 7 Nov 2013 11:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 wsLF-pB-192h for ; Thu, 7 Nov 2013 11:02:50 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 743B011E825F for ; Thu, 7 Nov 2013 11:01:10 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id hu16so817253qab.11 for ; Thu, 07 Nov 2013 11:00:56 -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:content-transfer-encoding:message-id:references :to; bh=PKWdAukfMJKGmbaDSa5zhS6/5hj/9nqruUGiYbkk6dE=; b=SImFFgdYTKO3LX7rQBcjTmAannTLz2clEx62CqnO6wOieqrg+7IDSvMIPF+6OELzIm w7Hm0m98DuCpP5tk6YoeogBeMvm1v4764gOXsYOTK4cIWOKRWc+TBrCnGt0qZJQ5WNqK eWd/BbkKVFtUhD6LtTS+e1BqYy4zwDk7jgbrw56RPEJ/YZW4eurFxc2PRzpcL1WHSh+m 2/Q+tCFhUyqsTj0e8wRRjPQFbeR9THb3eBNxIYsUu+p1latzLV/uypvOFu6+pegZM+re lLhg/alwuUc/n+Lu4AmvssCkZI0g1fG2Flh/dL/LLKhC0xkfyNOj5Yp293m3+/IyLx6m hGww== X-Gm-Message-State: ALoCoQm7qQ6gLPJW7vsgjuke1Sqgq+O+0ZiYMwyCVQESrSk6YY+1vjrPV7n4dnmPWKoR3ldxFdSS X-Received: by 10.49.95.233 with SMTP id dn9mr15607093qeb.54.1383850856353; Thu, 07 Nov 2013 11:00:56 -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 k2sm12888107qan.8.2013.11.07.11.00.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 11:00:55 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: <527BDF4A.8050008@bbn.com> Date: Thu, 7 Nov 2013 11:00:51 -0800 Content-Transfer-Encoding: quoted-printable 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> <527BCB5F.1080001@bbn.com> <2E8BE11E-4010-4BFE-9FD1-3ABE04E2265B@brianrosen.net> <527BDF4A.8050008@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1816) Cc: cnit@ietf.org Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:02:55 -0000 Okay, so my wife is a Social Worker, and there is the National = Association of Social Workers who accredits social workers, and there is = a state licensing board that licenses social workers. NASW is always looking for value-add programs, for example, they offer a = liability insurance program for members. So, let=92s say the Federal Trade Commission sets up a CA, and issues a = cert to NASW. Let=92s say NASW offers to issue a signed assertion that = my wife is an accredited social worker associated with her telephone = number. To do so, she goes to the NASW web site, signs up, and clicks = =93call to confirm=94. Her office phone rings, and an IVR asks her to = enter (via DTMF) the confirmation code displaying on her screen. She = then gets an email that has an attachment, which is some blob signed by = NASW with a cert traceable to the FTC. She forwards the email, with the = attachment, to her carrier, say Verizon. The email address at Verizon = is an automaton which lifts the attachment and stores it. Since it = contains the phone number, they know what to associate the blob with. When a client gets a call from her on their smartphone, it contains her = name, and =93Social Worker=94 on the display. Details of how the blob = gets retrieved by the validator need to be worked out. Is this breakable? Sure. NASW has a pretty conventional = username/password scheme, which could be compromised. Someone has to = provide the code to do the signing, although we could pretty easily open = source what is needed for every such organization. Carriers need code = to lift the attachment and store it. But it seems to me to be eminently doable. Brian On Nov 7, 2013, at 10:43 AM, Stephen Kent wrote: > Brian, >=20 >> Yes, but we might be able to thread certification of various aspects = to a single identity that we can use to coalesce the information. >>=20 >> That identity COULD be the phone number (using proof of possession), = but I suspect that isn=92t quite enough. > The approach you suggest is used by various folks to establish = identity, in several contexts. >=20 > It's often viewed as "good enough" but it is also vulnerable to folks = who want to game > a system for fraud. What constitutes "good enough" is very much = function of the value > to an attacker if the system can be subverted. >=20 > I'm a bit more comfortable with the group-level assertion that Henning = later suggested, for > groups where we believe the motivation to impersonate is high. But, I = question how well > the folks who manage the databases for these groups do their job wrt = this piece of > data. And, if they elect to outsource the generation of credentials, = e.g., certificates, > a whole new set of vulnerabilities will be introduced. >=20 > Steve From richard@shockey.us Thu Nov 7 15:33:34 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E587D21E818B for ; Thu, 7 Nov 2013 15:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.007 X-Spam-Level: X-Spam-Status: No, score=-102.007 tagged_above=-999 required=5 tests=[AWL=0.257, 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 hO9G+Ek7rMOv for ; Thu, 7 Nov 2013 15:33:24 -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 EE7FD21E816F 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: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:33:35 -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 kent@bbn.com Fri Nov 8 10:08:03 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754BB11E81CF for ; Fri, 8 Nov 2013 10:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 tjFrjIGZfCve for ; Fri, 8 Nov 2013 10:07:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E164111E818D for ; Fri, 8 Nov 2013 10:07:50 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:50656 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VeqTF-0006Yw-Ax; Fri, 08 Nov 2013 13:07:49 -0500 Message-ID: <527D2876.8080501@bbn.com> Date: Fri, 08 Nov 2013 13:07:50 -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: 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> <527BCB5F.1080001@bbn.com> <2E8BE11E-4010-4BFE-9FD1-3ABE04E2265B@brianrosen.net> <527BDF4A.8050008@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: cnit@ietf.org Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 18:08:04 -0000 Brian, yes, what you described is doable. Will NASW do it, or will it hire some third party to do it, just as they work with an insurance company to offer policies to its members? I but the latter. In which case that third party will probably offer analogous services for a number of other organizations. There will be competing third parties that decide this is a good business, and thus offer the same services. Price (rather than security) will become a major factor in determining which third parties win the contracts. Since outsourcing will lower costs, eventually, this will be done by some folks in Elbonia. What could possibly go wrong ;-) ? Steve From kent@bbn.com Fri Nov 8 10:12:28 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92BD21E81DE for ; Fri, 8 Nov 2013 10:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 EQFWfcB7gJ6h for ; Fri, 8 Nov 2013 10:12:22 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CCCA321E81E4 for ; Fri, 8 Nov 2013 10:12:21 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:41449 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VeqXa-0002dw-8u; Fri, 08 Nov 2013 13:12:18 -0500 Message-ID: <527D2982.3090606@bbn.com> Date: Fri, 08 Nov 2013 13:12:18 -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: Henning Schulzrinne 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> <527BCB5F.1080001@bbn.com> <2E8BE11E-4010-4BFE-9FD1-3ABE04E2265B@brianrosen.net> <527BDF4A.8050008@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "cnit@ietf.org" Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 18:12:28 -0000 So the threat model is that bad guys will engage in fraud, but we believe that law enforcement will respond quickly enough, and impose sufficient penalties, so that the bad guys will not stay one jump ahead, and thus will be deterred. I can't argue that your model will prove to be wrong. It's a future scenario and the outcome is uncertain. I just want to understand what model folks have in mind when they propose solutions. Steve From br@brianrosen.net Fri Nov 8 10:19:05 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F2421E81CD for ; Fri, 8 Nov 2013 10:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.5 X-Spam-Level: X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 i--ldYymn3bq for ; Fri, 8 Nov 2013 10:19:00 -0800 (PST) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 318F121E81D5 for ; Fri, 8 Nov 2013 10:18:38 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id b4so2250149qen.6 for ; Fri, 08 Nov 2013 10:18:37 -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:content-transfer-encoding:message-id:references :to; bh=A5QlQ/a54j9DYLGmWAdVbc6/H56mcrlCcS9uu2EQa/A=; b=ZrhvR5HHXAXsPx4TNFB0O+wy1rhTGH/fiv9lx+bd4C/Zwa0kZZAk4PV+on4BwEoM3b XAg1vCLzH1aF3lwFlNfWwmEM2zC8V7IqHp5aKKYE2ZHg0FRZwa8DO/TLAevCj7mIHOvU +P+G5AybwEBSUdnqy0ArKfwDRgXmZABHXZkkZ4N6rHydcSu6HMaz0Zgu1Gl77OPQMhjq wNsiHZzrcz4hlUHuDx6xScw4wVaQ/K9LdfE+xLTJQgS3lNWoGSa1Fxl32bQeNleK5jlN n6WO33BLuEgA7IGGfExZoOLpwo9uew3Vmr23z1JlMpiB363B0PbtHlYMP5lZ7OyFjwmN /hDg== X-Gm-Message-State: ALoCoQnZxQvhhz3Wc06LvFNESWRx4Qoa073FN58Ttn67o33oxDLYR7sLPD9bRrh0GYsMkIbr7rxU X-Received: by 10.224.45.197 with SMTP id g5mr26698388qaf.2.1383934717638; Fri, 08 Nov 2013 10:18:37 -0800 (PST) Received: from [192.168.128.255] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id n7sm24826476qai.1.2013.11.08.10.18.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 10:18:37 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Brian Rosen In-Reply-To: <527D2876.8080501@bbn.com> Date: Fri, 8 Nov 2013 10:18:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2FCDE887-FF74-4DDA-9025-C597DB166BAF@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> <527BCB5F.1080001@bbn.com> <2E8BE11E-4010-4BFE-9FD1-3ABE04E2265B@brianrosen.net> <527BDF4A.8050008@bbn.com> <527D2876.8080501@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1822) Cc: cnit@ietf.org Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 18:19:06 -0000 I=92m going to take this response as =93good idea, let=92s do it=94 If I take it as face value, then no situation involving a contractor = with clue could ever work on any security problem. I suggested in another message that maybe a piece of FOSS would be = helpful for this. Brian On Nov 8, 2013, at 10:07 AM, Stephen Kent wrote: > Brian, >=20 > yes, what you described is doable. Will NASW do it, or will it hire = some third party > to do it, just as they work with an insurance company to offer = policies to its members? > I but the latter. In which case that third party will probably offer = analogous services > for a number of other organizations. There will be competing third = parties that > decide this is a good business, and thus offer the same services. = Price (rather than > security) will become a major factor in determining which third = parties win the contracts. > Since outsourcing will lower costs, eventually, this will be done by = some folks in > Elbonia. >=20 > What could possibly go wrong ;-) ? >=20 > Steve From kent@bbn.com Fri Nov 8 10:38:22 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E7621E811B for ; Fri, 8 Nov 2013 10:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 GL8hfVqfczqZ for ; Fri, 8 Nov 2013 10:38:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94A21E8099 for ; Fri, 8 Nov 2013 10:38:09 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:36652 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VeqwZ-0002xv-OG; Fri, 08 Nov 2013 13:38:07 -0500 Message-ID: <527D2F90.10805@bbn.com> Date: Fri, 08 Nov 2013 13:38:08 -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: 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> <527BCB5F.1080001@bbn.com> <2E8BE11E-4010-4BFE-9FD1-3ABE04E2265B@brianrosen.net> <527BDF4A.8050008@bbn.com> <527D2876.8080501@bbn.com> <2FCDE887-FF74-4DDA-9025-C597DB166BAF@brianrosen.net> In-Reply-To: <2FCDE887-FF74-4DDA-9025-C597DB166BAF@brianrosen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: cnit@ietf.org Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 18:38:22 -0000 Brian, > I’m going to take this response as “good idea, let’s do it” Rather think of it as establishing an "I told you so" landmark :-). > If I take it as face value, then no situation involving a contractor with clue could ever work on any security problem. That is not a valid inference from my example. What I said is that when authoritative entities outsource credential issuance and outsource providers focus on maximizing revenue opportunities, quality is sacrificed. Steve