Jon,<= o:p>

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

&nbs= p;

The primary attack vector is

therefore one where the att= acker 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 termi= nating side.

This might be misconstrued as indicating th= at 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.&nbs= p;

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

&nbs= p;

Regards,

Alex

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

> From: stir-bounces@i= etf.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, "P= eterson, Jon" <jon.peterson@neustar.biz>

> wrote:

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

> >

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

> >>

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

> [IMO,

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

> >

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

> > implemented in either endp= oints or in intermediaries of various kinds.

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

<= p class=3DMsoPlainText>> >

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

> a

&g= t; >> SIP INVITE or MESSAGE, which might contain stock market advice = even

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

> esta= blishment.

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

&g= t; >> telephony form more than voice session setup.

> >

> > Probably if we wer= e 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 p= rotocol, 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.&n= bsp; Replace 2nd sentence of 2nd paragraph of 1.0 Introduction = with:

> >>

&= gt; >> The primary attack vector is

> &= gt;> therefore one where the attacker contrives for the calling te= lephone

> >> 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 t= o remove the implication that the number will

&g= t; > 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 p= rimary attack vectors that concern us.

> >=

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

> >>

> >> Smart devices are gen= erally based on computers with some degree

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

> >> capabilities of rendering text, audio a= nd/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 atta= cker with an computer sends a high volume of SIP MESSAGE

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

> >> party numbers.

> >>

> >>= Countermeasure: in-band authenticated ident= ity

> >

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

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

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

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

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

>= ; document.

> >

> > Jon Peterson

> > Neustar, Inc.<= /p>

> >

> >&g= t; Regards,

> >>

> >> Alex

> >>

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

> >>> From: stir-bounces@ie= tf.org [mailto:stir-bounces@ietf.org<= /a>] On Behalf

> >>> Of Richard Shoc= key

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

> >>> To: 'DOLLY, MAR= TIN 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<= /p>

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

> >>>

> >>> Yes, ok

= > >>>

> >>> Martin Dolly=

> >>> Lead Member of Technical Staf= f

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

> &= gt;>> Technology

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

> >>> md3135@a= tt.com

> >>>

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

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

> >>> wrote:

> >>>&g= t;

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

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

> >>>> Hi Martin -

> >&= gt;>>

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

> >>>> on the

> >>&= gt; 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 n= o 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-bo= unces@ietf.org [mailto:stir-bounces@ietf.org= ] On

> >>>>> Behalf= Of Russ Housley

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

> >&= gt;>>> 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 mo= re people about this

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

> >>> hear from him soon.

> >>>>>

> >>>= ;>> Russ

> >>>>>

&g= t; >>>>>> 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 ad= opt this I-D as the starting point for

> >= >>>>> the

> >>> STIR = threat docuent?

> >>>>>>

> >>>>>> Russ

> >>>>> _____________________________________= __________

> >>>>> stir mailin= g list

> >>>>> sti= r@ietf.org

> >>>>> = https://www.ietf.org/mailman/listinfo/sti= r

> >>>>

> >>>> _____________________________________= __________

> >>>> stir mailing li= st

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

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

> >>> _____________________________= __________________

> >>> stir mailin= g list

> >>> stir@ietf.o= rg

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

> >>>

> &= gt;>> _______________________________________________

> >>> stir mailing list

= > >>> stir@ietf.org

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

> >&= gt; _______________________________________________

> >> stir mailing list

> >>= ; stir@ietf.org

> >= > https://www.ietf.org/mailman/listinf= o/stir

> >

> > _______________________________________________

> > stir mailing list

>= ; > stir@ietf.org

>= > https://www.ietf.org/mailman/listin= fo/stir

> _______________________________________________

> stir mailing list

> stir@ietf.org

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

<= /div>= --_000_4B1956260CD29F4A9622F00322FE05319381A907C4BOBO1Abobotek_-- From fmousinh@cisco.com Wed Oct 2 10:01:51 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE06A21F9E70 for ; Wed, 2 Oct 2013 10:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_COMPNY=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXqujKUrHYv2 for ; Wed, 2 Oct 2013 10:01:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ECF8721F9C05 for ; Wed, 2 Oct 2013 09:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15244; q=dns/txt; s=iport; t=1380733147; x=1381942747; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gq+wAFmhXtv/LqVNEaVmFEfZ6lrrq4mQ7io88EpMISA=; b=UKh6fBnvYSRZ/4PLSdJh1Rry6bLLExKyvvEhmi70Ko557SEWQrcSHX44 tZ1o3+GOl3dQme/Y5qPhODe8nzudRijiLTcZ2VCwgHdUYvT6WAwvpE0Ki 9v7Pa4T52JGLdVWSgOPlc/t9toz1YU1A0tUbY/UIVTitnCH90An1zHd6U E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALdPTFKtJXHB/2dsb2JhbABPAQYDgwc4UsEWgRgWdIIlAQEBBAEBAVYVCwwGAQgOAwEDAQEBCh0uCxQDBggCBA4FCBOHawy9CASODgEDBgWBAwYbEAcCBAuDDoEEA5QklVyDJIFoAgcXIg X-IronPort-AV: E=Sophos;i="4.90,1019,1371081600"; d="scan'208";a="267198140" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 02 Oct 2013 16:59:06 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r92Gx4kT009064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 16:59:04 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Wed, 2 Oct 2013 11:59:04 -0500 From: "Fernando Mousinho (fmousinh)" To: Brian Rosen Thread-Topic: [stir] Call Center Implications Thread-Index: AQHOs6wM4w3gYleEHUa5h7lxd4Kh+JnNbOEggAAiDICAAEzNAIAADeUAgAAA5QCAAANyAP//6DzSgABb64CAE5iwgA== Date: Wed, 2 Oct 2013 16:59:04 +0000 Message-ID: <71E3420F5D11314D8D989D8B72D247E129FE2079@xmb-aln-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.117.152.4] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Gregory.Schumacher@sprint.com" , Richard Shockey , "stir@ietf.org" , Alex Bobotek , Michael Hammer , Henning Schulzrinne Subject: Re: [stir] Call Center Implications X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:01:51 -0000 Point taken on PAI, but am still struggling with this BPO model. Apologies upfront if this is obvious and I'm just failing to understand. If the company hires several BPOs and authorizes all of them to sign calls on its behalf, is there a way to trace back the originator (specific BPO) later on? I suppose that at some level the actual caller must be exposed (perhaps to trace malicious activity, such as malicious person infiltrated in an otherwise legitimate BPO). Via headers would be the obvious pick, but they don't survive the plethora of SBCs that the call is likely to transverse. Or maybe the certs themselves can carry this type of data (actual caller identity). On 9/19/13 9:43 PM, "Brian Rosen" wrote: >Don't think that would work without related changes in the networks. In >some networks, PAI is used for called id. They would have to change to >use From (if signed maybe). It also doesn't fit the definition of PAI. > >Brian > >On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh) > wrote: > >> Could a signed PAI be a potential solution to the BPO use case? "From" >>identifies the BPO, "PAI" the c >>ompany hiring the BPO - based on the delegation process Rosen mentions. >>PAI's use is widespread, and it's main limitation is being spoofable - >>but this is exactly the problem we are trying to solve anyway. >>=20 >>=20 >>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey" >>>wrote: >>>=20 >>> Excellent point a profile or BCP to complement the work. >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>Of Alex >>> Bobotek >>> Sent: Thursday, September 19, 2013 5:27 PM >>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com; >>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Call Center Implications >>>=20 >>> +1 >>> I've assumed that we are headed towards a "sign whatever extras you >>>wish, >>> and indicate what your signature covers" mechanism. >>>=20 >>> Based on this, standards would need to identify only a minimal subset >>>of >>> what shall/should be signed, and ensure that any required group of >>>signed >>> items survives transit intact. >>>=20 >>> Best signing practices may be needed to complement the standard, and an >>> appropriate place for all but the most basic 'what to sign' >>>recommendations. >>>=20 >>>=20 >>>=20 >>> Regards, >>>=20 >>> Alex >>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>> Of Henning Schulzrinne >>>> Sent: Thursday, September 19, 2013 2:24 PM >>>> To: Michael Hammer; fmousinh@cisco.com; Gregory.Schumacher@sprint.com; >>>> br@brianrosen.net >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Call Center Implications >>>>=20 >>>> I see no reason not to allow signing any number-related field in the >>>> SIP request. (Signing may well be done by different parties.) >>>>=20 >>>> As far as I know, callback numbers (SIP Reply-To) aren't conveyable >>>>in=20 >>>> legacy systems, however, so this may be of somewhat limited use for a >>> while. >>>>=20 >>>> ________________________________________ >>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of >>>> Michael Hammer [michael.hammer@yaanatech.com] >>>> Sent: Thursday, September 19, 2013 4:34 PM >>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com; >>>> br@brianrosen.net >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Call Center Implications >>>>=20 >>>> Don't we still want to know the true originator of the call, even >>>>when=20 >>>> we have some token that says "Doctor so and so approved this message." >>>>=20 >>>> Originating number, display number, and call-back number could be 3 >>>> different things. >>>> Should all of them be verifiable? >>>>=20 >>>> Mike >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>> Of Fernando Mousinho (fmousinh) >>>> Sent: Thursday, September 19, 2013 4:00 PM >>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Call Center Implications >>>>=20 >>>> I believe the scenario telemarketing here is when a client hires a >>>>BPO=20 >>>> to place outbound calls, but expect customers to return these calls >>>>to=20 >>>> a different place (say, their own and operated call center). This >>>>way,=20 >>>> this client is authorizing the BPO to use an identity that it (BPO) >>> doesn't own. >>>> These numbers in this scenario are always operational, just at a >>>> different place. >>>>=20 >>>> The same telemarketing operator would then outpulse multiple numbers >>>> for their multiple clients, none of these numbers belonging to the >>> telemarketer. >>>> BTW, we are using the term "telemarketing" in a very generic sense - >>>> this could just as easily be a public service announcement, >>>>fundraiser, >>> etc. >>>>=20 >>>> If the telemarketer happens to own the inbound call center as well, >>>>it=20 >>>> very likely owns the number as well and this would necessarily be a >>>> special case >>>> - it would fall under the same characteristics of any call center. >>>>=20 >>>> On a different note, it would help a lot of we standardized >>>>terminology. >>>> Telemarketing, BPO, call center, end customer, clients=A9 it may be >>>>hard=20 >>>> for others to follow the discussion later. >>>>=20 >>>>=20 >>>>=20 >>>> (generic term for any type of outbound calling, including public >>>> service announcement, so don't think it's all about sales!) >>>>=20 >>>>=20 >>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>> wrote: >>>>=20 >>>>> There are some benefits from this approach, but also some scenarios >>>>> that need clarification how they could function. >>>>>=20 >>>>> The benefit is that the credential represents both the company >>>>> "responsible" for the sales campaign (the "company" in your >>>>>scenario)=20 >>>>> and the company operating the sales campaign (the call center in >>>>>your=20 >>>>> scenario). For the use in forensics (after the fact analysis) such >>>>> as pursuit of fraud investigation, we then can follow both paths. >>>>>=20 >>>>> However can you clarify the following - >>>>> - If a SP "signs" the call, is it attesting to the "responsible" >>>>> party for the telemarketing call or the party executing the >>>>> telemarketing campaign or both? >>>>>=20 >>>>> - How is the SP supposed to know all the parties that it is >>>>>attesting=20 >>>>> to >>>>> - the responsible party and/or executing party? >>>>>=20 >>>>> -It seems likely that some of the numbers assigned to a company in >>>>> your scenario will not be assigned to real telephones (or call >>>>>center=20 >>>>> trunk) until a telemarketing campaign is initiated or a call center >>>>> selected to execute the sales campaign, is it possible to have these >>>>> unassigned or floating numbers when not in use for a telemarketing >>>>> campaign? Is it allowed under most national numbering regimes? >>>>>=20 >>>>> - How important is it to have a known or recognized phone number as >>>>> the caller id as part of a telemarketing campaign? I am assuming >>>>> that not all campaigns care about having a number that is known or >>> recognized. >>>>>=20 >>>>> -In other words for this last bit, if a call center (telemarketing >>>>> campaign operator) is using their own set of numbers but serve >>>>> multiple simultaneous telemarketing campaigns using the same >>>>> originating numbers, what will they sign? Will they just have a >>>>> credential representing the call center alone, or a different >>>>> credential per telemarketing campaign, or a different credential per >>>>> responsible party (per client)? This will affect what is possible >>>>>for >>> any forensic activity. >>>>>=20 >>>>> -----Original Message----- >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>>> Of Brian Rosen >>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>> To: Fernando Mousinho >>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>> Subject: Re: [stir] Call Center Implications >>>>>=20 >>>>> We have a requirement to support the BPO use case. >>>>>=20 >>>>> The notion we had is that the company contracting the call center >>>>> approves the use, and the call center, or the SP acting on its >>>>> behalf, signs. >>>>> Think of this as another level of delegation. An SP delegates >>>>> numbers to the company. The company "delegates" use of those >>>>>numbers=20 >>>>> to the call center. The call center calls, using that delegation. >>>>> The credentials of the call center would be different from those of >>>>> the company, but would cover the same number. Having multiple >>>>> credentials covering the same number will be very common due to the >>>>> way delegation happens. In order to allow SPs to sign, without >>>>> creating credential per TN, we allow credentials with ranges. The >>>>> ranges could overlap when delegation happens. >>>>>=20 >>>>> Consider the following complex US case: >>>>> The North American Number Plan Administrator delegates 202-555-xxxx >>>>> to the Pooling Administrator. The PA now has a credential covering >>>>> the entire 10K block. >>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. SP A has >>>>>a=20 >>>>> credential for the entire 1K block SP A resells 202-555-12xx to SP B >>>>>. >>>>> SP B has a credential for a 100 TN block SP B delegates 202-555-123x >>>>> to Company C. Company C has a credential for a 10 number block >>>>> Company C authorizes 202-555-1234 to BPO D. BPO D has credential >>>>>for=20 >>>>> a 1 number block >>>>>=20 >>>>> NANPA and the PA never are in a call path, so they would never sign >>>>>a=20 >>>>> call. >>>>>=20 >>>>> However, SP A or SP B could sign a call from either Company C or BPO >>>>> D using the credential they have. >>>>>=20 >>>>> The SP for the call center could acquire credentials from the BPO >>>>>and=20 >>>>> sign on its behalf. I suspect than many service providers would be >>>>> reluctant to do so unless the numbers were from their own inventory >>>>> (that is, the company got its numbers from the same SP as the call >>> center). >>>>> Since that won't be the common case, the call center probably has to >>>>> do the signing itself. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh) >>>>> wrote: >>>>>=20 >>>>>> I agree, Hadriel. While large call centers (including BPOs, which >>>>>> provide services for other companies) may have special arrangements >>>>>> with SPs, the majority (small to mid-size) will probably rely on >>>>>> the SPs to do provide to vouch for their identity. This would >>>>>> probably be the case for the home analog caller anyway. This would >>>>>> imply that the "originating" SP's willingness to provide this >>>>>> signature is a critical success factor for the proposal's adoption. >>>>>>=20 >>>>>>=20 >>>>>> But back to the business process outsourcers (BPO) case - where a >>>>>> call center is providing service on behalf of multiple companies. I >>>>>> can see the value of them sending different numbers based on the >>>>>> clients they represent. Wouldn't that create a billing issue though? >>>>>> This is not an area I understand well, but I would suspect that SP >>>>>> 1 allowing one of its subscribers to send an outbound call using a >>>>>> number registered to SP 2 could be a no-no. If this hypothesis is >>>>>> correct, then we are back to the case where the SP is signing all >>>>>> calls, >>>> even for BPOs. >>>>>>=20 >>>>>> Or maybe this is another problem we are trying to fix in the >>>>>> working group, in which case we perhaps should state as a goal or >>> benefit: >>>>>> "providing a reliable mechanism to let calls originated from one >>>>>> SP1 to outpulse numbers that belong to another". >>>>>>=20 >>>>>> Fernando >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>> wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> Any of them could do it. My guess is service providers will do it >>>>>>> for most call centers, although larger call centers might do it >>>>>>> themselves... >>>>>>> especially ones which have trunks from multiple providers and can >>>>>>> source calls using the same number(s) out through multiple >>>>>>> providers on a call-by-call basis. >>>>>>>=20 >>>>>>> -hadriel >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh) >>>>>>> wrote: >>>>>>>=20 >>>>>>>> I'm catching up with the discussions in this working group, and >>>>>>>> am trying to understand some architecture implications in call >>>>>>>> centers (which is where my background is). It seems that many of >>>>>>>> the problems we are trying to fix are related to contact centers >>>>>>>> anyway, so it is probably a good idea to have everyone in the >>>>>>>> same >>>> page. >>>>>>>>=20 >>>>>>>> Forgive me if it is an obvious question, but which components in >>>>>>>> a "typical call center architecture" do you see signature and >>>>>>>> verification taking place? Such "typical" deployments have >>>>>>>> premises based equipment (PME), a session border controller (SBC) >>>>>>>> and of course a SIP service provider all three could potentially >>>>>>>> be used throughout the authorization process. There are different >>>>>>>> ramifications depending on where your mind is at. >>>>>>>>=20 >>>>>>>> Fernando Mousinho >>>>>>>> Cisco Systems >>>>>>=20 >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=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=20 >>>>> you are not the intended recipient, please contact the sender and >>>>> delete all copies of the message. >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>> _______________________________________________ >>>> 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 > From br@brianrosen.net Wed Oct 2 10:31:50 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081A121F9DC9 for ; Wed, 2 Oct 2013 10:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_COMPNY=2.3, 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 CuZhIIMK9BYe for ; Wed, 2 Oct 2013 10:31:39 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id BCB1521F9E85 for ; Wed, 2 Oct 2013 10:27:19 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db12so811899veb.22 for ; Wed, 02 Oct 2013 10:27:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=lKaBQiFugz+3R/Suqs5rquvsZHkb/gK/yHxv09k9roY=; b=V1+xVJLIFJQllk3OySqBUYwnI9xu7ihuzb0iuBdSrIb+2VJNZLw5KTGacDe8uKxOI1 /oSKhRN95+Z3awjHMN98k7pDlzX0gDvR3YAl5e7NJNOjm8LHx0ofFlF0jzLg1PC2S/wf kHIK+TYMMUql/Ae+wLuV1ISgG1LazpHh91RAO7bK8z7mRZQCNkUKRDa9WbTjjutBNG1X vq/LVFhMR5SMoXN9ncTH32VjXqubRzUzB64uOVr9M2C+H9Aq842auEcutqOa7fY8JiMA YqBe/vq4NBCgK4hjO74wiiiKCC7JdTjim/oEdnDBShYTSfFwuEt5qPysiQ7qkaeXS3sC +3yg== X-Gm-Message-State: ALoCoQl79GXvF92Y4ttgZnOilv2+FL8IiXQ5XYh35u5eSCy9V0hXNQcHNhYNo/em6IoSJG2pmZLW X-Received: by 10.52.65.136 with SMTP id x8mr2565776vds.23.1380734836674; Wed, 02 Oct 2013 10:27:16 -0700 (PDT) Received: from [10.33.193.37] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id gr8sm2486830vdc.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Oct 2013 10:27:15 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Brian Rosen In-Reply-To: <71E3420F5D11314D8D989D8B72D247E129FE2079@xmb-aln-x06.cisco.com> Date: Wed, 2 Oct 2013 13:27:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1B06BEFF-E7AC-4B30-B9D5-844E1192B4CB@brianrosen.net> References: <71E3420F5D11314D8D989D8B72D247E129FE2079@xmb-aln-x06.cisco.com> To: Fernando Mousinho (fmousinh) X-Mailer: Apple Mail (2.1508) Cc: "Gregory.Schumacher@sprint.com" , Richard Shockey , "stir@ietf.org" , Alex Bobotek , Michael Hammer , Henning Schulzrinne Subject: Re: [stir] Call Center Implications X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:31:50 -0000 Sure. Each BPO would have a different private/public key pair. So you can trace which one placed the call. Brian On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh) = wrote: > Point taken on PAI, but am still struggling with this BPO model. = Apologies > upfront if this is obvious and I'm just failing to understand. >=20 > If the company hires several BPOs and authorizes all of them to sign = calls > on its behalf, is there a way to trace back the originator (specific = BPO) > later on? I suppose that at some level the actual caller must be = exposed > (perhaps to trace malicious activity, such as malicious person = infiltrated > in an otherwise legitimate BPO). >=20 > Via headers would be the obvious pick, but they don't survive the = plethora > of SBCs that the call is likely to transverse. Or maybe the certs > themselves can carry this type of data (actual caller identity). >=20 >=20 >=20 >=20 > On 9/19/13 9:43 PM, "Brian Rosen" wrote: >=20 >> Don't think that would work without related changes in the networks. = In >> some networks, PAI is used for called id. They would have to change = to >> use =46rom (if signed maybe). It also doesn't fit the definition of = PAI. >>=20 >> Brian >>=20 >> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh) >> wrote: >>=20 >>> Could a signed PAI be a potential solution to the BPO use case? = "From" >>> identifies the BPO, "PAI" the c >>> ompany hiring the BPO - based on the delegation process Rosen = mentions. >>> PAI's use is widespread, and it's main limitation is being spoofable = - >>> but this is exactly the problem we are trying to solve anyway. >>>=20 >>>=20 >>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey" >>>> wrote: >>>>=20 >>>> Excellent point a profile or BCP to complement the work. >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf >>>> Of Alex >>>> Bobotek >>>> Sent: Thursday, September 19, 2013 5:27 PM >>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com; >>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Call Center Implications >>>>=20 >>>> +1 >>>> I've assumed that we are headed towards a "sign whatever extras you >>>> wish, >>>> and indicate what your signature covers" mechanism. >>>>=20 >>>> Based on this, standards would need to identify only a minimal = subset >>>> of >>>> what shall/should be signed, and ensure that any required group of >>>> signed >>>> items survives transit intact. >>>>=20 >>>> Best signing practices may be needed to complement the standard, = and an >>>> appropriate place for all but the most basic 'what to sign' >>>> recommendations. >>>>=20 >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Alex >>>>=20 >>>>> -----Original Message----- >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf >>>>> Of Henning Schulzrinne >>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>> To: Michael Hammer; fmousinh@cisco.com; = Gregory.Schumacher@sprint.com; >>>>> br@brianrosen.net >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Call Center Implications >>>>>=20 >>>>> I see no reason not to allow signing any number-related field in = the >>>>> SIP request. (Signing may well be done by different parties.) >>>>>=20 >>>>> As far as I know, callback numbers (SIP Reply-To) aren't = conveyable >>>>> in=20 >>>>> legacy systems, however, so this may be of somewhat limited use = for a >>>> while. >>>>>=20 >>>>> ________________________________________ >>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of >>>>> Michael Hammer [michael.hammer@yaanatech.com] >>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com; >>>>> br@brianrosen.net >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Call Center Implications >>>>>=20 >>>>> Don't we still want to know the true originator of the call, even >>>>> when=20 >>>>> we have some token that says "Doctor so and so approved this = message." >>>>>=20 >>>>> Originating number, display number, and call-back number could be = 3 >>>>> different things. >>>>> Should all of them be verifiable? >>>>>=20 >>>>> Mike >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf >>>>> Of Fernando Mousinho (fmousinh) >>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Call Center Implications >>>>>=20 >>>>> I believe the scenario telemarketing here is when a client hires a >>>>> BPO=20 >>>>> to place outbound calls, but expect customers to return these = calls >>>>> to=20 >>>>> a different place (say, their own and operated call center). This >>>>> way,=20 >>>>> this client is authorizing the BPO to use an identity that it = (BPO) >>>> doesn't own. >>>>> These numbers in this scenario are always operational, just at a >>>>> different place. >>>>>=20 >>>>> The same telemarketing operator would then outpulse multiple = numbers >>>>> for their multiple clients, none of these numbers belonging to the >>>> telemarketer. >>>>> BTW, we are using the term "telemarketing" in a very generic sense = - >>>>> this could just as easily be a public service announcement, >>>>> fundraiser, >>>> etc. >>>>>=20 >>>>> If the telemarketer happens to own the inbound call center as = well, >>>>> it=20 >>>>> very likely owns the number as well and this would necessarily be = a >>>>> special case >>>>> - it would fall under the same characteristics of any call center. >>>>>=20 >>>>> On a different note, it would help a lot of we standardized >>>>> terminology. >>>>> Telemarketing, BPO, call center, end customer, clients=A9 it may = be >>>>> hard=20 >>>>> for others to follow the discussion later. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> (generic term for any type of outbound calling, including public >>>>> service announcement, so don't think it's all about sales!) >>>>>=20 >>>>>=20 >>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>> wrote: >>>>>=20 >>>>>> There are some benefits from this approach, but also some = scenarios >>>>>> that need clarification how they could function. >>>>>>=20 >>>>>> The benefit is that the credential represents both the company >>>>>> "responsible" for the sales campaign (the "company" in your >>>>>> scenario)=20 >>>>>> and the company operating the sales campaign (the call center in >>>>>> your=20 >>>>>> scenario). For the use in forensics (after the fact analysis) = such >>>>>> as pursuit of fraud investigation, we then can follow both paths. >>>>>>=20 >>>>>> However can you clarify the following - >>>>>> - If a SP "signs" the call, is it attesting to the "responsible" >>>>>> party for the telemarketing call or the party executing the >>>>>> telemarketing campaign or both? >>>>>>=20 >>>>>> - How is the SP supposed to know all the parties that it is >>>>>> attesting=20 >>>>>> to >>>>>> - the responsible party and/or executing party? >>>>>>=20 >>>>>> -It seems likely that some of the numbers assigned to a company = in >>>>>> your scenario will not be assigned to real telephones (or call >>>>>> center=20 >>>>>> trunk) until a telemarketing campaign is initiated or a call = center >>>>>> selected to execute the sales campaign, is it possible to have = these >>>>>> unassigned or floating numbers when not in use for a = telemarketing >>>>>> campaign? Is it allowed under most national numbering regimes? >>>>>>=20 >>>>>> - How important is it to have a known or recognized phone number = as >>>>>> the caller id as part of a telemarketing campaign? I am assuming >>>>>> that not all campaigns care about having a number that is known = or >>>> recognized. >>>>>>=20 >>>>>> -In other words for this last bit, if a call center = (telemarketing >>>>>> campaign operator) is using their own set of numbers but serve >>>>>> multiple simultaneous telemarketing campaigns using the same >>>>>> originating numbers, what will they sign? Will they just have a >>>>>> credential representing the call center alone, or a different >>>>>> credential per telemarketing campaign, or a different credential = per >>>>>> responsible party (per client)? This will affect what is = possible >>>>>> for >>>> any forensic activity. >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf >>>>>> Of Brian Rosen >>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>> To: Fernando Mousinho >>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>> Subject: Re: [stir] Call Center Implications >>>>>>=20 >>>>>> We have a requirement to support the BPO use case. >>>>>>=20 >>>>>> The notion we had is that the company contracting the call center >>>>>> approves the use, and the call center, or the SP acting on its >>>>>> behalf, signs. >>>>>> Think of this as another level of delegation. An SP delegates >>>>>> numbers to the company. The company "delegates" use of those >>>>>> numbers=20 >>>>>> to the call center. The call center calls, using that = delegation. >>>>>> The credentials of the call center would be different from those = of >>>>>> the company, but would cover the same number. Having multiple >>>>>> credentials covering the same number will be very common due to = the >>>>>> way delegation happens. In order to allow SPs to sign, without >>>>>> creating credential per TN, we allow credentials with ranges. = The >>>>>> ranges could overlap when delegation happens. >>>>>>=20 >>>>>> Consider the following complex US case: >>>>>> The North American Number Plan Administrator delegates = 202-555-xxxx >>>>>> to the Pooling Administrator. The PA now has a credential = covering >>>>>> the entire 10K block. >>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. SP A = has >>>>>> a=20 >>>>>> credential for the entire 1K block SP A resells 202-555-12xx to = SP B >>>>>> . >>>>>> SP B has a credential for a 100 TN block SP B delegates = 202-555-123x >>>>>> to Company C. Company C has a credential for a 10 number block >>>>>> Company C authorizes 202-555-1234 to BPO D. BPO D has credential >>>>>> for=20 >>>>>> a 1 number block >>>>>>=20 >>>>>> NANPA and the PA never are in a call path, so they would never = sign >>>>>> a=20 >>>>>> call. >>>>>>=20 >>>>>> However, SP A or SP B could sign a call from either Company C or = BPO >>>>>> D using the credential they have. >>>>>>=20 >>>>>> The SP for the call center could acquire credentials from the BPO >>>>>> and=20 >>>>>> sign on its behalf. I suspect than many service providers would = be >>>>>> reluctant to do so unless the numbers were from their own = inventory >>>>>> (that is, the company got its numbers from the same SP as the = call >>>> center). >>>>>> Since that won't be the common case, the call center probably has = to >>>>>> do the signing itself. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh) >>>>>> wrote: >>>>>>=20 >>>>>>> I agree, Hadriel. While large call centers (including BPOs, = which >>>>>>> provide services for other companies) may have special = arrangements >>>>>>> with SPs, the majority (small to mid-size) will probably rely on >>>>>>> the SPs to do provide to vouch for their identity. This would >>>>>>> probably be the case for the home analog caller anyway. This = would >>>>>>> imply that the "originating" SP's willingness to provide this >>>>>>> signature is a critical success factor for the proposal's = adoption. >>>>>>>=20 >>>>>>>=20 >>>>>>> But back to the business process outsourcers (BPO) case - where = a >>>>>>> call center is providing service on behalf of multiple = companies. I >>>>>>> can see the value of them sending different numbers based on the >>>>>>> clients they represent. Wouldn't that create a billing issue = though? >>>>>>> This is not an area I understand well, but I would suspect that = SP >>>>>>> 1 allowing one of its subscribers to send an outbound call using = a >>>>>>> number registered to SP 2 could be a no-no. If this hypothesis = is >>>>>>> correct, then we are back to the case where the SP is signing = all >>>>>>> calls, >>>>> even for BPOs. >>>>>>>=20 >>>>>>> Or maybe this is another problem we are trying to fix in the >>>>>>> working group, in which case we perhaps should state as a goal = or >>>> benefit: >>>>>>> "providing a reliable mechanism to let calls originated from one >>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>=20 >>>>>>> Fernando >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" = >>>>> wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Any of them could do it. My guess is service providers will do = it >>>>>>>> for most call centers, although larger call centers might do it >>>>>>>> themselves... >>>>>>>> especially ones which have trunks from multiple providers and = can >>>>>>>> source calls using the same number(s) out through multiple >>>>>>>> providers on a call-by-call basis. >>>>>>>>=20 >>>>>>>> -hadriel >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh) >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> I'm catching up with the discussions in this working group, = and >>>>>>>>> am trying to understand some architecture implications in call >>>>>>>>> centers (which is where my background is). It seems that many = of >>>>>>>>> the problems we are trying to fix are related to contact = centers >>>>>>>>> anyway, so it is probably a good idea to have everyone in the >>>>>>>>> same >>>>> page. >>>>>>>>>=20 >>>>>>>>> Forgive me if it is an obvious question, but which components = in >>>>>>>>> a "typical call center architecture" do you see signature and >>>>>>>>> verification taking place? Such "typical" deployments have >>>>>>>>> premises based equipment (PME), a session border controller = (SBC) >>>>>>>>> and of course a SIP service provider all three could = potentially >>>>>>>>> be used throughout the authorization process. There are = different >>>>>>>>> ramifications depending on where your mind is at. >>>>>>>>>=20 >>>>>>>>> Fernando Mousinho >>>>>>>>> Cisco Systems >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>=20 >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>=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=20 >>>>>> you are not the intended recipient, please contact the sender and >>>>>> delete all copies of the message. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>=20 >=20 From internet-drafts@ietf.org Fri Oct 4 15:23:47 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9955221F9E39; Fri, 4 Oct 2013 15:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IugUHk5F1Yk; Fri, 4 Oct 2013 15:23:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3378721F9B65; Fri, 4 Oct 2013 15:23:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131004222346.32223.87882.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2013 15:23:46 -0700 X-Mailman-Approved-At: Sat, 05 Oct 2013 03:35:43 -0700 Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-problem-statement-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 22:23:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Telephone Identity Revisited Worki= ng Group of the IETF. Title : Secure Telephone Identity Problem Statement Author(s) : Jon Peterson Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-stir-problem-statement-00.txt Pages : 23 Date : 2013-10-04 Abstract: Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall security of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes or even circumventing multi- factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack of effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult, and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stir-problem-statement-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From housley@vigilsec.com Tue Oct 8 09:33:25 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C98D21E826E for ; Tue, 8 Oct 2013 09:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIhlLedBAOiI for ; Tue, 8 Oct 2013 09:33:20 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 71A7421E8236 for ; Tue, 8 Oct 2013 09:33:20 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 4D62DF24093 for ; Tue, 8 Oct 2013 12:33:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id WlGqvWcCyIaO for ; Tue, 8 Oct 2013 12:33:03 -0400 (EDT) Received: from [192.168.2.107] (pool-71-191-197-233.washdc.fios.verizon.net [71.191.197.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A60D4F24099 for ; Tue, 8 Oct 2013 12:33:39 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Oct 2013 12:33:15 -0400 Message-Id: <35CD2E5A-AB42-466A-AC65-7E7DBAEF5954@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [stir] IETF88 STIR WG Agenda X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:33:25 -0000 https://datatracker.ietf.org/meeting/88/agenda/stir/ The framework for the agenda that was previously discussed has been = posted. Please reach out to Robert or myself if you would like to = present at either session. Russ From br@brianrosen.net Tue Oct 8 09:36:36 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBCC21E81C6 for ; Tue, 8 Oct 2013 09:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 8jIIJWIfmPo4 for ; Tue, 8 Oct 2013 09:36:31 -0700 (PDT) Received: from mail-ye0-f174.google.com (mail-ye0-f174.google.com [209.85.213.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5469A21E81FD for ; Tue, 8 Oct 2013 09:36:28 -0700 (PDT) Received: by mail-ye0-f174.google.com with SMTP id r14so318139yen.5 for ; Tue, 08 Oct 2013 09:36:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=so4WkHHwaKxwe7rkbPQquz5LRYbSnVcszPwXMqq1Vdk=; b=XACBUnjPs1OLrKQjY/P9sj6OMSgaQOmh5I9oj6L4kQdWu8rdWS2udQb6Y6TMaW1O5g Blh2VJ8YRsqgRRGgeXI45KfXPRM4zjBFxAsUZ+pobC937qDICrBCQxYr8Un7Z/4Uf7my BXDcEYcGetxEPTF8IzrX7naxgmRkUwspOYfZrdKMHqsLh3pdW3mah2/sMurGkR3axuPJ U9ooKPAMQ5/zi2coIqs50dhQaQhDZyk4oGsBLtwxG179IHowziBrbsFbuwiA6HlEVdng xEo4eeg8asii9fYOs7LAnZx6abw87h7f83XsfWWCwZdG31tcVCKyLDnmYXdzkIaLSSd6 2pmw== X-Gm-Message-State: ALoCoQkgMOxewDVBMTm69Oo2qbEJmH0xgsQQ17ZiC927J0auyJh5eW5jSVtd/sfU5HgC5lifEvb2 X-Received: by 10.236.41.102 with SMTP id g66mr2082759yhb.20.1381250187798; Tue, 08 Oct 2013 09:36:27 -0700 (PDT) Received: from [10.33.193.37] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id m68sm53330209yhj.22.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Oct 2013 09:36:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Brian Rosen In-Reply-To: <35CD2E5A-AB42-466A-AC65-7E7DBAEF5954@vigilsec.com> Date: Tue, 8 Oct 2013 12:36:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <994B0D46-0F6B-4DDD-B44B-25EF5DACB7FF@brianrosen.net> References: <35CD2E5A-AB42-466A-AC65-7E7DBAEF5954@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1510) Cc: IETF STIR Mail List Subject: Re: [stir] IETF88 STIR WG Agenda X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:36:36 -0000 What is your intention on adopting the problem statement and threats = docs? Wait until the meeting, or declare consensus now? I'm hoping one or both of them can enter WGLC immediately after the = meeting. Brian On Oct 8, 2013, at 12:33 PM, Russ Housley wrote: > https://datatracker.ietf.org/meeting/88/agenda/stir/ >=20 > The framework for the agenda that was previously discussed has been = posted. Please reach out to Robert or myself if you would like to = present at either session. >=20 > Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From rjsparks@nostrum.com Tue Oct 8 09:45:57 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EABB21E80BE for ; Tue, 8 Oct 2013 09:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrHGHLwgb4Zs for ; Tue, 8 Oct 2013 09:45:56 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8946621E80A8 for ; Tue, 8 Oct 2013 09:45:56 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-224.dllstx.fios.verizon.net [173.57.89.224]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r98GjteI032128 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Tue, 8 Oct 2013 11:45:56 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <525436C3.4060303@nostrum.com> Date: Tue, 08 Oct 2013 11:45:55 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <35CD2E5A-AB42-466A-AC65-7E7DBAEF5954@vigilsec.com> <994B0D46-0F6B-4DDD-B44B-25EF5DACB7FF@brianrosen.net> In-Reply-To: <994B0D46-0F6B-4DDD-B44B-25EF5DACB7FF@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 173.57.89.224 is authenticated by a trusted mechanism) Subject: Re: [stir] IETF88 STIR WG Agenda X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:45:57 -0000 On 10/8/13 11:36 AM, Brian Rosen wrote: > What is your intention on adopting the problem statement and threats docs? > Wait until the meeting, or declare consensus now? I've asked Jon to submit both as WG -00s as soon as it is convenient for him to do so. RjS > > I'm hoping one or both of them can enter WGLC immediately after the meeting. > > Brian > > > On Oct 8, 2013, at 12:33 PM, Russ Housley wrote: > >> https://datatracker.ietf.org/meeting/88/agenda/stir/ >> >> The framework for the agenda that was previously discussed has been posted. Please reach out to Robert or myself if you would like to present at either session. >> >> 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 From br@brianrosen.net Tue Oct 8 09:47:38 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD16421E8274 for ; Tue, 8 Oct 2013 09:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.213 X-Spam-Level: X-Spam-Status: No, score=-103.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 SACoFb5ovr16 for ; Tue, 8 Oct 2013 09:47:34 -0700 (PDT) Received: from mail-gg0-f177.google.com (mail-gg0-f177.google.com [209.85.161.177]) by ietfa.amsl.com (Postfix) with ESMTP id DE8B621E8249 for ; Tue, 8 Oct 2013 09:47:33 -0700 (PDT) Received: by mail-gg0-f177.google.com with SMTP id t2so1446081ggn.22 for ; Tue, 08 Oct 2013 09:47:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=PHQUWf90rJA+TyBwgarK0p5zhFRC4b3YrNcJgtxermQ=; b=eq3aEVKhHLwW2HoYdvQE6FzIIAbwwGn0IYby9C03G0S0fvRCHpG0v+8zQNSl/bHZKt yR9cOMmCq4FSBgNB1zizYOtVJC6EWUI929OfEhk5fXC4SI7Z5VB3t7QksC5QPujG7SfR s0P5/WkpqmWVVmwJCJ5+9pVIwY3ZrdxcFivgNemjKc8y1MjXuMphvuVXvGv64Ea4HwzZ GwumE2nMDxCbn5D+gmYInWwBVqFPGgPWyVxxmjjluF75vZYCuLixU0jU9e3a5LKjg/Ng 5usargKCbsOEzrk1PT4FFahkRLFajAGwWoMUSaIpmlzm8C8KmA29K1j+jBuWFq456p4c tMsg== X-Gm-Message-State: ALoCoQmJrYYKfJjUwiWaZcqhZt3hHuRu/0GC3FhB02KJhPi/mbQuNdEgH1DcIKRC8yCVRw2MGrIU X-Received: by 10.236.141.12 with SMTP id f12mr2125295yhj.34.1381250844100; Tue, 08 Oct 2013 09:47:24 -0700 (PDT) Received: from [10.33.193.37] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id t31sm53406326yhp.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Oct 2013 09:47:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Brian Rosen In-Reply-To: <525436C3.4060303@nostrum.com> Date: Tue, 8 Oct 2013 12:47:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <35CD2E5A-AB42-466A-AC65-7E7DBAEF5954@vigilsec.com> <994B0D46-0F6B-4DDD-B44B-25EF5DACB7FF@brianrosen.net> <525436C3.4060303@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1510) Cc: stir@ietf.org Subject: Re: [stir] IETF88 STIR WG Agenda X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:47:39 -0000 Excellent, thank you. Brian On Oct 8, 2013, at 12:45 PM, Robert Sparks wrote: > On 10/8/13 11:36 AM, Brian Rosen wrote: >> What is your intention on adopting the problem statement and threats = docs? >> Wait until the meeting, or declare consensus now? > I've asked Jon to submit both as WG -00s as soon as it is convenient = for him to do so. >=20 > RjS >>=20 >> I'm hoping one or both of them can enter WGLC immediately after the = meeting. >>=20 >> Brian >>=20 >>=20 >> On Oct 8, 2013, at 12:33 PM, Russ Housley = wrote: >>=20 >>> https://datatracker.ietf.org/meeting/88/agenda/stir/ >>>=20 >>> The framework for the agenda that was previously discussed has been = posted. Please reach out to Robert or myself if you would like to = present at either session. >>>=20 >>> Russ >>>=20 >>> _______________________________________________ >>> 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 From rjsparks@nostrum.com Tue Oct 8 09:48:18 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C27621E8272 for ; Tue, 8 Oct 2013 09:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d07hlLenSwTe for ; Tue, 8 Oct 2013 09:47:53 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8802821E823C for ; Tue, 8 Oct 2013 09:47:48 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-224.dllstx.fios.verizon.net [173.57.89.224]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r98GlmIu032330 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Tue, 8 Oct 2013 11:47:48 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <52543734.7040404@nostrum.com> Date: Tue, 08 Oct 2013 11:47:48 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org References: <35CD2E5A-AB42-466A-AC65-7E7DBAEF5954@vigilsec.com> <994B0D46-0F6B-4DDD-B44B-25EF5DACB7FF@brianrosen.net> <525436C3.4060303@nostrum.com> In-Reply-To: <525436C3.4060303@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 173.57.89.224 is authenticated by a trusted mechanism) Subject: Re: [stir] IETF88 STIR WG Agenda X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:48:18 -0000 On 10/8/13 11:45 AM, Robert Sparks wrote: > On 10/8/13 11:36 AM, Brian Rosen wrote: >> What is your intention on adopting the problem statement and threats >> docs? >> Wait until the meeting, or declare consensus now? > I've asked Jon to submit both as WG -00s as soon as it is convenient > for him to do so. and to be clear, the problem-statement is already submitted (as of the 4th). > > RjS >> >> I'm hoping one or both of them can enter WGLC immediately after the >> meeting. >> >> Brian >> >> >> On Oct 8, 2013, at 12:33 PM, Russ Housley wrote: >> >>> https://datatracker.ietf.org/meeting/88/agenda/stir/ >>> >>> The framework for the agenda that was previously discussed has been >>> posted. Please reach out to Robert or myself if you would like to >>> present at either session. >>> >>> 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 > From jon.peterson@neustar.biz Tue Oct 8 11:22:27 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E149011E80FE for ; Tue, 8 Oct 2013 11:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.722 X-Spam-Level: X-Spam-Status: No, score=-105.722 tagged_above=-999 required=5 tests=[AWL=0.877, 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 2S2tggvWqavk for ; Tue, 8 Oct 2013 11:22:24 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id C3FD911E80F8 for ; Tue, 8 Oct 2013 11:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1381256495; x=1696615825; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=zYMi/rySNq OD8vojSg2JQjp9pDsHOEjJc02ifwmdodo=; b=mu/6rAvIdTxY16qoGaG8ydNslt LthhE30LqsM+N4kl9GpAV3FuDK3OnHNrqm+e2+7Wzy8EuLmEOrMYVDbgPlmg== Received: from ([10.31.58.69]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.25734286; Tue, 08 Oct 2013 14:17:23 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc10.cis.neustar.com ([169.254.4.132]) with mapi id 14.02.0342.003; Tue, 8 Oct 2013 14:22:04 -0400 From: "Peterson, Jon" To: "Rosen, Brian" , "stir@ietf.org List" Thread-Topic: [stir] Comments on draft-peterson-stir-threats-00 Thread-Index: AQHOvsfUbiPUZPEZSU6y5TDfiZrobZnq9q8A Date: Tue, 8 Oct 2013 18:22:03 +0000 Message-ID: In-Reply-To: <01F04E36-C5F8-4DF4-A575-21290E7E7ED8@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [192.168.129.154] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: oBXTu4xToWwI4Y/swvxiBw== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] Comments on draft-peterson-stir-threats-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:22:28 -0000 Thanks for these detailed notes, Brian. A few comments inline. On 10/1/13 10:01 AM, "Rosen, Brian" wrote: >I think this document is a very good start as a threat analysis and >should be adopted by the work group. > >In the Introduction, I think the most stark example of these attacks is >swatting, where the caller impersonates a victim and causes a massive law >enforcement action without any real basis. True, and we can mention it - though my understanding is that swatting attacks can be performed without impersonating any caller ID, since effectively you can just contact emergency services and claim there's a disturbance at a location and the response will be sent there. Having a caller ID for that location isn't integral to the attack. Certainly having the right caller ID provides a good corroborating detail. >There is a paragraph that talks about post set-up changes. It's correct >that we don't consider them, but the way SIP works, any INVITE (say from >a bridge) could be protected. Protected from what attack? That's the question for a threats document. >Do you want to at least reference cnit? Maybe just as "further work will >be needed". Is the second-to-last paragraph of the Introduction not sufficient? The problem-statement document already has a statement that this effort isn't considering display name validation as well. >In Attackers, I'm not sure I understand an attacker that observes but >does not replay. We are not encrypting anything, so observation will >always be possible. The voicemail hack would require a replay to be >successful (if it were possible) unless they had the keys. The attacker postulated in that TBD isn't entirely passive: the question there is if we should consider attackers who can replay signaling that wasn't sent directly to them. So, say, an attacker at the IETF who can listen to the public WiFi there, captures signaling going from you to your voicemail service, and then wants to impersonate you to your voicemail service.=20 So the point of that TBD is to ask, are we considering only attackers who replay signaling that they received, or also attackers who might replay signaling that they captured be eavesdropping? >When you talk about not including intermediaries as attackers, perhaps it >would be good to explain in the intro that we don't consider service >providers to be directly participating, but we do see some of them >turning a blind eye to bad things their customers are doing. We're not >assuming the service providers are the attackers, but we are assuming >some of them are indirectly complicit. I suspect that subtlety is probably better suited for the problem-statement than for this document. Unless we're saying that we want to implement protocol mechanisms to defend against careless service providers, I'm not sure what we'd say about this in a threat document that would change the recommendations. >In Voicemail Attacks, I got lost in the paragraph beginning "If the >voicemail service could know ahead of time that it should always expect >authenticated identity.." I'm not sure what it's trying to say and >wonder if it could be deleted without losing anything important. The rest of the paragraph does give a concrete example of this countermeasure: if I call a voicemail service regularly, and my call is signed with an identity signature, the voicemail service should be wary if it receives a call purporting to be from my number without a signature. But we want to say something more general than that, to take into account DANE-like mechanisms for advertising "you should expect identity in a call from this number." So, I went with "if you could know ahead of time" language there. In general, we want to discuss this sort of mechanism in a high-level overview of countermeasures because identity is necessarily opt-in and will be adopted only incrementally, so anything we can do to improve the prospect that incremental identity will be practically useful is very helpful.=20 >In Commercial impersonation Attacks, I am bothered by the sentence "If >there were a directory that could inform the terminating side of that >fact, however, that would help in the robocalling case." I have no idea >what directory that is referring to, and ISTM that you can rarely assure >you can ALWAYS get authenticated identity from a given TN. I guess you >mean the out of band directory, but that would depend on the called party >having credentials, so there is at least some qualification needed. Same as the last note. "Directory" here is again referring to DANE-like mechanisms. I agree you can rarely assure that you can always get identity in a call, but your policies can know to treat calls without identity with greater suspicion when you have an expectation it will be used. >I'd like the swatting case documented. I can send text if desired. Please do, but please do focus on the degree to which the calling party number actually changes what emergency responders do. >In IP-PSTN attack scenario, if we did adopt some of the ideas in >Hadriel's proposal, we might get the in band solution to work with >IP-PSTN GWs. I also want to get the notion that if there is an >intermediary on the IP side, including the IP-PSTN GW, it could validate. Certainly I thought about this question when writing these threats, though just for the IP-PSTN-IP case, not for the IP-PSTN case. For IP-PSTN the terminating gateway could validate, and say, not send the call to the PSTN if there's no identity signature - we've talked about things like that before. I'd be willing to add that as a scenario where in-band helps with the IP-PSTN case, though it's not an end-to-end indication in that case. Regarding gateway the identity signature, I suspect this question is largely one of terminology, about what is "in-band" versus "out-of-band." If "in-band" is understood strictly to mean "in SIP," then I don't think gatewaying would be in the scope of "in-band." We could even define some kind of "hybrid" designation for gatewaying. The reason why I didn't, thus far anyway, is because I'm interested in how much overlap there is in the information that we imagine would be gatewayed (stored in a field in XMPP somewhere, say) and the information that would be shared via out-of-band for identity. If the overlap turns out to be very large, then maybe these cases are closer than they might look right now. But that depends very much on the details of the solution space, and is certainly beyond the scope of a threats document. >Isn't it a stretch to say that the out of band mechanism could work for a >PSTN-PSTN connection? It assumes an Internet-aware origination (device >or service) with both IP and PSTN connectivity. That would not cover any >existing device or service, so you are talking about an upgraded service >that did not also upgrade to SIP origination. Possible, sure, but worth >documenting? Dunno. This is a cornerstone case for out-of-band: a case where two mobile phones, say, can exchange out-of-band identity even though their call goes over the PSTN. It does indeed assume an Internet-aware device with both PSTN and IP connectivity. I'd say every iPhone meets that description, so I'm not sure what distinction you're drawing here that I'm missing. >IP-PSTN-IP - same comments as IP-PSTN See above. Thanks again, Jon Peterson Neustar, Inc. >Brian >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From internet-drafts@ietf.org Fri Oct 11 16:34:33 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5FF21E8084; Fri, 11 Oct 2013 16:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cisMf6EnNlJ5; Fri, 11 Oct 2013 16:34:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F85721F9DFB; Fri, 11 Oct 2013 16:34:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131011233433.16052.66127.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2013 16:34:33 -0700 X-Mailman-Approved-At: Sat, 12 Oct 2013 19:34:27 -0700 Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 23:34:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Telephone Identity Revisited Worki= ng Group of the IETF. Title : Secure Telephone Identity Threat Model Author(s) : Jon Peterson Filename : draft-ietf-stir-threats-00.txt Pages : 11 Date : 2013-10-11 Abstract: As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes or even circumventing multi- factor authentication systems trusted by banks. This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stir-threats-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From br@brianrosen.net Mon Oct 14 14:34:46 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C4721F93BF for ; Mon, 14 Oct 2013 14:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.357 X-Spam-Level: X-Spam-Status: No, score=-103.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 LAXm1pcV4dUe for ; Mon, 14 Oct 2013 14:34:31 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8B05621E8089 for ; Mon, 14 Oct 2013 14:34:22 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id v2so5272771qcr.20 for ; Mon, 14 Oct 2013 14:34:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=Rtt+TYPcMrDN7zEOwPQ0NZvwhHxxoDUprURxGsfTeU8=; b=LFdik8N/aEqs1Qee26g7H5Zr/ZV67RtcMwv+s2Uhgt8kbCqH+gborJqzOSKenJIxYy g6OfM4f+27VEM76D3Yx28tIlOADtI9kdjlIFIiB9C6DAeRvRt1oKmKm0b7u9lMPDTm7U xSRh4sUiss+y4We9CrGrLfq7w2mXG1eelixggPqXJaf87G+pDwYB5RN8+0FD6dlxS0WD JHxcHWlk2bP/7uzx51Jb39ZAXUgvIJqLXNunwBk2U6Dt0mmLf4vHkU0IqHKK3Dc3BmUe wQHNIlpV9wDS/GjR5Ps7nOfD+WIYf5rTV7tCICARc6SvcJWdbajZmYY7KNsxdFK5VfR6 fZ7Q== X-Gm-Message-State: ALoCoQkGgqoJZTF3h8ovQePVDN9hvTX1igpOgna8xUcg49mHqnMA7qmAZmH64rmkp8JQFPkoahag X-Received: by 10.224.130.72 with SMTP id r8mr25607749qas.32.1381786462066; Mon, 14 Oct 2013 14:34:22 -0700 (PDT) Received: from [10.33.193.37] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id u3sm71998074qej.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Oct 2013 14:34:21 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 14 Oct 2013 17:34:20 -0400 To: "stir@ietf.org Mail List" Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) X-Mailer: Apple Mail (2.1510) Subject: [stir] draft-ietf-stir-problem-statement-00 looks pretty good to me X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 21:34:47 -0000 I looked at the draft and most of my comments have been addressed, with = the couple remaining ones a difference of style not important. I think it's good enough and would like to send it on its way. Brian From fmousinh@cisco.com Mon Oct 14 15:11:48 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0D121E8195 for ; Mon, 14 Oct 2013 15:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQk24WTVlmzt for ; Mon, 14 Oct 2013 15:11:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BEEB721E8133 for ; Mon, 14 Oct 2013 15:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=963; q=dns/txt; s=iport; t=1381788702; x=1382998302; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=N0imsXE434TBNAsYhUoqxnXQGCrk/qzDuESuYK110AA=; b=G/hgPvYt6OAi6MFWGx+FV9cp9rbF9vb5cGzIXk5Nf77AQpH8oFyCVsR4 +pKHXNFEMK8jzZPwzsP23iHpiJYHf2YGoYo2Zjt7A7XKnnT9gB4Wrh5oN qUKoTGXyBoNI+JHZClBQ7j3zhfe8fJItYZk1G7E7FUf0mf1gUbRbsINFC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFABNrXFKtJXHB/2dsb2JhbABZgwc4UsIQgSoWdIInAQQBAQFrHQEIDhRLCyUCBAESCBOHawy9ZQSPIDiDH4EEA6oHgySCKQ X-IronPort-AV: E=Sophos;i="4.93,494,1378857600"; d="scan'208";a="272128704" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 14 Oct 2013 22:11:42 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9EMBgaP019571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 22:11:42 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 17:11:41 -0500 From: "Fernando Mousinho (fmousinh)" To: Brian Rosen , "stir@ietf.org Mail List" Thread-Topic: [stir] draft-ietf-stir-problem-statement-00 looks pretty good to me Thread-Index: AQHOySU3eq0PYu6Vv0ChL4ZBVx5DPpn00y8A Date: Mon, 14 Oct 2013 22:11:41 +0000 Message-ID: <71E3420F5D11314D8D989D8B72D247E129FF9406@xmb-aln-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.117.152.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3F3A2D78A8FCCB4584599647BD8F5E33@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] draft-ietf-stir-problem-statement-00 looks pretty good to me X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 22:11:48 -0000 Thinking loud=8A maybe these don't need to be addressed: - Do we need to specify which types of identities we want to tackle: public PSTN numbers, private numbers, and/or URIs? Or is "all of the above" implicit? - What about internal use of the solutions (e.g., verifying identities of other callers in the same domain - preventing attacks from within)? Do we care about this use case or is it assumed to be implicit? The draft reads as it inter-domain (inter-company) is the main (only?) topic, but it could be just me. On 10/14/13 5:34 PM, "Brian Rosen" wrote: >I looked at the draft and most of my comments have been addressed, with >the couple remaining ones a difference of style not important. > >I think it's good enough and would like to send it on its way. > >Brian > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From philippe.fouquart@orange.com Tue Oct 15 08:47:22 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC15A21E81D5 for ; Tue, 15 Oct 2013 08:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 QSOOFah2W07V for ; Tue, 15 Oct 2013 08:47:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id D3D0221E81BB for ; Tue, 15 Oct 2013 08:46:56 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id B858F190564 for ; Tue, 15 Oct 2013 17:46:55 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id A066EC806C for ; Tue, 15 Oct 2013 17:46:55 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 17:46:55 +0200 From: To: "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-problem-statement-00.txt Thread-Index: AQHOwbard6+J3gk4m0SXrO2ksZ5g2Jn17t9w Date: Tue, 15 Oct 2013 15:46:54 +0000 Message-ID: <23536_1381852015_525D636F_23536_8349_1_B5939C6860701C49AA39C5DA5189448B0C533A@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20131004222346.32223.87882.idtracker@ietfa.amsl.com> In-Reply-To: <20131004222346.32223.87882.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.15.62114 Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:47:22 -0000 This draft looks good to me. A few typos & nitpicking: > 1. Introduction [...] > conceptional=20 "functionally" (?) > 2. Problem Statement [...]=20 > through the concept of certificated=20 > carriers "Certified" doesn't read well to me here. "licensed"?=20 > 3. Terminology [...] > telephoone telephone > 4. Use Cases [...] > We generally assume that the PSTN component of any call path cannot > be altered. Not quite clear to me what we mean by this (or equally unclear what the con= sequence would be for the document should we make the opposite assumption..= .) Maybe remove or clarify.=20=20=20 > 4.2. IP-PSTN-IP Call > Frequently, two VoIP-based service providers Would suggest inserting "(VSP)" after that. > 4.4. VoIP-to-PSTN Call Call Probably too many calls here... > 4.5. PSTN-VoIP-PSTN Call > Consequenly Consequently > That said, > national authorities for telephone numbers are increasingly migrating > their provisioning services to the Internet, and issuing credentials > that express authority for telephone numbers to secure those > services.=20=20 The use of plural and "increasingly" seems a bit exaggerated to me. Maybe s= ay "some... are..." Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Saturday, October 05, 2013 12:24 AM To: i-d-announce@ietf.org Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-problem-statement-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Telephone Identity Revisited Worki= ng Group of the IETF. Title : Secure Telephone Identity Problem Statement Author(s) : Jon Peterson Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-stir-problem-statement-00.txt Pages : 23 Date : 2013-10-04 Abstract: Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall security of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes or even circumventing multi- factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack of effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult, and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stir-problem-statement-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From br@brianrosen.net Wed Oct 16 06:39:28 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E486B11E8260 for ; Wed, 16 Oct 2013 06:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.384 X-Spam-Level: X-Spam-Status: No, score=-103.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 hh9U6o+oll-s for ; Wed, 16 Oct 2013 06:39:24 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5211E8132 for ; Wed, 16 Oct 2013 06:39:23 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id d4so570374qej.21 for ; Wed, 16 Oct 2013 06:39:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=5K3u4/cf2e8Ynrl5TtIzxAqrLAHTaTlXdhlXwX4ljug=; b=fA/5oO6c8x2GZIPhQKhrytB93LTJMuNBk39zimGekTLJxoFmip5sgD0eJSebxBgZ8w o+A8AfMOQKxYw3xVevHaM/XeYYba7MTP9pf+o/8lLr9ZsAI6nYgtVw4ZAY1gVyb/6HLJ /vqoYB95UWGvvkQFJDvHz4e7kbleepkk2fydyAY0KdF/FvImYqPXxvlM8qAnIl9juiLn z5QR6uGgT1x2HBe+/pztBRsjwGmiU8YN2rk+LWa13BxyxIm26XHokdTdzOghfw89kaV3 +LEIpGyuff3Qot/24fJ9x8uko8KNEtBwU8rxu7pNAqUmAeIaHH8bGlcbDCzzkTVFABXb jL0g== X-Gm-Message-State: ALoCoQlmBIheU5JK5Oo/nHQkhNfqCzlXTQZfcxgIAv7IEMmfjL+GJJuq4zzYzth3CZ7YKeTLNI+n X-Received: by 10.224.54.209 with SMTP id r17mr4827985qag.16.1381930762455; Wed, 16 Oct 2013 06:39:22 -0700 (PDT) Received: from [10.33.193.37] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id h9sm51829295qaq.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Oct 2013 06:39:21 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Brian Rosen In-Reply-To: <71E3420F5D11314D8D989D8B72D247E129FF9406@xmb-aln-x06.cisco.com> Date: Wed, 16 Oct 2013 09:39:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0DEDEC27-D3C2-48E3-9799-A005906CD3D6@brianrosen.net> References: <71E3420F5D11314D8D989D8B72D247E129FF9406@xmb-aln-x06.cisco.com> To: Fernando Mousinho (fmousinh) X-Mailer: Apple Mail (2.1510) Cc: "stir@ietf.org Mail List" Subject: Re: [stir] draft-ietf-stir-problem-statement-00 looks pretty good to me X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:39:29 -0000 I think the draft is fairly clear we're talking about public identities. = It mostly talks about telephone numbers, but ISTM the mechanisms we're = discussing probably would work with user@domain IDs, but I think that's = a bonus and not an explicit goal. Similarly, I think internal use would work just fine, but is also not an = explicit goal. Brian On Oct 14, 2013, at 6:11 PM, Fernando Mousinho (fmousinh) = wrote: > Thinking loud=8A maybe these don't need to be addressed: >=20 > - Do we need to specify which types of identities we want to tackle: > public PSTN numbers, private numbers, and/or URIs? Or is "all of the > above" implicit? >=20 > - What about internal use of the solutions (e.g., verifying identities = of > other callers in the same domain - preventing attacks from within)? Do = we > care about this use case or is it assumed to be implicit? >=20 > The draft reads as it inter-domain (inter-company) is the main (only?) > topic, but it could be just me. >=20 >=20 >=20 >=20 >=20 > On 10/14/13 5:34 PM, "Brian Rosen" wrote: >=20 >> I looked at the draft and most of my comments have been addressed, = with >> the couple remaining ones a difference of style not important. >>=20 >> I think it's good enough and would like to send it on its way. >>=20 >> Brian >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From br@brianrosen.net Wed Oct 16 12:14:52 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC7911E8255 for ; Wed, 16 Oct 2013 12:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.406 X-Spam-Level: X-Spam-Status: No, score=-103.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 qBeAsrP5f9Jj for ; Wed, 16 Oct 2013 12:14:46 -0700 (PDT) Received: from mail-yh0-f51.google.com (mail-yh0-f51.google.com [209.85.213.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4E74911E8147 for ; Wed, 16 Oct 2013 12:14:43 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id 29so286294yhl.24 for ; Wed, 16 Oct 2013 12:14:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=I54MAzDfXSY3zQArmUjtqXe8y0s1NubKoXPS6GLAY+s=; b=aMips/tY2iA2KCvz8hUe6NhGL/OyKBOE1+B1+4zSZTxcWw4r/0ZUcZEpflqse7yPXf crWWjUrrwCUkSkvMNRdRsu3EHMGJh/D3kea9mSOngM4F6wMht+hs3I80S1dFktBHus9s iozPzrOoST8jD3TPP5uLPaMRlQ1Su7DdO9Ohzmu4DZX1p96h8xV0dH0GQRub6FeHFMpg sK9y8UT3kbQlhS5GXNFVl2Kt/3i/Ro7K1m9K+AjrF6lHLCKa4a36QWwdGlNnO618/JQf HuePZ8QGj6Jf6Fa6RCna5gUvn4RykmzPakW0FuwhAgqAcmMWse2ASmKXkl/5pfFFT2gF UD1g== X-Gm-Message-State: ALoCoQnOxbtr/PzjUJCSJzxB8dOf98SfWvPzmw+0WgR5ayBAdOZlcMdECxZEj7DgwZYK8wv4Sk3n X-Received: by 10.236.181.6 with SMTP id k6mr1903334yhm.93.1381950882903; Wed, 16 Oct 2013 12:14:42 -0700 (PDT) Received: from [10.33.193.37] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id d26sm122426742yhj.25.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Oct 2013 12:14:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Brian Rosen In-Reply-To: <23536_1381852015_525D636F_23536_8349_1_B5939C6860701C49AA39C5DA5189448B0C533A@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Wed, 16 Oct 2013 15:14:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2437B7EA-7092-4F3D-81F0-F55C1BB705A8@brianrosen.net> References: <20131004222346.32223.87882.idtracker@ietfa.amsl.com> <23536_1381852015_525D636F_23536_8349_1_B5939C6860701C49AA39C5DA5189448B0C533A@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: philippe.fouquart@orange.com X-Mailer: Apple Mail (2.1510) Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 19:14:52 -0000 Minor detail but in 2, "certificated" is a U.S.-centric term that means = a government authorized carrier. The term of art is "certificated" = because a state government entity issues an operating certificate to the = carrier that lets other entities know that it is authorized to provide = service. "Licensed" is pretty close, but not actually what happens in the U.S. I = could deal with "licensed" though - it's clear what it means. Brian On Oct 15, 2013, at 11:46 AM, philippe.fouquart@orange.com wrote: > This draft looks good to me. >=20 > A few typos & nitpicking: >=20 >> 1. Introduction > [...] >> conceptional=20 >=20 > "functionally" (?) >=20 >> 2. Problem Statement > [...]=20 >> through the concept of certificated=20 >> carriers >=20 > "Certified" doesn't read well to me here. "licensed"?=20 >=20 >> 3. Terminology > [...] >> telephoone >=20 > telephone >=20 >> 4. Use Cases > [...] >> We generally assume that the PSTN component of any call path cannot >> be altered. >=20 > Not quite clear to me what we mean by this (or equally unclear what = the consequence would be for the document should we make the opposite = assumption...) Maybe remove or clarify. =20 >=20 >> 4.2. IP-PSTN-IP Call >> Frequently, two VoIP-based service providers >=20 > Would suggest inserting "(VSP)" after that. >=20 >> 4.4. VoIP-to-PSTN Call Call >=20 > Probably too many calls here... >=20 >> 4.5. PSTN-VoIP-PSTN Call >> Consequenly >=20 > Consequently >=20 >> That said, >> national authorities for telephone numbers are increasingly = migrating >> their provisioning services to the Internet, and issuing credentials >> that express authority for telephone numbers to secure those >> services. =20 >=20 > The use of plural and "increasingly" seems a bit exaggerated to me. = Maybe say "some... are..." >=20 > Regards, >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Saturday, October 05, 2013 12:24 AM > To: i-d-announce@ietf.org > Cc: stir@ietf.org > Subject: [stir] I-D Action: draft-ietf-stir-problem-statement-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Telephone Identity Revisited = Working Group of the IETF. >=20 > Title : Secure Telephone Identity Problem Statement > Author(s) : Jon Peterson > Henning Schulzrinne > Hannes Tschofenig > Filename : draft-ietf-stir-problem-statement-00.txt > Pages : 23 > Date : 2013-10-04 >=20 > Abstract: > Over the past decade, Voice over IP (VoIP) systems based on SIP have > replaced many traditional telephony deployments. Interworking VoIP > systems with the traditional telephone network has reduced the > overall security of calling party number and Caller ID assurances by > granting attackers new and inexpensive tools to impersonate or > obscure calling party numbers when orchestrating bulk commercial > calling schemes, hacking voicemail boxes or even circumventing = multi- > factor authentication systems trusted by banks. Despite previous > attempts to provide a secure assurance of the origin of SIP > communications, we still lack of effective standards for identifying > the calling party in a VoIP session. This document examines the > reasons why providing identity for telephone numbers on the Internet > has proven so difficult, and shows how changes in the last decade = may > provide us with new strategies for attaching a secure identity to = SIP > sessions. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-stir-problem-statement-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From philippe.fouquart@orange.com Thu Oct 17 01:31:39 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB73C11E8114 for ; Thu, 17 Oct 2013 01:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 peMVF76OgBLA for ; Thu, 17 Oct 2013 01:31:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id F32B611E810D for ; Thu, 17 Oct 2013 01:31:32 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id AFE8422CC60; Thu, 17 Oct 2013 10:31:31 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7477935C082; Thu, 17 Oct 2013 10:31:31 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0347.000; Thu, 17 Oct 2013 10:31:31 +0200 From: To: Brian Rosen Thread-Topic: [stir] I-D Action: draft-ietf-stir-problem-statement-00.txt Thread-Index: AQHOwbard6+J3gk4m0SXrO2ksZ5g2Jn17t9wgAG0F4CAAPSc0A== Date: Thu, 17 Oct 2013 08:31:31 +0000 Message-ID: <19616_1381998691_525FA063_19616_4126_2_B5939C6860701C49AA39C5DA5189448B0CE8FE@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20131004222346.32223.87882.idtracker@ietfa.amsl.com> <23536_1381852015_525D636F_23536_8349_1_B5939C6860701C49AA39C5DA5189448B0C533A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2437B7EA-7092-4F3D-81F0-F55C1BB705A8@brianrosen.net> In-Reply-To: <2437B7EA-7092-4F3D-81F0-F55C1BB705A8@brianrosen.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.10.17.43315 Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 08:31:39 -0000 Thanks for the background on this, Brian.=20 FWIW this makes me think that people familiar with the EU framework may als= o argue for the use of "authorization" since the individual licensing regim= e has moved to what's called authorizations there (and it's generally more = of a lightweight registration really). Given the context of stir, I just th= ought readers might infer that such carriers always get digital certificate= s if they're "certificated"/registered/authorized/licensed, when they don't= always do - and probably don't in general.=20 But I don't feel strongly one way or another, either.=20 Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, October 16, 2013 9:15 PM To: FOUQUART Philippe IMT/OLN Cc: stir@ietf.org Subject: Re: [stir] I-D Action: draft-ietf-stir-problem-statement-00.txt Minor detail but in 2, "certificated" is a U.S.-centric term that means a g= overnment authorized carrier. The term of art is "certificated" because a = state government entity issues an operating certificate to the carrier that= lets other entities know that it is authorized to provide service. "Licensed" is pretty close, but not actually what happens in the U.S. I co= uld deal with "licensed" though - it's clear what it means. Brian On Oct 15, 2013, at 11:46 AM, philippe.fouquart@orange.com wrote: > This draft looks good to me. >=20 > A few typos & nitpicking: >=20 >> 1. Introduction > [...] >> conceptional=20 >=20 > "functionally" (?) >=20 >> 2. Problem Statement > [...]=20 >> through the concept of certificated=20 >> carriers >=20 > "Certified" doesn't read well to me here. "licensed"?=20 >=20 >> 3. Terminology > [...] >> telephoone >=20 > telephone >=20 >> 4. Use Cases > [...] >> We generally assume that the PSTN component of any call path cannot >> be altered. >=20 > Not quite clear to me what we mean by this (or equally unclear what the c= onsequence would be for the document should we make the opposite assumption= ...) Maybe remove or clarify.=20=20=20 >=20 >> 4.2. IP-PSTN-IP Call >> Frequently, two VoIP-based service providers >=20 > Would suggest inserting "(VSP)" after that. >=20 >> 4.4. VoIP-to-PSTN Call Call >=20 > Probably too many calls here... >=20 >> 4.5. PSTN-VoIP-PSTN Call >> Consequenly >=20 > Consequently >=20 >> That said, >> national authorities for telephone numbers are increasingly migrating >> their provisioning services to the Internet, and issuing credentials >> that express authority for telephone numbers to secure those >> services.=20=20 >=20 > The use of plural and "increasingly" seems a bit exaggerated to me. Maybe= say "some... are..." >=20 > Regards, >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Saturday, October 05, 2013 12:24 AM > To: i-d-announce@ietf.org > Cc: stir@ietf.org > Subject: [stir] I-D Action: draft-ietf-stir-problem-statement-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Secure Telephone Identity Revisited Work= ing Group of the IETF. >=20 > Title : Secure Telephone Identity Problem Statement > Author(s) : Jon Peterson > Henning Schulzrinne > Hannes Tschofenig > Filename : draft-ietf-stir-problem-statement-00.txt > Pages : 23 > Date : 2013-10-04 >=20 > Abstract: > Over the past decade, Voice over IP (VoIP) systems based on SIP have > replaced many traditional telephony deployments. Interworking VoIP > systems with the traditional telephone network has reduced the > overall security of calling party number and Caller ID assurances by > granting attackers new and inexpensive tools to impersonate or > obscure calling party numbers when orchestrating bulk commercial > calling schemes, hacking voicemail boxes or even circumventing multi- > factor authentication systems trusted by banks. Despite previous > attempts to provide a secure assurance of the origin of SIP > communications, we still lack of effective standards for identifying > the calling party in a VoIP session. This document examines the > reasons why providing identity for telephone numbers on the Internet > has proven so difficult, and shows how changes in the last decade may > provide us with new strategies for attaching a secure identity to SIP > sessions. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-stir-problem-statement-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From fluffy@cisco.com Sat Oct 19 22:12:14 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CCE11E8162 for ; Sat, 19 Oct 2013 22:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fRNHgCJK9L5 for ; Sat, 19 Oct 2013 22:12:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 09D8D11E816D for ; Sat, 19 Oct 2013 22:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16901; q=dns/txt; s=iport; t=1382245926; x=1383455526; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hijl2VLTjAyCpSpK5d42gaci/L51iKIz9S9pjh/qxOo=; b=ED08jxX4kru3eycZWeOxXwDnESyrKkmtTgs3uP5qS9iF0lgf3GyqeRtM 1EOKNvkJKtP7KXwfjCgzZ9bNgild2n4WwTfK6M9DSyZAfpqcPZDFvPEdu rUQ0cbl0pY1NTXdrH4Y7iL2YaPWGSUS3TVJnCww96miCFlEz0S0+/8xMU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAA5lY1KtJV2b/2dsb2JhbABQAQYDgwc4VL4zgSAWdIIlAQEBAwEBAQFWFQsFBwQCAQgOAwEDAQEBCh0HJwsUAwYIAgQOBQgTh2UGDb95BI4ZAQMGBYEBAgYbEAcCBAuDDoEKA5QqlWaDJIFoAgcXIg X-IronPort-AV: E=Sophos;i="4.93,532,1378857600"; d="scan'208";a="271234502" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 20 Oct 2013 05:12:05 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9K5C4Oc015800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Oct 2013 05:12:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sun, 20 Oct 2013 00:12:04 -0500 From: "Cullen Jennings (fluffy)" To: Brian Rosen Thread-Topic: [stir] Call Center Implications Thread-Index: AQHOzVLqVcqY5phDgki6OmYv42qajQ== Date: Sun, 20 Oct 2013 05:12:03 +0000 Message-ID: References: <71E3420F5D11314D8D989D8B72D247E129FE2079@xmb-aln-x06.cisco.com> <1B06BEFF-E7AC-4B30-B9D5-844E1192B4CB@brianrosen.net> In-Reply-To: <1B06BEFF-E7AC-4B30-B9D5-844E1192B4CB@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <794AECF2E3D05749B9C46BC3E21EEB07@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Gregory.Schumacher@sprint.com" , Richard Shockey , Henning Schulzrinne , "stir@ietf.org" , Alex Bobotek , Michael Hammer , "Fernando Mousinho $fmousinh$" Subject: Re: [stir] Call Center Implications X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 05:12:14 -0000 What Fernando is saying makes sense to me a desirable property of the solut= ion and I agree that if we gave each BPO a different private key that woul= d solve it but that might be pretty hard to mange in other ways. I like the= requirements but the solution is not 100% obvious to me.=20 On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: > Sure. >=20 > Each BPO would have a different private/public key pair. >=20 > So you can trace which one placed the call. >=20 > Brian >=20 > On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh) wrote: >=20 >> Point taken on PAI, but am still struggling with this BPO model. Apologi= es >> upfront if this is obvious and I'm just failing to understand. >>=20 >> If the company hires several BPOs and authorizes all of them to sign cal= ls >> on its behalf, is there a way to trace back the originator (specific BPO= ) >> later on? I suppose that at some level the actual caller must be exposed >> (perhaps to trace malicious activity, such as malicious person infiltrat= ed >> in an otherwise legitimate BPO). >>=20 >> Via headers would be the obvious pick, but they don't survive the pletho= ra >> of SBCs that the call is likely to transverse. Or maybe the certs >> themselves can carry this type of data (actual caller identity). >>=20 >>=20 >>=20 >>=20 >> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>=20 >>> Don't think that would work without related changes in the networks. I= n >>> some networks, PAI is used for called id. They would have to change to >>> use From (if signed maybe). It also doesn't fit the definition of PAI. >>>=20 >>> Brian >>>=20 >>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh) >>> wrote: >>>=20 >>>> Could a signed PAI be a potential solution to the BPO use case? "From" >>>> identifies the BPO, "PAI" the c >>>> ompany hiring the BPO - based on the delegation process Rosen mentions= . >>>> PAI's use is widespread, and it's main limitation is being spoofable - >>>> but this is exactly the problem we are trying to solve anyway. >>>>=20 >>>>=20 >>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey" >>>>> wrote: >>>>>=20 >>>>> Excellent point a profile or BCP to complement the work. >>>>>=20 >>>>> -----Original Message----- >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>>> Of Alex >>>>> Bobotek >>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com; >>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Call Center Implications >>>>>=20 >>>>> +1 >>>>> I've assumed that we are headed towards a "sign whatever extras you >>>>> wish, >>>>> and indicate what your signature covers" mechanism. >>>>>=20 >>>>> Based on this, standards would need to identify only a minimal subset >>>>> of >>>>> what shall/should be signed, and ensure that any required group of >>>>> signed >>>>> items survives transit intact. >>>>>=20 >>>>> Best signing practices may be needed to complement the standard, and = an >>>>> appropriate place for all but the most basic 'what to sign' >>>>> recommendations. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Alex >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>>>> Of Henning Schulzrinne >>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>> To: Michael Hammer; fmousinh@cisco.com; Gregory.Schumacher@sprint.co= m; >>>>>> br@brianrosen.net >>>>>> Cc: stir@ietf.org >>>>>> Subject: Re: [stir] Call Center Implications >>>>>>=20 >>>>>> I see no reason not to allow signing any number-related field in the >>>>>> SIP request. (Signing may well be done by different parties.) >>>>>>=20 >>>>>> As far as I know, callback numbers (SIP Reply-To) aren't conveyable >>>>>> in=20 >>>>>> legacy systems, however, so this may be of somewhat limited use for = a >>>>> while. >>>>>>=20 >>>>>> ________________________________________ >>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of >>>>>> Michael Hammer [michael.hammer@yaanatech.com] >>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com; >>>>>> br@brianrosen.net >>>>>> Cc: stir@ietf.org >>>>>> Subject: Re: [stir] Call Center Implications >>>>>>=20 >>>>>> Don't we still want to know the true originator of the call, even >>>>>> when=20 >>>>>> we have some token that says "Doctor so and so approved this message= ." >>>>>>=20 >>>>>> Originating number, display number, and call-back number could be 3 >>>>>> different things. >>>>>> Should all of them be verifiable? >>>>>>=20 >>>>>> Mike >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>>>> Of Fernando Mousinho (fmousinh) >>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>> Cc: stir@ietf.org >>>>>> Subject: Re: [stir] Call Center Implications >>>>>>=20 >>>>>> I believe the scenario telemarketing here is when a client hires a >>>>>> BPO=20 >>>>>> to place outbound calls, but expect customers to return these calls >>>>>> to=20 >>>>>> a different place (say, their own and operated call center). This >>>>>> way,=20 >>>>>> this client is authorizing the BPO to use an identity that it (BPO) >>>>> doesn't own. >>>>>> These numbers in this scenario are always operational, just at a >>>>>> different place. >>>>>>=20 >>>>>> The same telemarketing operator would then outpulse multiple numbers >>>>>> for their multiple clients, none of these numbers belonging to the >>>>> telemarketer. >>>>>> BTW, we are using the term "telemarketing" in a very generic sense - >>>>>> this could just as easily be a public service announcement, >>>>>> fundraiser, >>>>> etc. >>>>>>=20 >>>>>> If the telemarketer happens to own the inbound call center as well, >>>>>> it=20 >>>>>> very likely owns the number as well and this would necessarily be a >>>>>> special case >>>>>> - it would fall under the same characteristics of any call center. >>>>>>=20 >>>>>> On a different note, it would help a lot of we standardized >>>>>> terminology. >>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it may be >>>>>> hard=20 >>>>>> for others to follow the discussion later. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> (generic term for any type of outbound calling, including public >>>>>> service announcement, so don't think it's all about sales!) >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>> wrote: >>>>>>=20 >>>>>>> There are some benefits from this approach, but also some scenarios >>>>>>> that need clarification how they could function. >>>>>>>=20 >>>>>>> The benefit is that the credential represents both the company >>>>>>> "responsible" for the sales campaign (the "company" in your >>>>>>> scenario)=20 >>>>>>> and the company operating the sales campaign (the call center in >>>>>>> your=20 >>>>>>> scenario). For the use in forensics (after the fact analysis) such >>>>>>> as pursuit of fraud investigation, we then can follow both paths. >>>>>>>=20 >>>>>>> However can you clarify the following - >>>>>>> - If a SP "signs" the call, is it attesting to the "responsible" >>>>>>> party for the telemarketing call or the party executing the >>>>>>> telemarketing campaign or both? >>>>>>>=20 >>>>>>> - How is the SP supposed to know all the parties that it is >>>>>>> attesting=20 >>>>>>> to >>>>>>> - the responsible party and/or executing party? >>>>>>>=20 >>>>>>> -It seems likely that some of the numbers assigned to a company in >>>>>>> your scenario will not be assigned to real telephones (or call >>>>>>> center=20 >>>>>>> trunk) until a telemarketing campaign is initiated or a call center >>>>>>> selected to execute the sales campaign, is it possible to have thes= e >>>>>>> unassigned or floating numbers when not in use for a telemarketing >>>>>>> campaign? Is it allowed under most national numbering regimes? >>>>>>>=20 >>>>>>> - How important is it to have a known or recognized phone number as >>>>>>> the caller id as part of a telemarketing campaign? I am assuming >>>>>>> that not all campaigns care about having a number that is known or >>>>> recognized. >>>>>>>=20 >>>>>>> -In other words for this last bit, if a call center (telemarketing >>>>>>> campaign operator) is using their own set of numbers but serve >>>>>>> multiple simultaneous telemarketing campaigns using the same >>>>>>> originating numbers, what will they sign? Will they just have a >>>>>>> credential representing the call center alone, or a different >>>>>>> credential per telemarketing campaign, or a different credential pe= r >>>>>>> responsible party (per client)? This will affect what is possible >>>>>>> for >>>>> any forensic activity. >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behal= f >>>>>>> Of Brian Rosen >>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>> To: Fernando Mousinho >>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>=20 >>>>>>> We have a requirement to support the BPO use case. >>>>>>>=20 >>>>>>> The notion we had is that the company contracting the call center >>>>>>> approves the use, and the call center, or the SP acting on its >>>>>>> behalf, signs. >>>>>>> Think of this as another level of delegation. An SP delegates >>>>>>> numbers to the company. The company "delegates" use of those >>>>>>> numbers=20 >>>>>>> to the call center. The call center calls, using that delegation. >>>>>>> The credentials of the call center would be different from those of >>>>>>> the company, but would cover the same number. Having multiple >>>>>>> credentials covering the same number will be very common due to the >>>>>>> way delegation happens. In order to allow SPs to sign, without >>>>>>> creating credential per TN, we allow credentials with ranges. The >>>>>>> ranges could overlap when delegation happens. >>>>>>>=20 >>>>>>> Consider the following complex US case: >>>>>>> The North American Number Plan Administrator delegates 202-555-xxxx >>>>>>> to the Pooling Administrator. The PA now has a credential covering >>>>>>> the entire 10K block. >>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. SP A has >>>>>>> a=20 >>>>>>> credential for the entire 1K block SP A resells 202-555-12xx to SP = B >>>>>>> . >>>>>>> SP B has a credential for a 100 TN block SP B delegates 202-555-123= x >>>>>>> to Company C. Company C has a credential for a 10 number block >>>>>>> Company C authorizes 202-555-1234 to BPO D. BPO D has credential >>>>>>> for=20 >>>>>>> a 1 number block >>>>>>>=20 >>>>>>> NANPA and the PA never are in a call path, so they would never sign >>>>>>> a=20 >>>>>>> call. >>>>>>>=20 >>>>>>> However, SP A or SP B could sign a call from either Company C or BP= O >>>>>>> D using the credential they have. >>>>>>>=20 >>>>>>> The SP for the call center could acquire credentials from the BPO >>>>>>> and=20 >>>>>>> sign on its behalf. I suspect than many service providers would be >>>>>>> reluctant to do so unless the numbers were from their own inventory >>>>>>> (that is, the company got its numbers from the same SP as the call >>>>> center). >>>>>>> Since that won't be the common case, the call center probably has t= o >>>>>>> do the signing itself. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh) >>>>>>> wrote: >>>>>>>=20 >>>>>>>> I agree, Hadriel. While large call centers (including BPOs, which >>>>>>>> provide services for other companies) may have special arrangement= s >>>>>>>> with SPs, the majority (small to mid-size) will probably rely on >>>>>>>> the SPs to do provide to vouch for their identity. This would >>>>>>>> probably be the case for the home analog caller anyway. This would >>>>>>>> imply that the "originating" SP's willingness to provide this >>>>>>>> signature is a critical success factor for the proposal's adoption= . >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> But back to the business process outsourcers (BPO) case - where a >>>>>>>> call center is providing service on behalf of multiple companies. = I >>>>>>>> can see the value of them sending different numbers based on the >>>>>>>> clients they represent. Wouldn't that create a billing issue thoug= h? >>>>>>>> This is not an area I understand well, but I would suspect that SP >>>>>>>> 1 allowing one of its subscribers to send an outbound call using a >>>>>>>> number registered to SP 2 could be a no-no. If this hypothesis is >>>>>>>> correct, then we are back to the case where the SP is signing all >>>>>>>> calls, >>>>>> even for BPOs. >>>>>>>>=20 >>>>>>>> Or maybe this is another problem we are trying to fix in the >>>>>>>> working group, in which case we perhaps should state as a goal or >>>>> benefit: >>>>>>>> "providing a reliable mechanism to let calls originated from one >>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>=20 >>>>>>>> Fernando >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>> wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Any of them could do it. My guess is service providers will do i= t >>>>>>>>> for most call centers, although larger call centers might do it >>>>>>>>> themselves... >>>>>>>>> especially ones which have trunks from multiple providers and can >>>>>>>>> source calls using the same number(s) out through multiple >>>>>>>>> providers on a call-by-call basis. >>>>>>>>>=20 >>>>>>>>> -hadriel >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh) >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> I'm catching up with the discussions in this working group, and >>>>>>>>>> am trying to understand some architecture implications in call >>>>>>>>>> centers (which is where my background is). It seems that many of >>>>>>>>>> the problems we are trying to fix are related to contact centers >>>>>>>>>> anyway, so it is probably a good idea to have everyone in the >>>>>>>>>> same >>>>>> page. >>>>>>>>>>=20 >>>>>>>>>> Forgive me if it is an obvious question, but which components in >>>>>>>>>> a "typical call center architecture" do you see signature and >>>>>>>>>> verification taking place? Such "typical" deployments have >>>>>>>>>> premises based equipment (PME), a session border controller (SBC= ) >>>>>>>>>> and of course a SIP service provider all three could potentiall= y >>>>>>>>>> be used throughout the authorization process. There are differen= t >>>>>>>>>> ramifications depending on where your mind is at. >>>>>>>>>>=20 >>>>>>>>>> Fernando Mousinho >>>>>>>>>> Cisco Systems >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>=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=20 >>>>>>> you are not the intended recipient, please contact the sender and >>>>>>> delete all copies of the message. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>=20 >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Mon Oct 21 06:18:23 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1577011E8587 for ; Mon, 21 Oct 2013 06:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.423 X-Spam-Level: X-Spam-Status: No, score=-103.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 PdYGZrJJ5aVy for ; Mon, 21 Oct 2013 06:18:13 -0700 (PDT) Received: from mail-gg0-f173.google.com (mail-gg0-f173.google.com [209.85.161.173]) by ietfa.amsl.com (Postfix) with ESMTP id DE4EF11E8562 for ; Mon, 21 Oct 2013 06:15:49 -0700 (PDT) Received: by mail-gg0-f173.google.com with SMTP id e5so105978ggk.18 for ; Mon, 21 Oct 2013 06:15:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cD6gJ+4cJL5ba62EwUnyRev3cC+EiGwIunwuMg+MnLY=; b=NA0sPHP/6b2/yJT6vWs1pvIF8SMxtfnoKokhezG6BvvjJQmnykjkoMLwhkP9QKUbrH X3haxpwwIT6aNWJUYBKo5YAaIT5GRWsO2Pd1XwSEHvX2Hz4TPnGjHStv1dhqntzIEW+T vgO9QipPJgbxa+RiZ7TQQ31bIJPEt3dbFrRTTlCNbCJ2by3A/oI3ir/AkLhQ1ssCNcMJ GoLxJtrAaDDwyY5K010wu/KT/69vGGn+vWgiE4RRyt9IwwdMRuLIUuLfbAWyWy4s8ORF Gl3UXVWiEvS2vjWhubnNb3WCsRIGhTgxKnI06ncymptpSlJd8qVKfv0QUeRtTEcOIwLc WJog== X-Gm-Message-State: ALoCoQkhqsSNMWBcnlA7jm0pnFmkAKlBs3F67tlly/t+zGuyLHhQSeEc93+0gW1Mm8bciFDMO/nF X-Received: by 10.236.139.198 with SMTP id c46mr997031yhj.78.1382361348707; Mon, 21 Oct 2013 06:15:48 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 9sm26707510yhe.21.2013.10.21.06.15.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Oct 2013 06:15:48 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Brian Rosen In-Reply-To: Date: Mon, 21 Oct 2013 09:15:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> References: <71E3420F5D11314D8D989D8B72D247E129FE2079@xmb-aln-x06.cisco.com> <1B06BEFF-E7AC-4B30-B9D5-844E1192B4CB@brianrosen.net> To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1510) Cc: "Gregory.Schumacher@sprint.com" , Richard Shockey , Henning Schulzrinne , "stir@ietf.org" , Alex Bobotek , Michael Hammer , "Fernando Mousinho $fmousinh$" Subject: Re: [stir] Call Center Implications X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:18:23 -0000 We really need to give each BPO different keys I think. The notion = that we are sharing private keys among multiple competing entities who = provide services for a single enterprise strikes me as a VBI (Very Bad = Idea). I can't see any real difficulty in having more than one = authorized entity, each with it's own credentials. Who would have a = problem? We're already agreeing that there are multiple credentials for = a number, because the number gets delegated multiple times. Consider, = just as an example, the BPO and the contracting enterprise that was = actually delegated the number can both send calls from that number. You = certainly don't want the enterprise giving out IT'S key to it's = contractors. At best it's a key it authorizes to one or more of it's = BPOs. Brian On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy) = wrote: >=20 > What Fernando is saying makes sense to me a desirable property of the = solution and I agree that if we gave each BPO a different private key = that would solve it but that might be pretty hard to mange in other = ways. I like the requirements but the solution is not 100% obvious to = me.=20 >=20 >=20 > On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >=20 >> Sure. >>=20 >> Each BPO would have a different private/public key pair. >>=20 >> So you can trace which one placed the call. >>=20 >> Brian >>=20 >> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh) = wrote: >>=20 >>> Point taken on PAI, but am still struggling with this BPO model. = Apologies >>> upfront if this is obvious and I'm just failing to understand. >>>=20 >>> If the company hires several BPOs and authorizes all of them to sign = calls >>> on its behalf, is there a way to trace back the originator (specific = BPO) >>> later on? I suppose that at some level the actual caller must be = exposed >>> (perhaps to trace malicious activity, such as malicious person = infiltrated >>> in an otherwise legitimate BPO). >>>=20 >>> Via headers would be the obvious pick, but they don't survive the = plethora >>> of SBCs that the call is likely to transverse. Or maybe the certs >>> themselves can carry this type of data (actual caller identity). >>>=20 >>>=20 >>>=20 >>>=20 >>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>=20 >>>> Don't think that would work without related changes in the = networks. In >>>> some networks, PAI is used for called id. They would have to = change to >>>> use =46rom (if signed maybe). It also doesn't fit the definition = of PAI. >>>>=20 >>>> Brian >>>>=20 >>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh) >>>> wrote: >>>>=20 >>>>> Could a signed PAI be a potential solution to the BPO use case? = "From" >>>>> identifies the BPO, "PAI" the c >>>>> ompany hiring the BPO - based on the delegation process Rosen = mentions. >>>>> PAI's use is widespread, and it's main limitation is being = spoofable - >>>>> but this is exactly the problem we are trying to solve anyway. >>>>>=20 >>>>>=20 >>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey" = >>>>>> wrote: >>>>>>=20 >>>>>> Excellent point a profile or BCP to complement the work. >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf >>>>>> Of Alex >>>>>> Bobotek >>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com; >>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>> Cc: stir@ietf.org >>>>>> Subject: Re: [stir] Call Center Implications >>>>>>=20 >>>>>> +1 >>>>>> I've assumed that we are headed towards a "sign whatever extras = you >>>>>> wish, >>>>>> and indicate what your signature covers" mechanism. >>>>>>=20 >>>>>> Based on this, standards would need to identify only a minimal = subset >>>>>> of >>>>>> what shall/should be signed, and ensure that any required group = of >>>>>> signed >>>>>> items survives transit intact. >>>>>>=20 >>>>>> Best signing practices may be needed to complement the standard, = and an >>>>>> appropriate place for all but the most basic 'what to sign' >>>>>> recommendations. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Alex >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf >>>>>>> Of Henning Schulzrinne >>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>> To: Michael Hammer; fmousinh@cisco.com; = Gregory.Schumacher@sprint.com; >>>>>>> br@brianrosen.net >>>>>>> Cc: stir@ietf.org >>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>=20 >>>>>>> I see no reason not to allow signing any number-related field in = the >>>>>>> SIP request. (Signing may well be done by different parties.) >>>>>>>=20 >>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't = conveyable >>>>>>> in=20 >>>>>>> legacy systems, however, so this may be of somewhat limited use = for a >>>>>> while. >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of >>>>>>> Michael Hammer [michael.hammer@yaanatech.com] >>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com; >>>>>>> br@brianrosen.net >>>>>>> Cc: stir@ietf.org >>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>=20 >>>>>>> Don't we still want to know the true originator of the call, = even >>>>>>> when=20 >>>>>>> we have some token that says "Doctor so and so approved this = message." >>>>>>>=20 >>>>>>> Originating number, display number, and call-back number could = be 3 >>>>>>> different things. >>>>>>> Should all of them be verifiable? >>>>>>>=20 >>>>>>> Mike >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf >>>>>>> Of Fernando Mousinho (fmousinh) >>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>> Cc: stir@ietf.org >>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>=20 >>>>>>> I believe the scenario telemarketing here is when a client hires = a >>>>>>> BPO=20 >>>>>>> to place outbound calls, but expect customers to return these = calls >>>>>>> to=20 >>>>>>> a different place (say, their own and operated call center). = This >>>>>>> way,=20 >>>>>>> this client is authorizing the BPO to use an identity that it = (BPO) >>>>>> doesn't own. >>>>>>> These numbers in this scenario are always operational, just at a >>>>>>> different place. >>>>>>>=20 >>>>>>> The same telemarketing operator would then outpulse multiple = numbers >>>>>>> for their multiple clients, none of these numbers belonging to = the >>>>>> telemarketer. >>>>>>> BTW, we are using the term "telemarketing" in a very generic = sense - >>>>>>> this could just as easily be a public service announcement, >>>>>>> fundraiser, >>>>>> etc. >>>>>>>=20 >>>>>>> If the telemarketer happens to own the inbound call center as = well, >>>>>>> it=20 >>>>>>> very likely owns the number as well and this would necessarily = be a >>>>>>> special case >>>>>>> - it would fall under the same characteristics of any call = center. >>>>>>>=20 >>>>>>> On a different note, it would help a lot of we standardized >>>>>>> terminology. >>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it may = be >>>>>>> hard=20 >>>>>>> for others to follow the discussion later. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> (generic term for any type of outbound calling, including public >>>>>>> service announcement, so don't think it's all about sales!) >>>>>>>=20 >>>>>>>=20 >>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>> wrote: >>>>>>>=20 >>>>>>>> There are some benefits from this approach, but also some = scenarios >>>>>>>> that need clarification how they could function. >>>>>>>>=20 >>>>>>>> The benefit is that the credential represents both the company >>>>>>>> "responsible" for the sales campaign (the "company" in your >>>>>>>> scenario)=20 >>>>>>>> and the company operating the sales campaign (the call center = in >>>>>>>> your=20 >>>>>>>> scenario). For the use in forensics (after the fact analysis) = such >>>>>>>> as pursuit of fraud investigation, we then can follow both = paths. >>>>>>>>=20 >>>>>>>> However can you clarify the following - >>>>>>>> - If a SP "signs" the call, is it attesting to the = "responsible" >>>>>>>> party for the telemarketing call or the party executing the >>>>>>>> telemarketing campaign or both? >>>>>>>>=20 >>>>>>>> - How is the SP supposed to know all the parties that it is >>>>>>>> attesting=20 >>>>>>>> to >>>>>>>> - the responsible party and/or executing party? >>>>>>>>=20 >>>>>>>> -It seems likely that some of the numbers assigned to a company = in >>>>>>>> your scenario will not be assigned to real telephones (or call >>>>>>>> center=20 >>>>>>>> trunk) until a telemarketing campaign is initiated or a call = center >>>>>>>> selected to execute the sales campaign, is it possible to have = these >>>>>>>> unassigned or floating numbers when not in use for a = telemarketing >>>>>>>> campaign? Is it allowed under most national numbering regimes? >>>>>>>>=20 >>>>>>>> - How important is it to have a known or recognized phone = number as >>>>>>>> the caller id as part of a telemarketing campaign? I am = assuming >>>>>>>> that not all campaigns care about having a number that is known = or >>>>>> recognized. >>>>>>>>=20 >>>>>>>> -In other words for this last bit, if a call center = (telemarketing >>>>>>>> campaign operator) is using their own set of numbers but serve >>>>>>>> multiple simultaneous telemarketing campaigns using the same >>>>>>>> originating numbers, what will they sign? Will they just have = a >>>>>>>> credential representing the call center alone, or a different >>>>>>>> credential per telemarketing campaign, or a different = credential per >>>>>>>> responsible party (per client)? This will affect what is = possible >>>>>>>> for >>>>>> any forensic activity. >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf >>>>>>>> Of Brian Rosen >>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>> To: Fernando Mousinho >>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>=20 >>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>=20 >>>>>>>> The notion we had is that the company contracting the call = center >>>>>>>> approves the use, and the call center, or the SP acting on its >>>>>>>> behalf, signs. >>>>>>>> Think of this as another level of delegation. An SP delegates >>>>>>>> numbers to the company. The company "delegates" use of those >>>>>>>> numbers=20 >>>>>>>> to the call center. The call center calls, using that = delegation. >>>>>>>> The credentials of the call center would be different from = those of >>>>>>>> the company, but would cover the same number. Having multiple >>>>>>>> credentials covering the same number will be very common due to = the >>>>>>>> way delegation happens. In order to allow SPs to sign, without >>>>>>>> creating credential per TN, we allow credentials with ranges. = The >>>>>>>> ranges could overlap when delegation happens. >>>>>>>>=20 >>>>>>>> Consider the following complex US case: >>>>>>>> The North American Number Plan Administrator delegates = 202-555-xxxx >>>>>>>> to the Pooling Administrator. The PA now has a credential = covering >>>>>>>> the entire 10K block. >>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. SP A = has >>>>>>>> a=20 >>>>>>>> credential for the entire 1K block SP A resells 202-555-12xx to = SP B >>>>>>>> . >>>>>>>> SP B has a credential for a 100 TN block SP B delegates = 202-555-123x >>>>>>>> to Company C. Company C has a credential for a 10 number block >>>>>>>> Company C authorizes 202-555-1234 to BPO D. BPO D has = credential >>>>>>>> for=20 >>>>>>>> a 1 number block >>>>>>>>=20 >>>>>>>> NANPA and the PA never are in a call path, so they would never = sign >>>>>>>> a=20 >>>>>>>> call. >>>>>>>>=20 >>>>>>>> However, SP A or SP B could sign a call from either Company C = or BPO >>>>>>>> D using the credential they have. >>>>>>>>=20 >>>>>>>> The SP for the call center could acquire credentials from the = BPO >>>>>>>> and=20 >>>>>>>> sign on its behalf. I suspect than many service providers = would be >>>>>>>> reluctant to do so unless the numbers were from their own = inventory >>>>>>>> (that is, the company got its numbers from the same SP as the = call >>>>>> center). >>>>>>>> Since that won't be the common case, the call center probably = has to >>>>>>>> do the signing itself. >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh) >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = which >>>>>>>>> provide services for other companies) may have special = arrangements >>>>>>>>> with SPs, the majority (small to mid-size) will probably rely = on >>>>>>>>> the SPs to do provide to vouch for their identity. This would >>>>>>>>> probably be the case for the home analog caller anyway. This = would >>>>>>>>> imply that the "originating" SP's willingness to provide this >>>>>>>>> signature is a critical success factor for the proposal's = adoption. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> But back to the business process outsourcers (BPO) case - = where a >>>>>>>>> call center is providing service on behalf of multiple = companies. I >>>>>>>>> can see the value of them sending different numbers based on = the >>>>>>>>> clients they represent. Wouldn't that create a billing issue = though? >>>>>>>>> This is not an area I understand well, but I would suspect = that SP >>>>>>>>> 1 allowing one of its subscribers to send an outbound call = using a >>>>>>>>> number registered to SP 2 could be a no-no. If this hypothesis = is >>>>>>>>> correct, then we are back to the case where the SP is signing = all >>>>>>>>> calls, >>>>>>> even for BPOs. >>>>>>>>>=20 >>>>>>>>> Or maybe this is another problem we are trying to fix in the >>>>>>>>> working group, in which case we perhaps should state as a goal = or >>>>>> benefit: >>>>>>>>> "providing a reliable mechanism to let calls originated from = one >>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>=20 >>>>>>>>> Fernando >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" = >>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Any of them could do it. My guess is service providers will = do it >>>>>>>>>> for most call centers, although larger call centers might do = it >>>>>>>>>> themselves... >>>>>>>>>> especially ones which have trunks from multiple providers and = can >>>>>>>>>> source calls using the same number(s) out through multiple >>>>>>>>>> providers on a call-by-call basis. >>>>>>>>>>=20 >>>>>>>>>> -hadriel >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh) >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> I'm catching up with the discussions in this working group, = and >>>>>>>>>>> am trying to understand some architecture implications in = call >>>>>>>>>>> centers (which is where my background is). It seems that = many of >>>>>>>>>>> the problems we are trying to fix are related to contact = centers >>>>>>>>>>> anyway, so it is probably a good idea to have everyone in = the >>>>>>>>>>> same >>>>>>> page. >>>>>>>>>>>=20 >>>>>>>>>>> Forgive me if it is an obvious question, but which = components in >>>>>>>>>>> a "typical call center architecture" do you see signature = and >>>>>>>>>>> verification taking place? Such "typical" deployments have >>>>>>>>>>> premises based equipment (PME), a session border controller = (SBC) >>>>>>>>>>> and of course a SIP service provider all three could = potentially >>>>>>>>>>> be used throughout the authorization process. There are = different >>>>>>>>>>> ramifications depending on where your mind is at. >>>>>>>>>>>=20 >>>>>>>>>>> Fernando Mousinho >>>>>>>>>>> Cisco Systems >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>=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=20 >>>>>>>> you are not the intended recipient, please contact the sender = and >>>>>>>> delete all copies of the message. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From richard@shockey.us Mon Oct 21 15:11:02 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD8011E873E for ; Mon, 21 Oct 2013 15:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 W49rp5lDnhZ5 for ; Mon, 21 Oct 2013 15:10:57 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id D3A0A11E8776 for ; Mon, 21 Oct 2013 15:10:32 -0700 (PDT) Received: (qmail 26297 invoked by uid 0); 21 Oct 2013 22:10:10 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by qproxy1.mail.unifiedlayer.com with SMTP; 21 Oct 2013 22:10:10 -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:To:From; bh=GYyNRbAWXOJkl2eFLZ55OZMcHnJkeXfliIZM43WseAg=; b=GasmxqPxYmgeww+IKBUuQKwJfDWiSIWL/nSQBhBalu0iD6Ztp75fF9pGL/loMJHHFM/GwuV3Ct5SgQNRSBdXAY3j8Wb+j5HV6GQzofbDJSmP0MTqOgdNslWTImbLtcjZ; Received: from [198.154.186.163] (port=54033 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VYNfu-0001Sl-L2 for stir@ietf.org; Mon, 21 Oct 2013 16:10:10 -0600 From: "Richard Shockey" To: Date: Mon, 21 Oct 2013 18:10:07 -0400 Message-ID: <014a01ceceaa$4dc7b960$e9572c20$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014B_01CECE88.C6B61960" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac7OqkGMSl6vo2TWRKGNfU4q0GsBDA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 198.154.186.163 authed with richard@shockey.us} Subject: [stir] International enforcement agencies join forces to thwart caller identification spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:11:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014B_01CECE88.C6B61960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI . http://www.crtc.gc.ca/eng/com100/2013/r131021.htm#.UmWltlN8CaU Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_000_014B_01CECE88.C6B61960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI = …

http://www.crtc.gc.ca/eng/com100/2013/r131021.htm#.UmWl= tlN8CaU

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: = rshockey101
http//www.sipforum.org

"Money is the answer, what is the question?" = tm

------=_NextPart_000_014B_01CECE88.C6B61960-- From rjsparks@nostrum.com Wed Oct 23 14:55:21 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B024F11E8265 for ; Wed, 23 Oct 2013 14:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W1Aj-GHC8tX for ; Wed, 23 Oct 2013 14:55:20 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 395AC11E81C7 for ; Wed, 23 Oct 2013 14:55:18 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-224.dllstx.fios.verizon.net [173.57.89.224]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9NLt1sK054888 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Wed, 23 Oct 2013 16:55:02 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <526845B5.40400@nostrum.com> Date: Wed, 23 Oct 2013 16:55:01 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 173.57.89.224 is authenticated by a trusted mechanism) Subject: [stir] Next level of agenda detail X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 21:55:21 -0000 Stir WG - Below is the next level of detail for the agenda in Vancouver. As we indicated before, we'll spend the first session concentrating on the threats and requirements, and the second starting to explore mechanism. As you can see from the repository, we've only had one update to the mechanism drafts. Rather than simply going through the drafts during the second session, lets try to work through some major questions in the context of those drafts. With that in mind, we propose the following agenda: Tuesday, 5 November 2013: 1300-1400 10m Chairs/Administrivia 20m Problem statement - Jon Peterson http://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ draft-ietf-stir-problem-statement-00.txt 30m Threats - Jon Peterson http://datatracker.ietf.org/doc/draft-ietf-stir-threats/ draft-ietf-stir-threats-00.txt Wednesday, 6 November 2013, 1550-1720 5m Administrivia 25m Constraints on signature construction and validation: Jon Peterson - what fields are included in the signature? - should that list be configurable? 40m Credential Acquisition: Jon Peterson and Hadriel Kaplan - how can signers and verifiers obtain the appropriate credentials? - what does a verifier need to access credentials (a number, a number range, some other hint)? - is access to the credentials public or private? - are credentials associated with a single number, a range, or an arbitrary set? 20m Gatewaying: Hadriel Kaplan - what constraints do we have on signature construction so that the signature is likely to survive transition through other protocols (can we build something that can be passed through UUI?) Reading for the second session: http://datatracker.ietf.org/doc/draft-kaplan-stir-cider/ (draft-kaplan-stir-cider-00.txt) http://datatracker.ietf.org/doc/draft-kaplan-stir-ikes-out/ (draft-kaplan-stir-ikes-out-00.txt) http://datatracker.ietf.org/doc/draft-jennings-stir-rfc4474bis/ (draft-jennings-stir-rfc4474bis-00.txt) http://datatracker.ietf.org/doc/draft-rescorla-stir-fallback/ (draft-rescorla-stir-fallback-00.txt) From aallen@blackberry.com Thu Oct 24 09:09:36 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235F111E83AB for ; Thu, 24 Oct 2013 09:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_PRODUCT=0.333] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97uwvQC4Awb7 for ; Thu, 24 Oct 2013 09:09:30 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id A2AB911E83B4 for ; Thu, 24 Oct 2013 09:02:56 -0700 (PDT) Received: from xct103ads.rim.net ([10.67.111.44]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 24 Oct 2013 12:02:52 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.03.0123.003; Thu, 24 Oct 2013 11:02:51 -0500 From: Andrew Allen To: "stir@ietf.org" Thread-Topic: comments on draft-ietf-stir-problem-statement-00 Thread-Index: Ac7QUSi+XuSwVM/UQPSEhXox+oZw/g== Date: Thu, 24 Oct 2013 16:02:51 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E3BB2BXMB104ADSrimnet_" MIME-Version: 1.0 Subject: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:09:36 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3BB2BXMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Some comments on draft-ietf-stir-problem-statement-00. I only just joined t= he list so apologies if I am duplicating any comments already given. General comment could we preface the references in the text with the RFC (or other document= identifier) [1} in isolation makes the document hard to read. Section 5.3 Due to its narrow scope of applicability, and the details of its implementa= tion, VIPR has some significant limitations. The most salient for the purp= oses of this document is that it only has bearing on repeated communication= s between entities: it has solution to the classic "robocall" problem, wher= e the target typically receives a call from a number that has never called = before. Shouldn't this be it has NO solution to the classic "robocall" problem"? Section 6.1 I think it is problematic to use as an example the Apple proprietary iMessa= ge service which I believe is restricted to just the iOS platform (and Macs= ) and which does not allow "iPhone users to send SMS messages to one anoth= er over the internet" (SMS is a specific text only messaging service). I = think we should not reference a single company's proprietary product as the= re are many instant messaging applications/services out there for smartphon= es many of which now support multiple smartphone OS platforms (including al= so now my own employers BlackBerry Messaging Service) and which basically s= hare similar characteristics in terms of out of band communications and cen= tralized trusted databases as iMessage. I would think that a multiple plat= form supporting messaging service is likely to be much more useful as the = basis for a solution than a system that is restricted to single vendor's pl= atform. I think this text should be generalized to talk about mobile instant messag= ing services in the abstract and not describe a single vendors product offe= ring. Potentially a plurality of instant messaging services from multiple v= endors could form a basis for a general solution if instant messaging ends = up being part of the solution. Another issue to consider (and it's not just relevant for the use of insta= nt messaging) is the use of SIM roaming or "plastic roaming" where users wh= o are travelling use either a SIM from pool of company provided local SIM c= ards or purchase a local prepaid SIM card in order to eliminate roaming cha= rges. This means that the E.164 number of the user has changed but potentia= lly the identity used by the instant messaging service remains the same as = many mobile IM services identities are independent of the E.164 number bein= g instead tied to email addresses or device identities. In many cases the s= martphone doesn't even know its E.164 number - it does with IMS though. Section 6.5 Due to roaming and countless other factors, calls on the PSTN may emerge fr= om administrative domains that have no relationship with the number assignee I am not convinced that roaming (at least in the traditional sense of cellu= lar roaming - and this will continue to be the case with IMS roaming) means= that calls will emerge from administrative domains that have no relationsh= ip with the number assignee. In cellular roaming there is a very close rela= tionship between the roamed to network and there are trust domains between= them and authentication of the mobile involving cooperation between the ho= me network that is the number assignee and the roamed to network. If roamin= g here means something else then please clarify. Section 7 Accommodating current practices: Must allow number portability among carri= ers and must support legitimate usage of number spoofing(doctor's office an= d call centers) I think the text in parenthesis should be prepended with e.g. Minimal payload overhead: Must lead to minimal expansion of SIP headers fi= elds to avoid fragmentation in deployments that use UDP. Is this really a MUST strength requirement? Whatever solution we come up wi= th that requires enhancement to SIP requires some enhancement. TCP is alway= s available to use if message sizes become too large and since the deployed= systems will need to be enhanced they can be (even should be) enhanced to = support TCP. I think in many cases SIP and SDP has already grown to such an= extent (ICE candidates, preconditions, SDP cap neg attributes, increasing = number of codecs and media lines etc...) that we are already at the point w= here we are perilously close to or already over the 1300 byte recommendatio= n in many scenarios. Any size increase at all may break the camel's back o= n the UDP fragmentation issue. I think at best this is guidance that messag= e size is a factor to consider in evaluating a solution not an overriding r= equirement Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3BB2BXMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Some comments on draf= t-ietf-stir-problem-statement-00. I only just joined the list so apologies = if I am duplicating any comments already given.

