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