General comment

could we preface the references in the text with the= RFC (or other document identifier) [1} in isolation makes the document har= d to read.

Section 5.3

Due to its narrow scope of applicability, and the details of its impleme= ntation, VIPR has some significant limitations. The most salient for = the purposes of this document is that it only has bearing on repeated communications between entities: it has solution to the classi= c "robocall" problem, where the target typically receives a call from a number that has never called before.

Shouldn’t this be it has NO solution to the cl= assic “robocall” problem”?

Section 6.1

I think it is problematic to use as an example the A= pple proprietary iMessage service which I believe is restricted to just the= iOS platform (and Macs) and which does not allow “iPhone users to &n= bsp;send SMS messages to one another over the internet” (SMS is a specific text only messaging service). &nb= sp;I think we should not reference a single company’s proprietary pro= duct as there are many instant messaging applications/services out there fo= r smartphones many of which now support multiple smartphone OS platforms (including also now my own employers BlackBerry Messaging Ser= vice) and which basically share similar characteristics in terms of out of = band communications and centralized trusted databases as iMessage. I = would think that a multiple platform supporting messaging service is likely to be much more useful as the= basis for a solution than a system that is restricted to single vendorR= 17;s platform.

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

Another issue to consider (and it’s not just r= elevant for the use of instant messaging) is the use of SIM roaming o= r “plastic roaming” where users who are travelling use either a= SIM from pool of company provided local SIM cards or purchase a local prepaid SIM card in order to eliminate roaming charges. This means= that the E.164 number of the user has changed but potentially the identity= used by the instant messaging service remains the same as many mobile IM s= ervices identities are independent of the E.164 number being instead tied to email addresses or device identi= ties. In many cases the smartphone doesn’t even know its E.164 number= – it does with IMS though.

Section 6.5

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

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

Section 7

Accommodating current practices:  Must allow number portabilit=
y among carriers and must support legitimate usage of number spoofing(docto=
r's office and call centers)

I think the text in parenthesis should be prepended with e.g.

Minimal payload overhead:  Must lead to minimal expansion of S=
IP headers fields to avoid fragmentation in deployments that use UDP.<=
/o:p>

Is this really a MUST strength requirement? Whatever solut= ion we come up with that requires enhancement to SIP requires some enhancem= ent. TCP is always available to use if message sizes become too large and since the deployed systems will need to be enha= nced they can be (even should be) enhanced to support TCP. I think in many = cases SIP and SDP has already grown to such an extent (ICE candidates, prec= onditions, SDP cap neg attributes, increasing number of codecs and media lines etc…) that we are alread= y at the point where we are perilously close to or already over the 1300 by= te recommendation in many scenarios. Any size increase at all may bre= ak the camel’s back on the UDP fragmentation issue. I think at best this is guidance that message size is a factor to c= onsider in evaluating a solution not an overriding requirement

Andrew

---------------------------------------------------------------------
Th= is transmission (including any attachments) may contain confidential inform= ation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immed= iately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by uni= ntended recipients is not authorized and may be unlawful.
--_000_BBF5DDFE515C3946BC18D733B20DAD2338E3BB2BXMB104ADSrimnet_-- From richard@shockey.us Fri Oct 25 10:28:49 2013 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B82C11E81BD for ; Fri, 25 Oct 2013 10:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.133 X-Spam-Level: X-Spam-Status: No, score=-101.133 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_PRODUCT=0.333, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YbKQ3hAWgWX for ; Fri, 25 Oct 2013 10:28:43 -0700 (PDT) Received: from oproxy17-pub.mail.unifiedlayer.com (oproxy17-pub.mail.unifiedlayer.com [74.220.201.171]) by ietfa.amsl.com (Postfix) with SMTP id 2E5EC11E81B6 for ; Fri, 25 Oct 2013 10:28:43 -0700 (PDT) Received: (qmail 7813 invoked by uid 0); 25 Oct 2013 17:28:32 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy17-pub.mail.unifiedlayer.com with SMTP; 25 Oct 2013 17:28:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=4KHkZPQFrxeFwhte6dCuEZyBy3g3dW1w4D1Wuolth2s=; b=Ae9lIeQSGmTkPcUvK0vyhR+4xfxOE2YZm+tyBL43PDWnStLOmHe+AAy06oc/P/u6sbQAfuo2l2h05AYhcg05EfvpUcZ9Z5szUMBuVQmLywShkmif9hb/sf1wX71nceWk; Received: from [71.114.100.16] (port=53924 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VZlBX-0000Vy-VT; Fri, 25 Oct 2013 11:28:32 -0600 From: "Richard Shockey" To: "'Andrew Allen'" , References: In-Reply-To: Date: Fri, 25 Oct 2013 13:28:29 -0400 Message-ID: <013b01ced1a7$9f3fb860$ddbf2920$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013C_01CED186.183125A0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI9gjN/fAuY/x0/yPzWV56VayXcYpkoR+6Q Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Telephone Identity Revisited