I have reviewed this draft in preparation for IETF LC, and= think it's ready to go. =A0I found a couple of minor nits, listed belo= w.

Thanks,

--Richard

NITS:

s/Protocols, like XMPP,/Other= protocols, such as XMPP,/

s/simiilar/similar/

s/as well as end system/as well as end systems/g

--047d7b339b1560994304f1bf2ad3-- From iesg-secretary@ietf.org Thu Feb 6 08:49:15 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896DD1A042A; Thu, 6 Feb 2014 08:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCM0ATBqpRvP; Thu, 6 Feb 2014 08:49:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 797011A03F7; Thu, 6 Feb 2014 08:49:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140206164914.25940.5263.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2014 08:49:14 -0800 Cc: stir@ietf.org Subject: [stir] Last Call: (Secure Telephone Identity Problem Statement) to Informational RFC X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 16:49:15 -0000 The IESG has received a request from the Secure Telephone Identity Revisited WG (stir) to consider the following document: - 'Secure Telephone Identity Problem Statement' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-02-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ballot/ No IPR declarations have been submitted directly on this I-D. From jon.peterson@neustar.biz Thu Feb 6 10:59:52 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4DC1A03C0 for ; Thu, 6 Feb 2014 10:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.301 X-Spam-Level: X-Spam-Status: No, score=-104.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G1OHpLgNgwz for ; Thu, 6 Feb 2014 10:59:50 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id DB5C01A00EA for ; Thu, 6 Feb 2014 10:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1391713339; x=1707069440; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=kR08p/LI5f CxLJbBQcW9ZqxwjUsAyuVe2X/t77jbV1Y=; b=AqRJ4eS1OYv0vBZ3skDjWxHJ60 3p3z1tA51oYwlaUsopmWNLXkdvQ9uiqKZIf+gNuiU9K4uhbLLGq8kPlv3jyg== Received: from ([10.31.58.71]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.40758918; Thu, 06 Feb 2014 14:02:18 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 6 Feb 2014 13:59:45 -0500 From: "Peterson, Jon" To: Paul Kyzivat , "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-threats-01.txt Thread-Index: AQHPIgwBRhCE4we7SU6UKa8P7pff3ZqnZV6AgAAPUICAAPAfgA== Date: Thu, 6 Feb 2014 18:59:45 +0000 Message-ID: References: <20140205004818.30915.38202.idtracker@ietfa.amsl.com> <52F294D9.2080005@nostrum.com> <52F2A1B1.5030708@alum.mit.edu> In-Reply-To: <52F2A1B1.5030708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.128.111] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: e2M07aNSJwhO+CrbwgQm8g== Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 18:59:53 -0000 Thanks for these notes, Paul. >Section 1 - Use of 'Caller ID' to mean the name of the calling party: > >Maybe I have the wrong understanding, but I consider the term "Caller >ID" to describe the delivery of the calling party number, or perhaps >both the number and optionally the name. I find it quite confusing to >see it used to mean just the delivery of the name, not the number. > >ISTM it would be better to use Caller ID to refer to the calling party >number, and another term for the calling party name. > >Wikipedia says: "Caller ID is made up of two separate pieces of >information: the calling number and the billing (or subscriber) name >where available." So that must be right. :-) Yeah, we=B9re trying to keep that straight, so I=B9ll replace any lingering misreferences to Caller ID with CPN. >Section 3.2 says: > > When a human callee is to be alerted at call setup time, the time > frame for executing any countermeasures is necessarily limited. > ... For text > messages, a delay for executing anti-impersonation countermeasures is > much less likely to degrade perceptible service. > >IMO this is frequently not the case. Often SMS-style text messages are >used in an interactive conversation style. In that case I suspect that >the delay sensitivity is similar to that for call setup type. Hmm. My intuition would be the other way. If you have to wait, say, ten seconds after receiving a call before you start alerting the callee, the caller may hang up - whether you=B9re playing ringing audio to the caller that whole time or (worse, I think) just dead air, they may lose patience. But if I=B9m getting a text message for the first time from an unfamiliar source, I don=B9t mind if its delivery is delayed ten or twenty seconds, if that will cut down significantly on spam. SMS delivery is unreliable, and senders are accustomed to not receiving immediate responses. In text message conversations where there=B9s quick back-and-forth, that delay might be intolerable, sure. But in those cases both parties have already established that they are participating in desired communications. So from a mechanism perspective, this is a case where you wouldn=B9t have t= o acquire new credentials, check delegation chains or what have you for each incoming message, provided messages from the same source use the same credentials.=20 Make sense? >Otherwise this seemed good to me. Thanks again, Jon Peterson Neustar, Inc. > Thanks, > Paul > >On 2/5/14 2:45 PM, Robert Sparks wrote: >> I'm working on the shepherd writeup for this draft. >> >> I'd like to hear from those that provided comments that they believe >> their comments have been addressed. >> >> I'd also very much like to hear from more people in the group that they >> read the document and believe it is ready to ship. >> >> RjS >> >> On 2/4/14, 6:48 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Secure Telephone Identity Revisited >>> Working Group of the IETF. >>> >>> Title : Secure Telephone Identity Threat Model >>> Author : Jon Peterson >>> Filename : draft-ietf-stir-threats-01.txt >>> Pages : 11 >>> Date : 2014-02-04 >>> >>> 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-01 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-threats-01 >>> >>> >>> 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 >> >> _______________________________________________ >> 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 york@isoc.org Thu Feb 6 12:06:56 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DE41A0472 for ; Thu, 6 Feb 2014 12:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 327bietA5Erx for ; Thu, 6 Feb 2014 12:06:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id 82D351A0458 for ; Thu, 6 Feb 2014 12:06:52 -0800 (PST) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB241.namprd06.prod.outlook.com (10.242.191.148) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 20:06:49 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.117]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.77]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 20:06:49 +0000 From: Dan York To: Robert Sparks , "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-threats-01.txt Thread-Index: AQHPIgv+TU1Mt2a8wEe8JLbFMf0W95qnEY2AgAFEdoA= Date: Thu, 6 Feb 2014 20:06:48 +0000 Message-ID: In-Reply-To: <52F294D9.2080005@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.4] x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(479174003)(377454003)(24454002)(199002)(189002)(56816005)(90146001)(2656002)(46102001)(81342001)(47446002)(87266001)(31966008)(93136001)(74706001)(81816001)(81542001)(74876001)(76176001)(85306002)(79102001)(92566001)(51856001)(36756003)(77096001)(80022001)(54316002)(49866001)(47736001)(76482001)(56776001)(86362001)(65816001)(93516002)(87936001)(74662001)(54356001)(92726001)(74366001)(94946001)(19580405001)(76786001)(77982001)(59766001)(50986001)(80976001)(83072002)(74502001)(63696002)(4396001)(47976001)(85852003)(19580395003)(83322001)(81686001)(76796001)(94316002)(69226001)(53806001)(95416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB241; H:BLUPR06MB243.namprd06.prod.outlook.com; CLIP:10.255.101.4; FPR:FE2CF2F6.86FA5D01.31D9714B.4EF5D161.20514; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 20:06:56 -0000 Robert, On 2/5/14 2:45 PM, "Robert Sparks" wrote: >I'd also very much like to hear from more people in the group that they >read the document and believe it is ready to ship. I have read the document and have no fundamental objection to publishing. I have only several editorial comments for Jon's consideration. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. In section one, I found this paragraph a bit confusing, particularly the last sentence: ---- In SIP and even many traditional telephone protocols, call signaling can be renegotiated after the call has been established. Using various transfer mechanisms common in telephone systems, a callee can easily be connected to, or conferenced in with, telephone numbers other than the original calling number once a call has been established. These post-setup changes to the call are outside the scope of impersonation considered in this model. Furthermore, impersonating a reached number to the originator of a call is outside the scope of this threat model. ---- Specifically the use of "reached number" is something I don't see anywhere else in the document. I also just find it strange to have that last sentence tacked on to a paragraph that covers another topic. It might be better as something like: ---- In SIP and even many traditional telephone protocols, call signaling can be renegotiated after the call has been established. Using various transfer mechanisms common in telephone systems, a callee can easily be connected to, or conferenced in with, telephone numbers other than the original calling number once a call has been established. These post-setup changes to the call are outside the scope of impersonation considered in this model. Furthermore, this threat model does not include in its scope the verification of the called party number back to the originator of the call. There is no assurance to the originator that they are reaching the correct number. This threat model is focused only on verifying the caller party number to the callee. ---- Maybe that's too wordy but I think it would be helpful to those trying to understand STIR to be clear that spoofing the called party number is out of scope. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2. In section "3.1. Voicemail Hacking via Impersonation", the end of the first paragraph says: ---- the attacker may try to impersonate the calling party number using one of the scenarios described below. ---- I'm not clear what the "scenarios described below" are as I don't see any scenarios in this section 3.1. Is it referring to the later section 4? If so, you might want to reword it along the lines of "the scenarios describe in the later section on "Attack Scenarios"." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. In section "3.2. Unsolicited Commercial Calling from Impersonated Numbers", third paragaph: ---- If there were a service that could inform the terminating side of that it should expect an identity signature in calls or texts from that number, however, that would also help in the robocalling case. ---- The "of that it" doesn't work in my brain. I think the "of" needs to be dropped. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4. In section "3.3. Telephony Denial-of-Service Attacks", first paragraph, there is an extra "a" in "attaacks": ---- These attaacks might target a business, an individual or a public resource like emergency responders; the attack may intend to extort the target or have other motivations. ---- I also personally don't like this usage of the semi-colon and might suggest these would be best as two separate sentences... but that's a style thing. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. In section "4. Attack Scenarios", the acronyms "CPN" and "IAM" are used without expansion in the first paragraph and then CPN is defined in the second paragraph. It might be better to put "PSTN-PSTN" first. I don't know whether "IAM" warrants expanding. I also would suggest putting "IP-IP" first in the scenarios given that most folks reading this should be familiar with SIP and that is by far the easiest example for people to understand. The flow of the scenarios could be:=20 IP-IP PSTN-PSTN IP-PSTN IP-PSTN-IP ---- Impersonation, IP-PSTN An attacker on the Internet uses a commercial WebRTC service to send a call to the PSTN with a chosen calling party number. The service contacts an Internet-to-PSTN gateway, which inserts the attacker's chosen calling party number into the SS7 call setup message (the CPN field of an IAM). When the call setup message reaches the terminating telephone switch, the terminal renders the attacker's chosen calling party number as the calling identity. Impersonation, PSTN-PSTN An attacker with a traditional PBX (connected to the PSTN through ISDN) sends a Q.931 SETUP request with a chosen calling party number which a service provider inserts into the corresponding SS7 calling party number (CPN) field of a call setup message (IAM). When the call setup message reaches the endpoint switch, the terminal renders the attacker's chosen calling party number as the calling identity. ---- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 6. In section "4. Attack Scenarios", the term "calling identity" is used at the end of each scenario in the text "the terminal renders the attacker's chosen calling party number as the calling identity." That's the only usage of that phrase in the document. I don't know that this is wrong, but I just wondered if it was in keeping with the terminology that is being used across other STIR documents. (And I don't really have an alternative that comes to my mind.) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards, Dan From pkyzivat@alum.mit.edu Thu Feb 6 13:09:04 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507E31A0508 for ; Thu, 6 Feb 2014 13:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7oz2skP5PxU for ; Thu, 6 Feb 2014 13:09:03 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id E535C1A0506 for ; Thu, 6 Feb 2014 13:09:02 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id P7mq1n0031YDfWL59991sX; Thu, 06 Feb 2014 21:09:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id P9911n00D3ZTu2S3g991Mf; Thu, 06 Feb 2014 21:09:01 +0000 Message-ID: <52F3F9ED.7080205@alum.mit.edu> Date: Thu, 06 Feb 2014 16:09:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Peterson, Jon" , "stir@ietf.org" References: <20140205004818.30915.38202.idtracker@ietfa.amsl.com> <52F294D9.2080005@nostrum.com> <52F2A1B1.5030708@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391720941; bh=G+omgjC4crXBYLqhvc2h9AJmDEsBH37r/oOpvbBuTBo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rqZaGbok0/52oqtdYXrNT44vqm1E7VtFlEMFgmjR5dGJmVQ4RDkIkX6O1QFxBSUvQ cQcrURG2tyJoRrACgE17LIzZo0wnqNpoYsINcNcdPOH+1+zbmBF4ROavA9sXD6oCCS 94xYsczK798zHSMQ/rNoVn8VXgj7ogdJgy1ck5h8lyMQN1nW+UfJhp5nJ5oDv2C3Hr kKsIIlPFR6soJOMJSEBqE+J9oc5k2OMh4dlycZ3WGNNGQZ8trSaLEO9eW8casH9BjZ gUB4SoiSeiosA8YNe6jxPTINM+CeLiylmx8aL3TeqhgNSpFBBfSUeWQsrrWEido1JR PdNrxWVzMiOfA== Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 21:09:04 -0000 On 2/6/14 1:59 PM, Peterson, Jon wrote: > > Thanks for these notes, Paul. > >> Section 1 - Use of 'Caller ID' to mean the name of the calling party: >> >> Maybe I have the wrong understanding, but I consider the term "Caller >> ID" to describe the delivery of the calling party number, or perhaps >> both the number and optionally the name. I find it quite confusing to >> see it used to mean just the delivery of the name, not the number. >> >> ISTM it would be better to use Caller ID to refer to the calling party >> number, and another term for the calling party name. >> >> Wikipedia says: "Caller ID is made up of two separate pieces of >> information: the calling number and the billing (or subscriber) name >> where available." So that must be right. :-) > > Yeah, we�re trying to keep that straight, so I�ll replace any lingering > misreferences to Caller ID with CPN. Thx. >> Section 3.2 says: >> >> When a human callee is to be alerted at call setup time, the time >> frame for executing any countermeasures is necessarily limited. >> ... For text >> messages, a delay for executing anti-impersonation countermeasures is >> much less likely to degrade perceptible service. >> >> IMO this is frequently not the case. Often SMS-style text messages are >> used in an interactive conversation style. In that case I suspect that >> the delay sensitivity is similar to that for call setup type. > > Hmm. My intuition would be the other way. If you have to wait, say, ten > seconds after receiving a call before you start alerting the callee, the > caller may hang up - whether you�re playing ringing audio to the caller > that whole time or (worse, I think) just dead air, they may lose patience. > But if I�m getting a text message for the first time from an unfamiliar > source, I don�t mind if its delivery is delayed ten or twenty seconds, if > that will cut down significantly on spam. SMS delivery is unreliable, and > senders are accustomed to not receiving immediate responses. > > In text message conversations where there�s quick back-and-forth, that > delay might be intolerable, sure. But in those cases both parties have > already established that they are participating in desired communications. > So from a mechanism perspective, this is a case where you wouldn�t have to > acquire new credentials, check delegation chains or what have you for each > incoming message, provided messages from the same source use the same > credentials. > > Make sense? *If* the delay is only on the first message, then fine. It was the quick back-and-forth that I was concerned with. If all the delay is in the endpoint, and it can skip the rechecking then fine. I was imagining that the delay would be from some intermediary that wouldn't have the history to do that. Thanks, Paul From jon.peterson@neustar.biz Thu Feb 6 16:15:06 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051A01A0577 for ; Thu, 6 Feb 2014 16:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npIvudMSEmpR for ; Thu, 6 Feb 2014 16:15:03 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3170E1A0573 for ; Thu, 6 Feb 2014 16:15:03 -0800 (PST) Received: from stntexhc11.cis.neustar.com (unknown [10.31.58.70]) by stihiron1.va.neustar.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 7c02_424f_6ec24246_528f_4301_ae7d_4aff9b87d342; Thu, 06 Feb 2014 19:14:44 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 6 Feb 2014 19:14:43 -0500 From: "Peterson, Jon" To: Dan York , Robert Sparks , "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-threats-01.txt Thread-Index: AQHPIgwBRhCE4we7SU6UKa8P7pff3ZqnZV6AgAGYSgD//78jgA== Date: Fri, 7 Feb 2014 00:14:42 +0000 Message-ID: References: <52F294D9.2080005@nostrum.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.9.131030 x-originating-ip: [192.168.128.111] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: /XaqwfrFCUEcH8+b3HIWZQ== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <49D637EDFB0D7B45AF7D3E01F981D08F@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 00:15:06 -0000 Thanks Dan, some notes below. >1. In section one, I found this paragraph a bit confusing, particularly >the last sentence: >---- > In SIP and even many traditional telephone protocols, call signaling > can be renegotiated after the call has been established. Using > various transfer mechanisms common in telephone systems, a callee can > easily be connected to, or conferenced in with, telephone numbers > other than the original calling number once a call has been > established. These post-setup changes to the call are outside the > scope of impersonation considered in this model. Furthermore, > impersonating a reached number to the originator of a call is outside > the scope of this threat model. > >---- > >Specifically the use of "reached number" is something I don't see anywhere >else in the document. I also just find it strange to have that last >sentence tacked on to a paragraph that covers another topic. It might be >better as something like: > >---- > In SIP and even many traditional telephone protocols, call signaling >can be renegotiated after the call has been established. Using >various transfer mechanisms common in telephone systems, a callee can >easily be connected to, or conferenced in with, telephone numbers >other than the original calling number once a call has been >established. These post-setup changes to the call are outside the >scope of impersonation considered in this model. > >Furthermore, this threat model does not include in its scope the >verification of >the called party number back to the originator of the call. There is no >assurance to the originator that they are reaching the correct number. >This >threat model is focused only on verifying the caller party number to the >callee. >---- I=B9m fine splitting this into two as you suggest. The reason why these things were lumped into one paragraph is that all these sentences show that the only form of telephone identity in scope of this thread model is the kind conveyed to identify the originator of a call. > >Maybe that's too wordy but I think it would be helpful to those trying to >understand STIR to be clear that spoofing the called party number is out >of scope. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >2. In section "3.1. Voicemail Hacking via Impersonation", the end of the >first paragraph says: >---- > the > attacker may try to impersonate the calling party number using one of > the scenarios described below. >---- >I'm not clear what the "scenarios described below" are as I don't see any >scenarios in this section 3.1. Is it referring to the later section 4? >If so, you might want to reword it along the lines of "the scenarios >describe in the later section on "Attack Scenarios"." I=B9ll just put in a ref to that section. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >3. In section "3.2. Unsolicited Commercial Calling from Impersonated >Numbers", third paragaph: >---- >If there were a service that > could inform the terminating side of that it should expect an > identity signature in calls or texts from that number, however, that > would also help in the robocalling case. >---- > >The "of that it" doesn't work in my brain. I think the "of" needs to be >dropped. I think you=B9re right. Well caught. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >4. In section "3.3. Telephony Denial-of-Service Attacks", first >paragraph, there is an extra "a" in "attaacks": The extra a=B9s is for emphasis, as in =B3attaaaaaaaack!=B2 No really, I=B9= ll fix it. >---- >These attaacks might target a > business, an individual or a public resource like emergency > > responders; the attack may intend to extort the target or have other > motivations. > >---- >I also personally don't like this usage of the semi-colon and might >suggest these would be best as two separate sentences... but that's a >style thing. =20 > I think I like that semicolon. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >5. In section "4. Attack Scenarios", the acronyms "CPN" and "IAM" are used > without expansion in the first paragraph and then CPN is defined in the >second paragraph. It might be better to put "PSTN-PSTN" first. I don't >know whether "IAM" warrants expanding. We probably should just put a ref to Q.761 or something in here, and maybe Q.931 as well. The draft is really reference-light. >I also would suggest putting "IP-IP" first in the scenarios given that >most folks reading this should be familiar with SIP and that is by far the >easiest example for people to understand. The flow of the scenarios could >be:=20 >IP-IP >PSTN-PSTN >IP-PSTN >IP-PSTN-IP No strong feelings here; I can shuffle these. >---- > Impersonation, IP-PSTN > > An attacker on the Internet uses a commercial WebRTC service to send > a call to the PSTN with a chosen calling party number. The service > contacts an Internet-to-PSTN gateway, which inserts the attacker's > chosen calling party number into the SS7 call setup message (the CPN > field of an IAM). When the call setup message reaches the > terminating telephone switch, the terminal renders the attacker's > chosen calling party number as the calling identity. > > Impersonation, PSTN-PSTN > > An attacker with a traditional PBX (connected to the PSTN through > ISDN) sends a Q.931 SETUP request with a chosen calling party number > which a service provider inserts into the corresponding SS7 calling > party number (CPN) field of a call setup message (IAM). When the > call setup message reaches the endpoint switch, the terminal renders > the attacker's chosen calling party number as the calling identity. > >---- > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >6. In section "4. Attack Scenarios", the term "calling identity" is used >at the end of each scenario in the text "the terminal renders the >attacker's chosen calling party number as the calling identity." That's >the only usage of that phrase in the document. I don't know that this is >wrong, but I just wondered if it was in keeping with the terminology that >is being used across other STIR documents. (And I don't really have an >alternative that comes to my mind.) Erm. It=B9s probably okay. Thanks again, Jon Peterson Neustar, Inc. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Regards, >Dan > > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From travis.russell@oracle.com Thu Feb 6 20:18:24 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD381A034B for ; Thu, 6 Feb 2014 20:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vblQ0RA5RZm7 for ; Thu, 6 Feb 2014 20:18:22 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8719E1A0346 for ; Thu, 6 Feb 2014 20:18:22 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s174IJnX026977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Feb 2014 04:18:19 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s174II2m027214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Feb 2014 04:18:19 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s174IIIv028326; Fri, 7 Feb 2014 04:18:18 GMT MIME-Version: 1.0 Message-ID: Date: Thu, 6 Feb 2014 20:18:17 -0800 (PST) From: Travis Russell To: X-Mailer: Zimbra on Oracle Beehive Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 04:18:24 -0000 FYI - I am leaving Dubai today after a week of discussions at the GSMA Frau= d Forum meetings here. This topic of SIP spoofing comes around quite a bit = within this group as these are the folks who have to deal with the fall-out= . Might be a good group to review the finished document as they understand = the issues and business implications better than anyone. If that is of inte= rest to the group let me know and I can help facilitate. ----- Original Message ----- From: jon.peterson@neustar.biz To: pkyzivat@alum.mit.edu, stir@ietf.org Sent: Thursday, February 6, 2014 11:00:07 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-01.txt Thanks for these notes, Paul. >Section 1 - Use of 'Caller ID' to mean the name of the calling party: > >Maybe I have the wrong understanding, but I consider the term "Caller >ID" to describe the delivery of the calling party number, or perhaps >both the number and optionally the name. I find it quite confusing to >see it used to mean just the delivery of the name, not the number. > >ISTM it would be better to use Caller ID to refer to the calling party >number, and another term for the calling party name. > >Wikipedia says: "Caller ID is made up of two separate pieces of >information: the calling number and the billing (or subscriber) name >where available." So that must be right. :-) Yeah, we=C2=B9re trying to keep that straight, so I=C2=B9ll replace any lin= gering misreferences to Caller ID with CPN. >Section 3.2 says: > > When a human callee is to be alerted at call setup time, the time > frame for executing any countermeasures is necessarily limited. > ... For text > messages, a delay for executing anti-impersonation countermeasures is > much less likely to degrade perceptible service. > >IMO this is frequently not the case. Often SMS-style text messages are >used in an interactive conversation style. In that case I suspect that >the delay sensitivity is similar to that for call setup type. Hmm. My intuition would be the other way. If you have to wait, say, ten seconds after receiving a call before you start alerting the callee, the caller may hang up - whether you=C2=B9re playing ringing audio to the calle= r that whole time or (worse, I think) just dead air, they may lose patience. But if I=C2=B9m getting a text message for the first time from an unfamilia= r source, I don=C2=B9t mind if its delivery is delayed ten or twenty seconds,= if that will cut down significantly on spam. SMS delivery is unreliable, and senders are accustomed to not receiving immediate responses. In text message conversations where there=C2=B9s quick back-and-forth, that delay might be intolerable, sure. But in those cases both parties have already established that they are participating in desired communications. So from a mechanism perspective, this is a case where you wouldn=C2=B9t hav= e to acquire new credentials, check delegation chains or what have you for each incoming message, provided messages from the same source use the same credentials.=20 Make sense? >Otherwise this seemed good to me. Thanks again, Jon Peterson Neustar, Inc. >=09Thanks, >=09Paul > >On 2/5/14 2:45 PM, Robert Sparks wrote: >> I'm working on the shepherd writeup for this draft. >> >> I'd like to hear from those that provided comments that they believe >> their comments have been addressed. >> >> I'd also very much like to hear from more people in the group that they >> read the document and believe it is ready to ship. >> >> RjS >> >> On 2/4/14, 6:48 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Secure Telephone Identity Revisited >>> Working Group of the IETF. >>> >>> Title : Secure Telephone Identity Threat Model >>> Author : Jon Peterson >>> Filename : draft-ietf-stir-threats-01.txt >>> Pages : 11 >>> Date : 2014-02-04 >>> >>> 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-01 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-threats-01 >>> >>> >>> 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 >> >> _______________________________________________ >> 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 Oracle Travis Russell | Technologist |=20 +1919.460.2172 (o) | +1919.412.1167 (c)=20 Oracle CGBU Product Marketing=20 5200 Paramount Pkwy=20 Morrisville, NC 27560=20 USA=20 Green Oracle=09Oracle is committed to developing practices and products tha= t help protect the environment=20 From anton@ministry.int.ru Mon Feb 10 00:15:32 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7221A009A for ; Mon, 10 Feb 2014 00:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.27 X-Spam-Level: ** X-Spam-Status: No, score=2.27 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUGbb0NSsFAM for ; Mon, 10 Feb 2014 00:15:31 -0800 (PST) Received: from leaf.named.informdeskmedia.ru (leaf.named.informdeskmedia.ru [85.17.236.2]) by ietfa.amsl.com (Postfix) with ESMTP id E57AB1A054E for ; Mon, 10 Feb 2014 00:15:30 -0800 (PST) Received: from [178.71.97.153] (account postmaster@leaf.named.informdeskmedia.ru HELO firepaw) by leaf.named.informdeskmedia.ru (CommuniGate Pro SMTP 6.0.4 _community_) with ESMTPSA id 2310059; Mon, 10 Feb 2014 12:15:29 +0400 Date: Mon, 10 Feb 2014 10:15:04 +0200 From: Anton Baskov To: Michael Hammer Message-Id: <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 08:15:32 -0000 I think that by default canonization should be possible only if we have any additional informational header with tel: uri to allow canonization. But, if this header is accidentally missed, we can still guess full E.164 number and if will match STIR signature we can be sure that all is ok, but if phone number we guessed don’t match signature we don’t know – is it a problem with signature or we just guessed wrong number. By the way, additional field can be helpful if we would like to have signed call from local numbers, like tel:112 (911) and other numbers that can’t be routed globally. -- Anton Baskov +7 (911) 254-77-92, +7 (916) 716-89-46 On Sat, 1 Feb 2014 17:51:13 +0000 Michael Hammer wrote: > We seem to have this confusion repeated from time to time. > > Local prefixes that tell the switch whether the entered digits are local, > national, or international number are not part of the E.164 number. > A proper switch knows not to include such prefixes as part of the E.164 > number. > This is a case of "if it hurts to do something confusing, then stop doing it > that way." > > Also, the domain part after the @ sign is not part of the E.164 number, and > so should not be confused with any operation that STIR might make. > > So, I guess bottom line, am agreeing with Brian that we need to have > explicit guidance for STIR about all the rules about processing numbers, > again. > > Michael Hammer > Principal Engineer > michael.hammer@yaanatech.com > Mobile: +1 408-202-9291 > 500 Yosemite Drive Suite 120 > Milpitas, CA 95035 USA > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Friday, January 31, 2014 4:21 PM > To: Anton Baskov > Cc: stir@ietf.org List > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > > This is a good point. > > We probably have to say that if the rules we agree to do not result in a a > proper e.164, and the call is sent beyond the local domain, that the From > must be changed to be able to be canonicalized by the rules. > > Brian > > On Jan 30, 2014, at 5:49 AM, Anton Baskov wrote: > > > Some notes about phone number canonization described in Cullen's STIR > Signaling presentation and section "7. Identity and Telephone Numbers" of > draft-jennings-stir-rfc4474bis: > > > > There is a problem with telephone number canonization that in some cases > we can't assume right number judging on sip uri, because some countries uses > international access codes different that recommended by ITU. For example, > at Russia dial out code is "8" for long distance calls and "8 - 10" for > international calls, and most local operators use such number representation > in their voip systems, so looking at "sip:8495..." number we can't suppose > is that call from Moscow (+7495...) or it's from Vietnam (+84...). Also I > saw two voip operators that use internal account number as right side of > client sip uri - it's make a possibility to make false phone number > assumption by clients. In this case I think that we should have at least > information header with full tel: uri or limit canonization procedure only > to "sip:+..@domain"-like uri. > > > > > > -- > > Anton Baskov > > +7 (911) 254-77-92, +7 (916) 716-89-46 > > _______________________________________________ > > 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 Mon Feb 10 06:23:47 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0501A086B for ; Mon, 10 Feb 2014 06:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyFJmRkc34Ud for ; Mon, 10 Feb 2014 06:23:43 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 99AB01A0868 for ; Mon, 10 Feb 2014 06:23:40 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id ar20so3514266iec.34 for ; Mon, 10 Feb 2014 06:23:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=BNskwA6v8/pRhptApXsdb59iv3LoGgYanmbRoWezMsc=; b=BtyF4lVRXmqd9TU57lhpK6czDOvxyWGxpLaxjKWwzJBceeDOvLgLpyKp/wOOjLAj8Z 5wabDShP+Le8M8oUcXXveGeZNLdlZSSbvmdNYLevkuOc8T34mvUIlqH84fL2/wpnuEdh k0Cc5H9NOwPIErPSpr9AqWe7xnRiK+saZcCMiITDFQW32rUJJzvf1wqY79fQGgNkYHE7 IFOAUcAAf49WlHpBAMvynKOF181BIqjLft8TncL/w8VDM8AtxfUHOFiyCot278NfCmGL U21dxk6YfP1p3RbW7uUehPRWDqGjGSeIuHk/0Qc7J4O3/gm+MKSW8DKQYwtv+ez0dhuK t4hA== X-Gm-Message-State: ALoCoQmWZYDoJH8eanMvXrBXXaunbHOZWIgFvmaKfaKozVKKFe2kwv41w940+2vDEPhZiTqnhJaR X-Received: by 10.43.155.84 with SMTP id lh20mr584837icc.81.1392042218875; Mon, 10 Feb 2014 06:23:38 -0800 (PST) Received: from [10.33.193.26] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id ml2sm42755042igb.10.2014.02.10.06.23.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 06:23:38 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 $1827$) From: Brian Rosen In-Reply-To: <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> Date: Mon, 10 Feb 2014 09:23:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> To: Anton Baskov X-Mailer: Apple Mail (2.1827) Cc: "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:23:47 -0000 I think we=92re proposing to describe an algorithm in our document that = turns the From/PAI into a canonical e.164. We need some rules for what = happens when the algorithm fails. The origination side can test this = and determine if it needs to do anything. So, it=92s not a =93guess=94. Brian On Feb 10, 2014, at 3:15 AM, Anton Baskov wrote: > I think that by default canonization should be possible only if we = have any additional informational header with tel: uri to allow = canonization. But, if this header is accidentally missed, we can still = guess full E.164 number and if will match STIR signature we can be sure = that all is ok, but if phone number we guessed don=92t match signature = we don=92t know =96 is it a problem with signature or we just guessed = wrong number. >=20 > By the way, additional field can be helpful if we would like to have = signed call from local numbers, like tel:112 (911) and other numbers = that can=92t be routed globally. >=20 > --=20 > Anton Baskov > +7 (911) 254-77-92, +7 (916) 716-89-46 >=20 > On Sat, 1 Feb 2014 17:51:13 +0000 > Michael Hammer wrote: >=20 >> We seem to have this confusion repeated from time to time. >>=20 >> Local prefixes that tell the switch whether the entered digits are = local, >> national, or international number are not part of the E.164 number. >> A proper switch knows not to include such prefixes as part of the = E.164 >> number. >> This is a case of "if it hurts to do something confusing, then stop = doing it >> that way." >>=20 >> Also, the domain part after the @ sign is not part of the E.164 = number, and >> so should not be confused with any operation that STIR might make. >>=20 >> So, I guess bottom line, am agreeing with Brian that we need to have >> explicit guidance for STIR about all the rules about processing = numbers, >> again. >>=20 >> Michael Hammer >> Principal Engineer >> michael.hammer@yaanatech.com >> Mobile: +1 408-202-9291 >> 500 Yosemite Drive Suite 120 >> Milpitas, CA 95035 USA >>=20 >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >> Sent: Friday, January 31, 2014 4:21 PM >> To: Anton Baskov >> Cc: stir@ietf.org List >> Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 >>=20 >> This is a good point. >>=20 >> We probably have to say that if the rules we agree to do not result = in a a >> proper e.164, and the call is sent beyond the local domain, that the = From >> must be changed to be able to be canonicalized by the rules. >>=20 >> Brian >>=20 >> On Jan 30, 2014, at 5:49 AM, Anton Baskov = wrote: >>=20 >>> Some notes about phone number canonization described in Cullen's = STIR >> Signaling presentation and section "7. Identity and Telephone = Numbers" of >> draft-jennings-stir-rfc4474bis: >>>=20 >>> There is a problem with telephone number canonization that in some = cases >> we can't assume right number judging on sip uri, because some = countries uses >> international access codes different that recommended by ITU. For = example, >> at Russia dial out code is "8" for long distance calls and "8 - 10" = for >> international calls, and most local operators use such number = representation >> in their voip systems, so looking at "sip:8495..." number we can't = suppose >> is that call from Moscow (+7495...) or it's from Vietnam (+84...). = Also I >> saw two voip operators that use internal account number as right side = of >> client sip uri - it's make a possibility to make false phone number >> assumption by clients. In this case I think that we should have at = least >> information header with full tel: uri or limit canonization procedure = only >> to "sip:+..@domain"-like uri. >>>=20 >>>=20 >>> --=20 >>> Anton Baskov >>> +7 (911) 254-77-92, +7 (916) 716-89-46 >>> _______________________________________________ >>> 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 From pkyzivat@alum.mit.edu Mon Feb 10 07:05:43 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E7A1A0871 for ; Mon, 10 Feb 2014 07:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LSFPD85OOtH for ; Mon, 10 Feb 2014 07:05:38 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 037731A086C for ; Mon, 10 Feb 2014 07:05:37 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id Qe3n1n0040QuhwU5Cf5dQg; Mon, 10 Feb 2014 15:05:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id Qf5d1n01E3ZTu2S3Nf5dFd; Mon, 10 Feb 2014 15:05:37 +0000 Message-ID: <52F8EAC1.2090701@alum.mit.edu> Date: Mon, 10 Feb 2014 10:05:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: stir@ietf.org References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> In-Reply-To: <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392044737; bh=wDA7+LUtqpTl8ZtnrrFEaUj+X9DGKOPTng3em/A5s90=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LnSreRFbwZ/O5JUho3mdd41U+bCkZxYbw+rbWv4JkcvS4CqB/tE51KzIcJ3yTQro/ qsqzaIsuXLgksRlNYeA+IiYujY5Wcco4OYtjFB5D5j62fXQ1aE3ADgGWlO/LikK3Km hCh1Hv1A5rZzsgXXhtGgTBWTwc+XYQ+WWsJe0fZw3RmuNDav7Vw68kEGR3WV8mcAFP xLcWYL5YtWRgxhucJ8zaa3742J5Wwcdii8vvNPkNMnosYDIy0jwuWc6ND+Hs6TSTDn AeNZwKv08I+mi/E5vfDt0e4AlOVV7hWZzw6nXMts0CWES90bCheJbIsYksvEqKulw2 xTNg1GJrzr96g== Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:05:43 -0000 On 2/10/14 3:15 AM, Anton Baskov wrote: > I think that by default canonization should be possible only if we have any additional informational header with tel: uri to allow canonization. But, if this header is accidentally missed, we can still guess full E.164 number and if will match STIR signature we can be sure that all is ok, but if phone number we guessed don’t match signature we don’t know – is it a problem with signature or we just guessed wrong number. > > By the way, additional field can be helpful if we would like to have signed call from local numbers, like tel:112 (911) and other numbers that can’t be routed globally. Note: tel:112 and tel:911 are invalid syntax for a tel uri. 112 isn't an E.164. To be syntactically valid it requires a parameter. E.g., tel:112;phone-context=+44, tel:911;phone-context=+1 But is there really a case where we need to sign these? We are talking about signing From, not To. I don't expect to get a call with one of these as From. Thanks, Paul From michael.hammer@yaanatech.com Mon Feb 10 07:09:25 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C8C1A0879 for ; Mon, 10 Feb 2014 07:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS69XXcjNYW7 for ; Mon, 10 Feb 2014 07:09:23 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id AFD161A0871 for ; Mon, 10 Feb 2014 07:09:23 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 07:09:23 -0800 From: Michael Hammer To: "pkyzivat@alum.mit.edu" , "stir@ietf.org" Thread-Topic: [stir] Comment on draft-jennings-stir-rfc4474bis-00 Thread-Index: AQHPHakXeh5A9RY73U6WW9EQZxSv+5qfewSAgAE0IGCADgwMAIAAcrWA//96WQA= Date: Mon, 10 Feb 2014 15:09:22 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF26DBC@sc9-ex2k10mb1.corp.yaanatech.com> References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> <52F8EAC1.2090701@alum.mit.edu> In-Reply-To: <52F8EAC1.2090701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.77] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0096_01CF2648.2AB63A00" MIME-Version: 1.0 Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:09:26 -0000 ------=_NextPart_000_0096_01CF2648.2AB63A00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think that this is opening Pandora's box. They are essentially = service codes that are localized. There could be literally thousands of termination points that those = codes go to. Not sure it helps to have calls coming from those numbers, signed or = not. We should stick to the current scope of worrying about E.164 telephone = numbers. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, February 10, 2014 10:06 AM To: stir@ietf.org Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 On 2/10/14 3:15 AM, Anton Baskov wrote: > I think that by default canonization should be possible only if we = have any additional informational header with tel: uri to allow = canonization. But, if this header is accidentally missed, we can still = guess full E.164 number and if will match STIR signature we can be sure = that all is ok, but if phone number we guessed don=E2=80=99t match = signature we don=E2=80=99t know =E2=80=93 is it a problem with signature = or we just guessed wrong number. > > By the way, additional field can be helpful if we would like to have = signed call from local numbers, like tel:112 (911) and other numbers = that can=E2=80=99t be routed globally. Note: tel:112 and tel:911 are invalid syntax for a tel uri. 112 isn't an E.164. To be syntactically valid it requires a parameter.=20 E.g., tel:112;phone-context=3D+44, tel:911;phone-context=3D+1 But is there really a case where we need to sign these? We are talking = about signing From, not To. I don't expect to get a call with one of = these as From. Thanks, Paul _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0096_01CF2648.2AB63A00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIx MDE1MDkyMVowIwYJKoZIhvcNAQkEMRYEFOpdxPK8bbjzlzoU2S2ErqtEr9n6MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAewgbjJowaLc0+ZLKKciqifC/+SWehltML8cjDZrA wJKIMmtARPgY6mYpbuBwPl0syki9Qp5WZ8Bcg7SLJ4uhUH5tMl5ZwrKQ1AXayGq0Ym7B4Ju38xMU KhfjQL0Mgt3gz6gQ0GcX0Qcq3emYZ0c8vAgcRLwnHfFSLWFzoHc9mCph8j8yEuijtcV78rhZ2R5v QjGm8YZAHD0r5lGa4xEXgSc3mP5+B8dwzUbfMkCwfY3soHMDypUohjnAz1CtxX+HMkml2TW6tU8y D9f97SD3JwAGXYR1ApdSsyHSC9zT1gAQ0RpFXxxlFwJK3kAmq6A3B9xFO4zXwQfE6mTBI6gspwAA AAAAAA== ------=_NextPart_000_0096_01CF2648.2AB63A00-- From alex@bobotek.net Mon Feb 10 10:16:37 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDA21A00EE for ; Mon, 10 Feb 2014 10:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaCLcWs2Qjse for ; Mon, 10 Feb 2014 10:16:34 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id BE4FE1A01F1 for ; Mon, 10 Feb 2014 10:16:34 -0800 (PST) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta11.emeryville.ca.mail.comcast.net with comcast id QfVr1n0071wfjNsABiGasL; Mon, 10 Feb 2014 18:16:34 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by omta23.emeryville.ca.mail.comcast.net with comcast id QiGZ1n0064EJ4tY8jiGZxG; Mon, 10 Feb 2014 18:16:34 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Mon, 10 Feb 2014 10:13:17 -0800 From: Alex Bobotek To: Michael Hammer , "pkyzivat@alum.mit.edu" , "stir@ietf.org" Date: Mon, 10 Feb 2014 10:16:29 -0800 Thread-Topic: [stir] Comment on draft-jennings-stir-rfc4474bis-00 Thread-Index: AQHPHakXeh5A9RY73U6WW9EQZxSv+5qfewSAgAE0IGCADgwMAIAAcrWA//96WQCAAC4GwA== Message-ID: <4B1956260CD29F4A9622F00322FE0531EC8D239F04@BOBO1A.bobotek.net> References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> <52F8EAC1.2090701@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BBF26DBC@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF26DBC@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4B1956260CD29F4A9622F00322FE0531EC8D239F04BOBO1Abobotek_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392056194; bh=hyr4KiMn9LB4w33wg8+WxzcYXSgH321Ql7q13+4pWiY=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=Al0iJfP+sYYrn/BjuEV6wHRgGmLz8XjQHu3Z+B5/srWo484rK8HVzN+guF1Lik5II mes4OU9vrqkpL/MIthGQdzAnv3WckKV3cJFHyyYnENU+yzjO1R0VvRWKJ0438O8r8O z4AaFLg32xi40+ii/13cCOGiaMsYoziNb8wIG1XIZf8Q79B/l4A50nr3fIC4uJ4+W1 +hhTcBmE367itmIT9sBts43n5bSzf6QwUbTlKW8PxzFk1XNnbgkFAtkOetD5ZkhGnC MMQbpNRzEcD6OZfPtjJic/g2JrUBaViNArzhAGSQXvxHpzvcNoBM6dnMYSFjbnzaaf lHKGL1hcgGbrQ== Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 18:16:37 -0000 --_000_4B1956260CD29F4A9622F00322FE0531EC8D239F04BOBO1Abobotek_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KV2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IGxvY2FsIG51bWJlcmluZyBuZWVkcyB0byBi ZSBzdXBwb3J0ZWQgKGFuIGFzc3VtcHRpb24gd2hpY2ggSSBzdXBwb3J0KSwgdGhlcmUgYXJlIHR3 byBub24tZXhjbHVzaXZlIGVuZm9yY2VtZW50IGNob2ljZXM6DQoNCiogcHJvdmlkZSBhbiBlbmRw b2ludCAob3IgaXRzIHByb3h5KSB3aXRoIHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gd2l0aCB3aGlj aCB0byBlbmZvcmNlIHBvbGljeSAtLSBzcGVjaWZpY2FsbHk6DQogICAgICAgIC0gaXRzIG93biBj b250ZXh0IGFuZA0KICAgICAgICAtIHRoZSBjb250ZXh0IG9mIHRoZSBjYWxsZXINCiAgICAgICAg LSBjb250ZXh0KHMpIGF1dGhvcml6ZWQgZm9yIHRoZSBjYWxsZXINCg0KKiByZWx5IG9uIG5ldHdv cmtzIHRvIGJsb2NrIHVuYXV0aG9yaXplZCBjYWxsaW5nIGNvbnRleHRzIChlLmcuLCBsb2NhbCBu dW1iZXJpbmcgc2NoZW1lcykgZnJvbSByZWFjaGluZyBhIGNhbGxlZCBlbmRwb2ludA0KDQpDdXJy ZW50bHkgdGhlIGxhdHRlciBpcyBpbiBwbGFjZTsgaXQncyByZWFzb25hYmxlIHRvIGFzc3VtZSB0 aGF0IGl0IHdpbGwgcmVtYWluIHNvLg0KDQotLS0tDQoNCkFub3RoZXIgY29tbWVudCBpbiByZWFj dGlvbiB0byBhIGNlcnQgaXNzdWVkIGJ5IGEgM3JkIHBhcnR5IG5vbi10ZWxlcGhvbnktU1A6DQoN CkkgZG9uJ3QgYmVsaWV2ZSBhIHNlY3VyZSBjYWxsaW5nIGVudmlyb25tZW50IGludGVyb3BlcmFi bGUgd2l0aCB0aGUgUFNUTiBjYW4gYmUgZXN0YWJsaXNoZWQgd2l0aG91dCBhIG1lY2hhbmlzbSBp biB3aGljaCBhbiBvcmlnaW5hdGluZyBzZXJ2aWNlIHByb3ZpZGVyIHRha2VzIHJlc3BvbnNpYmls aXR5IGZvciAoaS5lLiwgc2lnbnMpIGFuIG9yaWdpbmF0aW5nIGNhbGwuICBJcyB0aGlzIGEgdG9w aWMgZm9yIGRpc2N1c3Npb24gb3IgZ2VuZXJhbGx5IGFncmVlZD8NCg0KUmVnYXJkcywNCg0KQWxl eA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHN0aXIgW21haWx0bzpz dGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsIEhhbW1lcg0KPiBTZW50 OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDc6MDkgQU0NCj4gVG86IHBreXppdmF0QGFsdW0u bWl0LmVkdTsgc3RpckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3N0aXJdIENvbW1lbnQgb24g ZHJhZnQtamVubmluZ3Mtc3Rpci1yZmM0NDc0YmlzLTAwDQo+DQo+IEkgdGhpbmsgdGhhdCB0aGlz IGlzIG9wZW5pbmcgUGFuZG9yYSdzIGJveC4gIFRoZXkgYXJlIGVzc2VudGlhbGx5IHNlcnZpY2Ug Y29kZXMNCj4gdGhhdCBhcmUgbG9jYWxpemVkLg0KPiBUaGVyZSBjb3VsZCBiZSBsaXRlcmFsbHkg dGhvdXNhbmRzIG9mIHRlcm1pbmF0aW9uIHBvaW50cyB0aGF0IHRob3NlIGNvZGVzIGdvDQo+IHRv Lg0KPiBOb3Qgc3VyZSBpdCBoZWxwcyB0byBoYXZlIGNhbGxzIGNvbWluZyBmcm9tIHRob3NlIG51 bWJlcnMsIHNpZ25lZCBvciBub3QuDQo+DQo+IFdlIHNob3VsZCBzdGljayB0byB0aGUgY3VycmVu dCBzY29wZSBvZiB3b3JyeWluZyBhYm91dCBFLjE2NCB0ZWxlcGhvbmUNCj4gbnVtYmVycy4NCj4N Cj4gTWljaGFlbCBIYW1tZXINCj4gUHJpbmNpcGFsIEVuZ2luZWVyDQo+IG1pY2hhZWwuaGFtbWVy QHlhYW5hdGVjaC5jb208bWFpbHRvOm1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20+DQo+IE1v YmlsZTogKzEgNDA4LTIwMi05MjkxDQo+IDUwMCBZb3NlbWl0ZSBEcml2ZSBTdWl0ZSAxMjANCj4g TWlscGl0YXMsIENBIDk1MDM1IFVTQQ0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUGF1bCBLeXppdmF0DQo+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMTA6MDYg QU0NCj4gVG86IHN0aXJAaWV0Zi5vcmc8bWFpbHRvOnN0aXJAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6 IFJlOiBbc3Rpcl0gQ29tbWVudCBvbiBkcmFmdC1qZW5uaW5ncy1zdGlyLXJmYzQ0NzRiaXMtMDAN Cj4NCj4gT24gMi8xMC8xNCAzOjE1IEFNLCBBbnRvbiBCYXNrb3Ygd3JvdGU6DQo+ID4gSSB0aGlu ayB0aGF0IGJ5IGRlZmF1bHQgY2Fub25pemF0aW9uIHNob3VsZCBiZSBwb3NzaWJsZSBvbmx5IGlm IHdlIGhhdmUgYW55DQo+IGFkZGl0aW9uYWwgaW5mb3JtYXRpb25hbCBoZWFkZXIgd2l0aCB0ZWw6 IHVyaSB0byBhbGxvdyBjYW5vbml6YXRpb24uIEJ1dCwgaWYgdGhpcw0KPiBoZWFkZXIgaXMgYWNj aWRlbnRhbGx5IG1pc3NlZCwgd2UgY2FuIHN0aWxsIGd1ZXNzIGZ1bGwgRS4xNjQgbnVtYmVyIGFu ZCBpZiB3aWxsDQo+IG1hdGNoIFNUSVIgc2lnbmF0dXJlIHdlIGNhbiBiZSBzdXJlIHRoYXQgYWxs IGlzIG9rLCBidXQgaWYgcGhvbmUgbnVtYmVyIHdlDQo+IGd1ZXNzZWQgZG9u4oCZdCBtYXRjaCBz aWduYXR1cmUgd2UgZG9u4oCZdCBrbm93IOKAkyBpcyBpdCBhIHByb2JsZW0gd2l0aA0KPiBzaWdu YXR1cmUgb3Igd2UganVzdCBndWVzc2VkIHdyb25nIG51bWJlci4NCj4gPg0KPiA+IEJ5IHRoZSB3 YXksIGFkZGl0aW9uYWwgZmllbGQgY2FuIGJlIGhlbHBmdWwgaWYgd2Ugd291bGQgbGlrZSB0byBo YXZlIHNpZ25lZA0KPiBjYWxsIGZyb20gbG9jYWwgbnVtYmVycywgbGlrZSB0ZWw6MTEyICg5MTEp IGFuZCBvdGhlciBudW1iZXJzIHRoYXQgY2Fu4oCZdCBiZQ0KPiByb3V0ZWQgZ2xvYmFsbHkuDQo+ DQo+IE5vdGU6IHRlbDoxMTIgYW5kIHRlbDo5MTEgYXJlIGludmFsaWQgc3ludGF4IGZvciBhIHRl bCB1cmkuDQo+DQo+IDExMiBpc24ndCBhbiBFLjE2NC4gVG8gYmUgc3ludGFjdGljYWxseSB2YWxp ZCBpdCByZXF1aXJlcyBhIHBhcmFtZXRlci4NCj4gRS5nLiwgdGVsOjExMjtwaG9uZS1jb250ZXh0 PSs0NCwgdGVsOjkxMTtwaG9uZS1jb250ZXh0PSsxDQo+DQo+IEJ1dCBpcyB0aGVyZSByZWFsbHkg YSBjYXNlIHdoZXJlIHdlIG5lZWQgdG8gc2lnbiB0aGVzZT8gV2UgYXJlIHRhbGtpbmcgYWJvdXQN Cj4gc2lnbmluZyBGcm9tLCBub3QgVG8uIEkgZG9uJ3QgZXhwZWN0IHRvIGdldCBhIGNhbGwgd2l0 aCBvbmUgb2YgdGhlc2UgYXMgRnJvbS4NCj4NCj4gICAgICAgVGhhbmtzLA0KPiAgICAgICBQYXVs DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHN0aXIgbWFpbGluZyBsaXN0DQo+IHN0aXJAaWV0Zi5vcmc8bWFpbHRvOnN0aXJAaWV0 Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KDQo= --_000_4B1956260CD29F4A9622F00322FE0531EC8D239F04BOBO1Abobotek_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzaXplPSIy Ij4NCjxkaXY+JiM0MzsxPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5XaXRoIHRoZSBh c3N1bXB0aW9uIHRoYXQgbG9jYWwgbnVtYmVyaW5nIG5lZWRzIHRvIGJlIHN1cHBvcnRlZCAoYW4g YXNzdW1wdGlvbiB3aGljaCBJIHN1cHBvcnQpLCB0aGVyZSBhcmUgdHdvIG5vbi1leGNsdXNpdmUg ZW5mb3JjZW1lbnQgY2hvaWNlczo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiogcHJv dmlkZSBhbiBlbmRwb2ludCAob3IgaXRzIHByb3h5KSB3aXRoIHN1ZmZpY2llbnQgaW5mb3JtYXRp b24gd2l0aCB3aGljaCB0byBlbmZvcmNlIHBvbGljeSAtLSBzcGVjaWZpY2FsbHk6PC9kaXY+DQo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIGl0cyBvd24g Y29udGV4dCBhbmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0gdGhlIGNvbnRleHQgb2YgdGhlIGNhbGxlcjwvZGl2Pg0KPGRpdj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBjb250ZXh0KHMpIGF1dGhvcml6 ZWQgZm9yIHRoZSBjYWxsZXI8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiogcmVseSBv biBuZXR3b3JrcyB0byBibG9jayB1bmF1dGhvcml6ZWQgY2FsbGluZyBjb250ZXh0cyAoZS5nLiwg bG9jYWwgbnVtYmVyaW5nIHNjaGVtZXMpIGZyb20gcmVhY2hpbmcgYSBjYWxsZWQgZW5kcG9pbnQ8 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjxiPkN1cnJlbnRseSB0aGUgbGF0dGVyIGlz IGluIHBsYWNlOyBpdCdzIHJlYXNvbmFibGUgdG8gYXNzdW1lIHRoYXQgaXQgd2lsbCByZW1haW4g c28uJm5ic3A7IDwvYj48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0tLS08L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFub3RoZXIgY29tbWVudCBpbiByZWFjdGlvbiB0byBh IGNlcnQgaXNzdWVkIGJ5IGEgM3JkIHBhcnR5IG5vbi10ZWxlcGhvbnktU1A6PC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIGRvbid0IGJlbGlldmUgYSBzZWN1cmUgY2FsbGluZyBlbnZp cm9ubWVudCBpbnRlcm9wZXJhYmxlIHdpdGggdGhlIFBTVE4gY2FuIGJlIGVzdGFibGlzaGVkIHdp dGhvdXQgYSBtZWNoYW5pc20gaW4gd2hpY2ggYW4gb3JpZ2luYXRpbmcgc2VydmljZSBwcm92aWRl ciB0YWtlcyByZXNwb25zaWJpbGl0eSBmb3IgKGkuZS4sIHNpZ25zKSBhbiBvcmlnaW5hdGluZyBj YWxsLiZuYnNwOyBJcyB0aGlzIGEgdG9waWMgZm9yIGRpc2N1c3Npb24gb3IgZ2VuZXJhbGx5DQph Z3JlZWQ/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+QWxleDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+ Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZGl2Pg0KPGRpdj4mZ3Q7IEZyb206IHN0 aXIgWzxhIGhyZWY9Im1haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzdGlyLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWljaGFlbCBIYW1tZXI8L2Rpdj4NCjxk aXY+Jmd0OyBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDc6MDkgQU08L2Rpdj4NCjxk aXY+Jmd0OyBUbzogcGt5eml2YXRAYWx1bS5taXQuZWR1OyBzdGlyQGlldGYub3JnPC9kaXY+DQo8 ZGl2PiZndDsgU3ViamVjdDogUmU6IFtzdGlyXSBDb21tZW50IG9uIGRyYWZ0LWplbm5pbmdzLXN0 aXItcmZjNDQ3NGJpcy0wMDwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IEkgdGhp bmsgdGhhdCB0aGlzIGlzIG9wZW5pbmcgUGFuZG9yYSdzIGJveC4mbmJzcDsgVGhleSBhcmUgZXNz ZW50aWFsbHkgc2VydmljZSBjb2RlczwvZGl2Pg0KPGRpdj4mZ3Q7IHRoYXQgYXJlIGxvY2FsaXpl ZC48L2Rpdj4NCjxkaXY+Jmd0OyBUaGVyZSBjb3VsZCBiZSBsaXRlcmFsbHkgdGhvdXNhbmRzIG9m IHRlcm1pbmF0aW9uIHBvaW50cyB0aGF0IHRob3NlIGNvZGVzIGdvPC9kaXY+DQo8ZGl2PiZndDsg dG8uPC9kaXY+DQo8ZGl2PiZndDsgTm90IHN1cmUgaXQgaGVscHMgdG8gaGF2ZSBjYWxscyBjb21p bmcgZnJvbSB0aG9zZSBudW1iZXJzLCBzaWduZWQgb3Igbm90LjwvZGl2Pg0KPGRpdj4mZ3Q7IDwv ZGl2Pg0KPGRpdj4mZ3Q7IFdlIHNob3VsZCBzdGljayB0byB0aGUgY3VycmVudCBzY29wZSBvZiB3 b3JyeWluZyBhYm91dCBFLjE2NCB0ZWxlcGhvbmU8L2Rpdj4NCjxkaXY+Jmd0OyBudW1iZXJzLjwv ZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IE1pY2hhZWwgSGFtbWVyPC9kaXY+DQo8 ZGl2PiZndDsgUHJpbmNpcGFsIEVuZ2luZWVyPC9kaXY+DQo8ZGl2PiZndDsgPGEgaHJlZj0ibWFp bHRvOm1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20iPm1pY2hhZWwuaGFtbWVyQHlhYW5hdGVj aC5jb208L2E+PC9kaXY+DQo8ZGl2PiZndDsgTW9iaWxlOiAmIzQzOzEgNDA4LTIwMi05MjkxPC9k aXY+DQo8ZGl2PiZndDsgNTAwIFlvc2VtaXRlIERyaXZlIFN1aXRlIDEyMDwvZGl2Pg0KPGRpdj4m Z3Q7IE1pbHBpdGFzLCBDQSA5NTAzNSBVU0E8L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rpdj4NCjxkaXY+ Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZGl2Pg0K PGRpdj4mZ3Q7IEZyb206IHN0aXIgWzxhIGhyZWY9Im1haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5v cmciPm1haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgUGF1bCBL eXppdmF0PC9kaXY+DQo8ZGl2PiZndDsgU2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCAx MDowNiBBTTwvZGl2Pg0KPGRpdj4mZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86c3RpckBpZXRmLm9y ZyI+c3RpckBpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+Jmd0OyBTdWJqZWN0OiBSZTogW3N0aXJd IENvbW1lbnQgb24gZHJhZnQtamVubmluZ3Mtc3Rpci1yZmM0NDc0YmlzLTAwPC9kaXY+DQo8ZGl2 PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgT24gMi8xMC8xNCAzOjE1IEFNLCBBbnRvbiBCYXNrb3Yg d3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBJIHRoaW5rIHRoYXQgYnkgZGVmYXVsdCBjYW5v bml6YXRpb24gc2hvdWxkIGJlIHBvc3NpYmxlIG9ubHkgaWYgd2UgaGF2ZSBhbnk8L2Rpdj4NCjxk aXY+Jmd0OyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uYWwgaGVhZGVyIHdpdGggdGVsOiB1cmkgdG8g YWxsb3cgY2Fub25pemF0aW9uLiBCdXQsIGlmIHRoaXM8L2Rpdj4NCjxkaXY+Jmd0OyBoZWFkZXIg aXMgYWNjaWRlbnRhbGx5IG1pc3NlZCwgd2UgY2FuIHN0aWxsIGd1ZXNzIGZ1bGwgRS4xNjQgbnVt YmVyIGFuZCBpZiB3aWxsPC9kaXY+DQo8ZGl2PiZndDsgbWF0Y2ggU1RJUiBzaWduYXR1cmUgd2Ug Y2FuIGJlIHN1cmUgdGhhdCBhbGwgaXMgb2ssIGJ1dCBpZiBwaG9uZSBudW1iZXIgd2U8L2Rpdj4N CjxkaXY+Jmd0OyBndWVzc2VkIGRvbuKAmXQgbWF0Y2ggc2lnbmF0dXJlIHdlIGRvbuKAmXQga25v dyDigJMgaXMgaXQgYSBwcm9ibGVtIHdpdGg8L2Rpdj4NCjxkaXY+Jmd0OyBzaWduYXR1cmUgb3Ig d2UganVzdCBndWVzc2VkIHdyb25nIG51bWJlci48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+ DQo8ZGl2PiZndDsgJmd0OyBCeSB0aGUgd2F5LCBhZGRpdGlvbmFsIGZpZWxkIGNhbiBiZSBoZWxw ZnVsIGlmIHdlIHdvdWxkIGxpa2UgdG8gaGF2ZSBzaWduZWQ8L2Rpdj4NCjxkaXY+Jmd0OyBjYWxs IGZyb20gbG9jYWwgbnVtYmVycywgbGlrZSA8YSBocmVmPSJ0ZWw6MTEyIj50ZWw6MTEyPC9hPiAo OTExKSBhbmQgb3RoZXIgbnVtYmVycyB0aGF0IGNhbuKAmXQgYmU8L2Rpdj4NCjxkaXY+Jmd0OyBy b3V0ZWQgZ2xvYmFsbHkuPC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgTm90ZTog PGEgaHJlZj0idGVsOjExMiI+dGVsOjExMjwvYT4gYW5kIDxhIGhyZWY9InRlbDo5MTEiPnRlbDo5 MTE8L2E+IGFyZSBpbnZhbGlkIHN5bnRheCBmb3IgYSB0ZWwgdXJpLjwvZGl2Pg0KPGRpdj4mZ3Q7 IDwvZGl2Pg0KPGRpdj4mZ3Q7IDExMiBpc24ndCBhbiBFLjE2NC4gVG8gYmUgc3ludGFjdGljYWxs eSB2YWxpZCBpdCByZXF1aXJlcyBhIHBhcmFtZXRlci48L2Rpdj4NCjxkaXY+Jmd0OyBFLmcuLCA8 YSBocmVmPSJ0ZWw6MTEyO3Bob25lLWNvbnRleHQ9JiM0Mzs0NCI+dGVsOjExMjtwaG9uZS1jb250 ZXh0PSYjNDM7NDQ8L2E+LCA8YSBocmVmPSJ0ZWw6OTExO3Bob25lLWNvbnRleHQ9JiM0MzsxIj50 ZWw6OTExO3Bob25lLWNvbnRleHQ9JiM0MzsxPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0K PGRpdj4mZ3Q7IEJ1dCBpcyB0aGVyZSByZWFsbHkgYSBjYXNlIHdoZXJlIHdlIG5lZWQgdG8gc2ln biB0aGVzZT8gV2UgYXJlIHRhbGtpbmcgYWJvdXQ8L2Rpdj4NCjxkaXY+Jmd0OyBzaWduaW5nIEZy b20sIG5vdCBUby4gSSBkb24ndCBleHBlY3QgdG8gZ2V0IGEgY2FsbCB3aXRoIG9uZSBvZiB0aGVz ZSBhcyBGcm9tLjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8L2Rpdj4NCjxkaXY+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYXVsPC9kaXY+DQo8ZGl2 PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4N CjxkaXY+Jmd0OyBzdGlyIG1haWxpbmcgbGlzdDwvZGl2Pg0KPGRpdj4mZ3Q7IDxhIGhyZWY9Im1h aWx0bzpzdGlyQGlldGYub3JnIj5zdGlyQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RpciI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyPC9hPjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4B1956260CD29F4A9622F00322FE0531EC8D239F04BOBO1Abobotek_-- From internet-drafts@ietf.org Mon Feb 10 11:49:03 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A1D1A03C9; Mon, 10 Feb 2014 11:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dW5LRtB_EB4G; Mon, 10 Feb 2014 11:49:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4991A01A8; Mon, 10 Feb 2014 11:49:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210194900.22227.78629.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 11:49:00 -0800 Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-threats-02.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:49:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited Working Group of the IETF. Title : Secure Telephone Identity Threat Model Author : Jon Peterson Filename : draft-ietf-stir-threats-02.txt Pages : 12 Date : 2014-02-10 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stir-threats-02 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 Tue Feb 11 07:45:23 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1669C1A03AD for ; Tue, 11 Feb 2014 07:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0x6k7cuYoxZ0 for ; Tue, 11 Feb 2014 07:45:15 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id A8F031A0308 for ; Tue, 11 Feb 2014 07:45:15 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tp5so4618356ieb.35 for ; Tue, 11 Feb 2014 07:45:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=YT2uxXRpXW68bTgux4fWK9I/mB5aFMBf04etkFD1kto=; b=gSkkfaFgcHbAbp/Ae7WdXUQ3DyjAUo4H/JGFeweKZ+RcMQ3hwqUBCJY1ONy0+lNEoi 0bvUJBzzRBN41vK61FlnG9SxyAZE5g7HwZBOSVAKuhcgmxxJV6/p1gFwZWDuUGMDBRrG lgb0cH7cEzRInA0cjb6oA4CHzuBudO2aK/tPJpS5dAJKyNE/KspDBI/LdY0MLvCUZCLb o2GUX3ttJPxo5Kq5QjsLwCESuz+2RSgJIIDT9OwZBRvQ+2bbh4oHDHEB/kG/9nr+53sr MSC5HaGrMCC8SBK89IbplYxPTuiZtI/X67g8sUntzg68vUe23s5n5K+x/4veVhuQui2t xkwA== X-Gm-Message-State: ALoCoQm06Q5KKKTd7FGUg6baoI3CB4TqfLoLjSZnVJDyWFvmBd58c/bgYZxQyVWP64KZvfmP1hVa X-Received: by 10.50.45.69 with SMTP id k5mr6697873igm.32.1392133514898; Tue, 11 Feb 2014 07:45:14 -0800 (PST) Received: from [10.33.193.26] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id l7sm55091500igx.2.2014.02.11.07.45.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 07:45:14 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_257DA34A-F11D-4B14-9940-D030D516B3C1" Mime-Version: 1.0 (Mac OS X Mail 7.1 $1827$) From: Brian Rosen In-Reply-To: <4B1956260CD29F4A9622F00322FE0531EC8D239F04@BOBO1A.bobotek.net> Date: Tue, 11 Feb 2014 10:45:11 -0500 Message-Id: <280CB26B-9B67-4B75-BFB3-FD2D37661217@brianrosen.net> References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> <52F8EAC1.2090701@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BBF26DBC@sc9-ex2k10mb1.corp.yaanatech.com> <4B1956260CD29F4A9622F00322FE0531EC8D239F04@BOBO1A.bobotek.net> To: Alex Bobotek X-Mailer: Apple Mail (2.1827) Cc: "stir@ietf.org" , Michael Hammer , Paul Kyzivat Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 15:45:23 -0000 --Apple-Mail=_257DA34A-F11D-4B14-9940-D030D516B3C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We=92re signing =46rom and To, so we have the problem. You can get a =93call back=94 from an emergency call. In most cases, = today, that is a call that is placed on the PSTN from a local PSAP or = responder, but we have some work in ecrit on a standardized marking for = call-backs. =20 While +1911 is not an e.164, it=92s certainly unambiguous, simple to = canonicalize, and straightforward to deal with as a To. For a From, it = would be a little harder, because multiple entities would need valid = credentials, but it=92s certainly feasible to give them such. Brian On Feb 10, 2014, at 1:16 PM, Alex Bobotek wrote: > +1 > =20 > With the assumption that local numbering needs to be supported (an = assumption which I support), there are two non-exclusive enforcement = choices: > =20 > * provide an endpoint (or its proxy) with sufficient information with = which to enforce policy -- specifically: > - its own context and > - the context of the caller > - context(s) authorized for the caller > =20 > * rely on networks to block unauthorized calling contexts (e.g., local = numbering schemes) from reaching a called endpoint > =20 > Currently the latter is in place; it's reasonable to assume that it = will remain so.=20 > =20 > ---- > =20 > Another comment in reaction to a cert issued by a 3rd party = non-telephony-SP: > =20 > I don't believe a secure calling environment interoperable with the = PSTN can be established without a mechanism in which an originating = service provider takes responsibility for (i.e., signs) an originating = call. Is this a topic for discussion or generally agreed? > =20 > Regards, > =20 > Alex > =20 > > -----Original Message----- > > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael = Hammer > > Sent: Monday, February 10, 2014 7:09 AM > > To: pkyzivat@alum.mit.edu; stir@ietf.org > > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > > > > I think that this is opening Pandora's box. They are essentially = service codes > > that are localized. > > There could be literally thousands of termination points that those = codes go > > to. > > Not sure it helps to have calls coming from those numbers, signed or = not. > > > > We should stick to the current scope of worrying about E.164 = telephone > > numbers. > > > > Michael Hammer > > Principal Engineer > > michael.hammer@yaanatech.com > > Mobile: +1 408-202-9291 > > 500 Yosemite Drive Suite 120 > > Milpitas, CA 95035 USA > > > > > > -----Original Message----- > > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Monday, February 10, 2014 10:06 AM > > To: stir@ietf.org > > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > > > > On 2/10/14 3:15 AM, Anton Baskov wrote: > > > I think that by default canonization should be possible only if we = have any > > additional informational header with tel: uri to allow canonization. = But, if this > > header is accidentally missed, we can still guess full E.164 number = and if will > > match STIR signature we can be sure that all is ok, but if phone = number we > > guessed don=92t match signature we don=92t know =96 is it a problem = with > > signature or we just guessed wrong number. > > > > > > By the way, additional field can be helpful if we would like to = have signed > > call from local numbers, like tel:112 (911) and other numbers that = can=92t be > > routed globally. > > > > Note: tel:112 and tel:911 are invalid syntax for a tel uri. > > > > 112 isn't an E.164. To be syntactically valid it requires a = parameter. > > E.g., tel:112;phone-context=3D+44, tel:911;phone-context=3D+1 > > > > But is there really a case where we need to sign these? We are = talking about > > signing From, not To. I don't expect to get a call with one of these = as From. > > > > Thanks, > > Paul > > > > > > > > _______________________________________________ > > 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 --Apple-Mail=_257DA34A-F11D-4B14-9940-D030D516B3C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 We=92re = signing =46rom and To, so we have the problem.

You = can get a =93call back=94 from an emergency call. In most cases, = today, that is a call that is placed on the PSTN from a local PSAP or = responder, but we have some work in ecrit on a standardized marking for = call-backs.

While +1911 is not an e.164, = it=92s certainly unambiguous, simple to canonicalize, and = straightforward to deal with as a To. For a From, it would be a = little harder, because multiple entities would need valid credentials, = but it=92s certainly feasible to give them = such.

Brian

On Feb 10, = 2014, at 1:16 PM, Alex Bobotek <alex@bobotek.net> = wrote:

+1

With the assumption that local numbering needs to be supported (an = assumption which I support), there are two non-exclusive enforcement = choices:

* provide an endpoint (or its proxy) with sufficient information = with which to enforce policy -- specifically:

        - its own context = and

        - the context of the = caller

        - context(s) authorized = for the caller

* rely on networks to block unauthorized calling contexts (e.g., = local numbering schemes) from reaching a called endpoint

Currently the latter is in place; it's reasonable to assume that = it will remain so.

----

Another comment in reaction to a cert issued by a 3rd party = non-telephony-SP:

I don't believe a secure calling environment interoperable with the = PSTN can be established without a mechanism in which an originating = service provider takes responsibility for (i.e., signs) an originating = call. Is this a topic for discussion or generally agreed?

Regards,

Alex

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

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

> Sent: Monday, February 10, 2014 7:09 AM

> To: pkyzivat@alum.mit.edu; stir@ietf.org

> Subject: Re: [stir] Comment on = draft-jennings-stir-rfc4474bis-00

>

> I think that this is opening Pandora's box. They are = essentially service codes

> that are localized.

> There could be literally thousands of termination points that = those codes go

> to.

> Not sure it helps to have calls coming from those numbers, = signed or not.

>

> We should stick to the current scope of worrying about E.164 = telephone

> numbers.

>

> Michael Hammer

> Principal Engineer

> michael.hammer@yaanatech.com<= /a>

> Mobile: +1 408-202-9291

> 500 Yosemite Drive Suite 120

> Milpitas, CA 95035 USA

>

>

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

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

> Sent: Monday, February 10, 2014 10:06 AM

> To: stir@ietf.org

> Subject: Re: [stir] Comment on = draft-jennings-stir-rfc4474bis-00

>

> On 2/10/14 3:15 AM, Anton Baskov wrote:

> > I think that by default canonization should be possible = only if we have any

> additional informational header with tel: uri to allow = canonization. But, if this

> header is accidentally missed, we can still guess full E.164 = number and if will

> match STIR signature we can be sure that all is ok, but if = phone number we

> guessed don=92t match signature we don=92t know =96 is it a = problem with

> signature or we just guessed wrong number.

> >

> > By the way, additional field can be helpful if we would = like to have signed

> call from local numbers, like tel:112 = (911) and other numbers that can=92t be

> routed globally.

>

> Note: tel:112 and tel:911 are invalid syntax for a tel uri.

>

> 112 isn't an E.164. To be syntactically valid it requires a = parameter.

> E.g., tel:112;phone-context=3D+44, tel:911;phone-context=3D+1

>

> But is there really a case where we need to sign these? We are = talking about

> signing From, not To. I don't expect to get a call with one of = these as From.

>

>        Thanks,

>        Paul

>

>

>

> _______________________________________________

> stir mailing list

> stir@ietf.org

> https://www.ietf.org/m= ailman/listinfo/stir

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_257DA34A-F11D-4B14-9940-D030D516B3C1-- From michael.hammer@yaanatech.com Tue Feb 11 07:55:22 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB621A0502 for ; Tue, 11 Feb 2014 07:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcsyYFUH34dT for ; Tue, 11 Feb 2014 07:55:17 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id B13A01A05D5 for ; Tue, 11 Feb 2014 07:55:17 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 07:55:17 -0800 From: Michael Hammer To: "br@brianrosen.net" , "alex@bobotek.net" Thread-Topic: [stir] Comment on draft-jennings-stir-rfc4474bis-00 Thread-Index: AQHPHakXeh5A9RY73U6WW9EQZxSv+5qfewSAgAE0IGCADgwMAIAAcrWA//96WQCAAC4GwIAB9QSA//98AfA= Date: Tue, 11 Feb 2014 15:55:16 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF27F50@sc9-ex2k10mb1.corp.yaanatech.com> References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> <52F8EAC1.2090701@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BBF26DBC@sc9-ex2k10mb1.corp.yaanatech.com> <4B1956260CD29F4A9622F00322FE0531EC8D239F04@BOBO1A.bobotek.net> <280CB26B-9B67-4B75-BFB3-FD2D37661217@brianrosen.net> In-Reply-To: <280CB26B-9B67-4B75-BFB3-FD2D37661217@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.92] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0165_01CF2717.BECEF900" MIME-Version: 1.0 Cc: "stir@ietf.org" , "pkyzivat@alum.mit.edu" Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 15:55:22 -0000 ------=_NextPart_000_0165_01CF2717.BECEF900 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0166_01CF2717.BECEF900" ------=_NextPart_001_0166_01CF2717.BECEF900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How many PSAPS are their across the U.S.? And how good have they been about conforming to a standard for operations? That herd of cats might be a bridge too far. But, I won't object if you can specify the logistics for that. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, February 11, 2014 10:45 AM To: Alex Bobotek Cc: Michael Hammer; Paul Kyzivat; stir@ietf.org Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 We're signing From and To, so we have the problem. You can get a "call back" from an emergency call. In most cases, today, that is a call that is placed on the PSTN from a local PSAP or responder, but we have some work in ecrit on a standardized marking for call-backs. While +1911 is not an e.164, it's certainly unambiguous, simple to canonicalize, and straightforward to deal with as a To. For a From, it would be a little harder, because multiple entities would need valid credentials, but it's certainly feasible to give them such. Brian On Feb 10, 2014, at 1:16 PM, Alex Bobotek wrote: +1 With the assumption that local numbering needs to be supported (an assumption which I support), there are two non-exclusive enforcement choices: * provide an endpoint (or its proxy) with sufficient information with which to enforce policy -- specifically: - its own context and - the context of the caller - context(s) authorized for the caller * rely on networks to block unauthorized calling contexts (e.g., local numbering schemes) from reaching a called endpoint Currently the latter is in place; it's reasonable to assume that it will remain so. ---- Another comment in reaction to a cert issued by a 3rd party non-telephony-SP: I don't believe a secure calling environment interoperable with the PSTN can be established without a mechanism in which an originating service provider takes responsibility for (i.e., signs) an originating call. Is this a topic for discussion or generally agreed? Regards, Alex > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer > Sent: Monday, February 10, 2014 7:09 AM > To: pkyzivat@alum.mit.edu; stir@ietf.org > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > > I think that this is opening Pandora's box. They are essentially service codes > that are localized. > There could be literally thousands of termination points that those codes go > to. > Not sure it helps to have calls coming from those numbers, signed or not. > > We should stick to the current scope of worrying about E.164 telephone > numbers. > > Michael Hammer > Principal Engineer > michael.hammer@yaanatech.com > Mobile: +1 408-202-9291 > 500 Yosemite Drive Suite 120 > Milpitas, CA 95035 USA > > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, February 10, 2014 10:06 AM > To: stir@ietf.org > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > > On 2/10/14 3:15 AM, Anton Baskov wrote: > > I think that by default canonization should be possible only if we have any > additional informational header with tel: uri to allow canonization. But, if this > header is accidentally missed, we can still guess full E.164 number and if will > match STIR signature we can be sure that all is ok, but if phone number we > guessed don't match signature we don't know - is it a problem with > signature or we just guessed wrong number. > > > > By the way, additional field can be helpful if we would like to have signed > call from local numbers, like tel:112 (911) and other numbers that can't be > routed globally. > > Note: tel:112 and tel:911 are invalid syntax for a tel uri. > > 112 isn't an E.164. To be syntactically valid it requires a parameter. > E.g., tel:112;phone-context=+44, tel:911;phone-context=+1 > > But is there really a case where we need to sign these? We are talking about > signing From, not To. I don't expect to get a call with one of these as From. > > Thanks, > Paul > > > > _______________________________________________ > 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 ------=_NextPart_001_0166_01CF2717.BECEF900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How many PSAPS are their across the U.S.?

And how good have they been about conforming to a standard for = operations?

That herd of cats might be a bridge too far.

But, I won’t object if you can specify the logistics for = that.

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite = 120

Milpitas, CA 95035 = USA

From:= = Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, = February 11, 2014 10:45 AM
To: Alex Bobotek
Cc: = Michael Hammer; Paul Kyzivat; stir@ietf.org
Subject: Re: = [stir] Comment on = draft-jennings-stir-rfc4474bis-00

We’re = signing From and To, so we have the problem.

You can get a “call back” from an = emergency call. In most cases, today, that is a call that is = placed on the PSTN from a local PSAP or responder, but we have some work = in ecrit on a standardized marking for call-backs. =

While +1911 is not an e.164, it’s certainly = unambiguous, simple to canonicalize, and straightforward to deal with as = a To. For a From, it would be a little harder, because multiple = entities would need valid credentials, but it’s certainly feasible = to give them such.

Brian

On = Feb 10, 2014, at 1:16 PM, Alex Bobotek <alex@bobotek.net> = wrote:

With the = assumption that local numbering needs to be supported (an assumption = which I support), there are two non-exclusive enforcement = choices:

* provide = an endpoint (or its proxy) with sufficient information with which to = enforce policy -- specifically:

= ; - its own context = and

= ; - the context of the = caller

= ; - context(s) authorized for the = caller

* rely on = networks to block unauthorized calling contexts (e.g., local numbering = schemes) from reaching a called = endpoint

Currently = the latter is in place; it's reasonable to assume that it will remain = so. =

----

Another = comment in reaction to a cert issued by a 3rd party = non-telephony-SP:

I don't = believe a secure calling environment interoperable with the PSTN can be = established without a mechanism in which an originating service provider = takes responsibility for (i.e., signs) an originating call. Is = this a topic for discussion or generally = agreed?

Regards,

Alex

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

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

> Sent: = Monday, February 10, 2014 7:09 AM

> To: = pkyzivat@alum.mit.edu; stir@ietf.org

> = Subject: Re: [stir] Comment on = draft-jennings-stir-rfc4474bis-00

> =

> I = think that this is opening Pandora's box. They are essentially = service codes

> that = are localized.

> There = could be literally thousands of termination points that those codes = go

> = to.

> Not = sure it helps to have calls coming from those numbers, signed or = not.

> =

> We = should stick to the current scope of worrying about E.164 = telephone

> = numbers.

> =

> = Michael Hammer

> = Principal Engineer

> michael.hammer@yaanatech.com=

> = Mobile: +1 408-202-9291

> 500 = Yosemite Drive Suite 120

> = Milpitas, CA 95035 USA

> =

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

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

> Sent: = Monday, February 10, 2014 10:06 AM

> To: = stir@ietf.org

> = Subject: Re: [stir] Comment on = draft-jennings-stir-rfc4474bis-00

> =

> On = 2/10/14 3:15 AM, Anton Baskov wrote:

> > = I think that by default canonization should be possible only if we have = any

> = additional informational header with tel: uri to allow canonization. = But, if this

> = header is accidentally missed, we can still guess full E.164 number and = if will

> match = STIR signature we can be sure that all is ok, but if phone number = we

> = guessed don’t match signature we don’t know – is it a = problem with

> = signature or we just guessed wrong = number.

> = >

> > = By the way, additional field can be helpful if we would like to have = signed

> call = from local numbers, like tel:112 (911) and other = numbers that can’t be

> = routed globally.

> =

> Note: = tel:112 and tel:911 are = invalid syntax for a tel uri.

> =

> 112 = isn't an E.164. To be syntactically valid it requires a = parameter.

> E.g., = tel:112;phone-context=3D+44, = tel:911;phone-context=3D+1

> =

> But = is there really a case where we need to sign these? We are talking = about

> = signing From, not To. I don't expect to get a call with one of these as = From.

> =

> &= nbsp; = Thanks,

> &= nbsp; = Paul

> =

> = _______________________________________________

> 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

------=_NextPart_001_0166_01CF2717.BECEF900-- ------=_NextPart_000_0165_01CF2717.BECEF900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIx MTE1NTUxNVowIwYJKoZIhvcNAQkEMRYEFMXmOMM5BYhrQusKW6wrC5f1LHvgMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAF/XyICpqoF836LjW5+ZsjZp78GDA9Xy3iuIUhuH0 za5h10DyoWEYePimTf/1t1GbN7K3tL3vlyr0GdOVOD+a/DvzLfm1BIAuINYuvxASudZ3MtIvuXtG HnzBPlmuJmfQDO9g/sVpKtN3spHgE3x/oPiN6Rqp0tPzCSusYuhvrQjejtmlqsCw2NXZCX46EJg5 sBDtywo6PnlpzvQZS2yV/nOdKxgSuaIS5HozLoIQT8OLz477Le/92zn6Up6n53tczGKu2vg79IoH ruSFejO/bsQIDfc4sjbqzqS87YyT9MfCGcSOGVJRhQrnalYfntcHtboG/IcgcJlC1Q4DvFolSQAA AAAAAA== ------=_NextPart_000_0165_01CF2717.BECEF900-- From br@brianrosen.net Tue Feb 11 08:00:49 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638C71A0605 for ; Tue, 11 Feb 2014 08:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDd8ZSZ94d2G for ; Tue, 11 Feb 2014 08:00:45 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD4B1A04DC for ; Tue, 11 Feb 2014 08:00:45 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id ar20so4444709iec.6 for ; Tue, 11 Feb 2014 08:00:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=oj1vfTosCrZ3u6lFetoTGwLr6WJQIv9Z1T8/AVhdpZI=; b=Uo1spIehv2cx2uwFaYBZYtrehcpAbzBL9/ewx9F9BTzb1ud1+YpRr6TTz2FiidgMCc Z1bl0wOsLH7MbapSa5G1If1NTsTHsl9qrxQMcWYBcVEYvPXNwtud1tydxf9jHTcw0T3+ Ge51zRg/LyYWkFw+tAwr95lnMMPWQeLAaGafQFSXvCDz9y5qCXRQJcmAoeXo0qLqXnyo dZLnGATmCfAUlzngz8UvhTioIh5zlUOACYIV/nbebhixUSzhK1ZhKvq24se432JSO4o1 cTdDrGUCav9r84uFFAuNn2LzQv5UzQyVz1hwsLvGkS6vVpa+s3gUvXYAX+sL5TtIMmk4 MFUQ== X-Gm-Message-State: ALoCoQlql37tsi0kkxPhlomdZZlFi1YXZAqD8lyiZKHdmCYtd3eGG9JmEJ9tWrzZ5dpjr1Sb1Dq8 X-Received: by 10.50.154.102 with SMTP id vn6mr20210980igb.1.1392134444410; Tue, 11 Feb 2014 08:00:44 -0800 (PST) Received: from [10.33.193.26] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id kz4sm55159493igb.4.2014.02.11.08.00.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 08:00:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F45D6A27-C6F5-4850-B396-5923B29FC276" Mime-Version: 1.0 (Mac OS X Mail 7.1 $1827$) From: Brian Rosen In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF27F50@sc9-ex2k10mb1.corp.yaanatech.com> Date: Tue, 11 Feb 2014 11:00:41 -0500 Message-Id: <078D7397-9E5C-4D46-AFC3-86FFDC1E2C01@brianrosen.net> References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> <52F8EAC1.2090701@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BBF26DBC@sc9-ex2k10mb1.corp.yaanatech.com> <4B1956260CD29F4A9622F00322FE0531EC8D239F04@BOBO1A.bobotek.net> <280CB26B-9B67-4B75-BFB3-FD2D37661217@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBF27F50@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1827) Cc: "stir@ietf.org" , "alex@bobotek.net" , Paul Kyzivat Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 16:00:49 -0000 --Apple-Mail=_F45D6A27-C6F5-4850-B396-5923B29FC276 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Over 6000. They had sloppy standards conformance before this, but we=92re testing = conformance with the Next Generation 9-1-1 standards and getting pretty = good results. Good enough that it=92s helping IETF efforts like siprec. I think it can be done. There is a PKI that I believe will get set up for credentials. Since = stir needs the ability to delegate =93authorized spoofing=94 for call = centers and doctors, we already have the problem of multiple credentials = for the same number. I think it=92s possible to have lots of such = credentials if the database is organized reasonably. An organization = like, say, American Express may have dozens or even hundreds of outlets = making calls on their behalf, but a single advertised number. We need = to be able to handle that. Brian On Feb 11, 2014, at 10:55 AM, Michael Hammer = wrote: > How many PSAPS are their across the U.S.? > And how good have they been about conforming to a standard for = operations? > That herd of cats might be a bridge too far. > But, I won=92t object if you can specify the logistics for that. > =20 > Michael Hammer > Principal Engineer > michael.hammer@yaanatech.com > Mobile: +1 408-202-9291 > 500 Yosemite Drive Suite 120 > Milpitas, CA 95035 USA > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, February 11, 2014 10:45 AM > To: Alex Bobotek > Cc: Michael Hammer; Paul Kyzivat; stir@ietf.org > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > =20 > We=92re signing =46rom and To, so we have the problem. > =20 > You can get a =93call back=94 from an emergency call. In most cases, = today, that is a call that is placed on the PSTN from a local PSAP or = responder, but we have some work in ecrit on a standardized marking for = call-backs. =20 > =20 > While +1911 is not an e.164, it=92s certainly unambiguous, simple to = canonicalize, and straightforward to deal with as a To. For a From, it = would be a little harder, because multiple entities would need valid = credentials, but it=92s certainly feasible to give them such. > =20 > Brian > =20 > On Feb 10, 2014, at 1:16 PM, Alex Bobotek wrote: >=20 >=20 > +1 > =20 > With the assumption that local numbering needs to be supported (an = assumption which I support), there are two non-exclusive enforcement = choices: > =20 > * provide an endpoint (or its proxy) with sufficient information with = which to enforce policy -- specifically: > - its own context and > - the context of the caller > - context(s) authorized for the caller > =20 > * rely on networks to block unauthorized calling contexts (e.g., local = numbering schemes) from reaching a called endpoint > =20 > Currently the latter is in place; it's reasonable to assume that it = will remain so.=20 > =20 > ---- > =20 > Another comment in reaction to a cert issued by a 3rd party = non-telephony-SP: > =20 > I don't believe a secure calling environment interoperable with the = PSTN can be established without a mechanism in which an originating = service provider takes responsibility for (i.e., signs) an originating = call. Is this a topic for discussion or generally agreed? > =20 > Regards, > =20 > Alex > =20 > > -----Original Message----- > > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael = Hammer > > Sent: Monday, February 10, 2014 7:09 AM > > To: pkyzivat@alum.mit.edu; stir@ietf.org > > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > > > > I think that this is opening Pandora's box. They are essentially = service codes > > that are localized. > > There could be literally thousands of termination points that those = codes go > > to. > > Not sure it helps to have calls coming from those numbers, signed or = not. > > > > We should stick to the current scope of worrying about E.164 = telephone > > numbers. > > > > Michael Hammer > > Principal Engineer > > michael.hammer@yaanatech.com > > Mobile: +1 408-202-9291 > > 500 Yosemite Drive Suite 120 > > Milpitas, CA 95035 USA > > > > > > -----Original Message----- > > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Monday, February 10, 2014 10:06 AM > > To: stir@ietf.org > > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > > > > On 2/10/14 3:15 AM, Anton Baskov wrote: > > > I think that by default canonization should be possible only if we = have any > > additional informational header with tel: uri to allow canonization. = But, if this > > header is accidentally missed, we can still guess full E.164 number = and if will > > match STIR signature we can be sure that all is ok, but if phone = number we > > guessed don=92t match signature we don=92t know =96 is it a problem = with > > signature or we just guessed wrong number. > > > > > > By the way, additional field can be helpful if we would like to = have signed > > call from local numbers, like tel:112 (911) and other numbers that = can=92t be > > routed globally. > > > > Note: tel:112 and tel:911 are invalid syntax for a tel uri. > > > > 112 isn't an E.164. To be syntactically valid it requires a = parameter. > > E.g., tel:112;phone-context=3D+44, tel:911;phone-context=3D+1 > > > > But is there really a case where we need to sign these? We are = talking about > > signing From, not To. I don't expect to get a call with one of these = as From. > > > > Thanks, > > Paul > > > > > > > > _______________________________________________ > > 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 --Apple-Mail=_F45D6A27-C6F5-4850-B396-5923B29FC276 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Over = 6000.

They had sloppy standards conformance before = this, but we=92re testing conformance with the Next Generation 9-1-1 = standards and getting pretty good results. Good enough that it=92s = helping IETF efforts like siprec.

I think it = can be done.

There is a PKI that I believe will = get set up for credentials. Since stir needs the ability to = delegate =93authorized spoofing=94 for call centers and doctors, we = already have the problem of multiple credentials for the same number. = I think it=92s possible to have lots of such credentials if the = database is organized reasonably. An organization like, say, = American Express may have dozens or even hundreds of outlets making = calls on their behalf, but a single advertised number. We need to = be able to handle = that.

Brian

On Feb 11, = 2014, at 10:55 AM, Michael Hammer <michael.hammer@yaanatech.com<= /a>> wrote:

How many PSAPS are their across the = U.S.?
And how good have they been about conforming to a = standard for operations?
That herd of cats might be a = bridge too far.
But, I won=92t object if you can specify the = logistics for that.

Michael Hammer
Principal = Engineer
michael.hammer@yaanatech.com
Mobile: +1 408-202-9291
500 = Yosemite Drive Suite 120
Milpitas, CA 95035 USA

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, February 11, 2014 = 10:45 AM
To: Alex = Bobotek
Cc: Michael Hammer; Paul = Kyzivat; stir@ietf.org
Subject: Re: [stir] Comment on = draft-jennings-stir-rfc4474bis-00

We=92re= signing =46rom and To, so we have the = problem.

You = can get a =93call back=94 from an emergency call. In most cases, = today, that is a call that is placed on the PSTN from a local PSAP or = responder, but we have some work in ecrit on a standardized marking for = call-backs.

While = +1911 is not an e.164, it=92s certainly unambiguous, simple to = canonicalize, and straightforward to deal with as a To. For a = From, it would be a little harder, because multiple entities would need = valid credentials, but it=92s certainly feasible to give them = such.

Brian

On = Feb 10, 2014, at 1:16 PM, Alex Bobotek <alex@bobotek.net> = wrote:

+1

With the assumption that local numbering needs to = be supported (an assumption which I support), there are two = non-exclusive enforcement = choices:

* provide an endpoint (or its proxy) with = sufficient information with which to enforce policy -- = specifically:
        - its own = context and
        - the context of = the caller
        - context(s) = authorized for the caller

* rely on networks to block unauthorized calling = contexts (e.g., local numbering schemes) from reaching a called = endpoint

Currently the latter is in place; it's reasonable = to assume that it will remain so.

----

Another comment in reaction to a cert issued by a = 3rd party non-telephony-SP:

I don't believe a secure calling environment = interoperable with the PSTN can be established without a mechanism in = which an originating service provider takes responsibility for (i.e., = signs) an originating call. Is this a topic for discussion or = generally agreed?

Regards,

Alex

> -----Original = Message-----
> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael = Hammer
> Sent: = Monday, February 10, 2014 7:09 AM
> To: pkyzivat@alum.mit.edu; stir@ietf.org
> Subject: Re: [stir] Comment on = draft-jennings-stir-rfc4474bis-00
>
> I think that this is opening Pandora's = box. They are essentially service = codes
> that = are localized.
> There could be literally thousands of termination = points that those codes go
> to.
> Not sure it helps to have calls coming from = those numbers, signed or not.
>
> We should stick to the current scope of = worrying about E.164 telephone
> = numbers.
>
> Michael Hammer
> Principal = Engineer
> michael.hammer@yaanatech.com
=
> Mobile: +1 = 408-202-9291
> 500 Yosemite Drive Suite = 120
> = Milpitas, CA 95035 USA
>
>
> -----Original = Message-----
> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul = Kyzivat
> Sent: = Monday, February 10, 2014 10:06 = AM
> = To: stir@ietf.org
> Subject: Re: [stir] Comment on = draft-jennings-stir-rfc4474bis-00
>
> On 2/10/14 3:15 AM, Anton Baskov = wrote:
> > I = think that by default canonization should be possible only if we have = any
> = additional informational header with tel: uri to allow canonization. = But, if this
> header is accidentally missed, we can still guess full = E.164 number and if will
> match STIR signature we can be sure that all = is ok, but if phone number we
> guessed don=92t match signature we don=92t = know =96 is it a problem with
> signature or we just guessed wrong = number.
> = >
> > = By the way, additional field can be helpful if we would like to have = signed
> call = from local numbers, like tel:112 (911) and other numbers = that can=92t be
> routed = globally.
>
> Note: tel:112 and tel:911 are invalid syntax for a = tel uri.
>
> 112 isn't an E.164. To be syntactically valid it = requires a parameter.
> E.g., tel:112;phone-context=3D+44, tel:911;phone-context=3D+1
>
> But is there really a case where we need to = sign these? We are talking about
> signing From, not To. I don't expect to get a = call with one of these as From.
>
>        = Thanks,
>        = Paul
>
>
>
> = _______________________________________________
> 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

= --Apple-Mail=_F45D6A27-C6F5-4850-B396-5923B29FC276-- From br@brianrosen.net Tue Feb 11 08:01:51 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2BE1A0548 for ; Tue, 11 Feb 2014 08:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3JkgXCq4qp4 for ; Tue, 11 Feb 2014 08:01:49 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by ietfa.amsl.com (Postfix) with ESMTP id BC5E31A0591 for ; Tue, 11 Feb 2014 08:01:48 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id j1so9094680iga.3 for ; Tue, 11 Feb 2014 08:01:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=dcQAsPI1nrPGZ9HZbyc8Z58A6n2VzOACjP+zqq5Uh2A=; b=SdOTHR2Bb1DHikqgRXxUzABDUfNYTIIK9jJYvbd292waVe7MqLoxTyil8y9/8CbLew MkjBv8OO+r0Msfa/WsOQeLotqhR3E+ptpHEeJgtvfuL5wuF6DFhJ8I0m9CTFLI8Dgum6 mGLkt3Ipijz97GyN6vvc854MuRVU5YDYKCSeg+ZhJIDHQAI8/nJ4KJd/zxzDJu+kyj46 Wjlofr9aQa/ZjUZ9uUUVfhSsIpi+krP9tt06MgNDVcuo8GWy8X62jzeKEs7xrc19DRrR 3m8d1YD3rnuYsOo4agNt/Kb1xExbgqlj372My0MJC18P0+/NR22jnNgsVCWlt8eGLe7B 55HQ== X-Gm-Message-State: ALoCoQkumvwcCBaitKc7Q432oQzRJIZgw8+lzg7Uft49o3zRLWk7K7EViwen+0DSGbPcdWfOB3yN X-Received: by 10.43.19.66 with SMTP id qj2mr20875004icb.31.1392134508192; Tue, 11 Feb 2014 08:01:48 -0800 (PST) Received: from [10.33.193.26] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id kt2sm57687704igb.1.2014.02.11.08.01.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 08:01:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DE717BA0-9B90-46CE-AED3-E3C21C8E8C5F" Mime-Version: 1.0 (Mac OS X Mail 7.1 $1827$) From: Brian Rosen In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF27F50@sc9-ex2k10mb1.corp.yaanatech.com> Date: Tue, 11 Feb 2014 11:01:45 -0500 Message-Id: References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> <52F8EAC1.2090701@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BBF26DBC@sc9-ex2k10mb1.corp.yaanatech.com> <4B1956260CD29F4A9622F00322FE0531EC8D239F04@BOBO1A.bobotek.net> <280CB26B-9B67-4B75-BFB3-FD2D37661217@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBF27F50@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1827) Cc: "stir@ietf.org" , "alex@bobotek.net" , Paul Kyzivat Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 16:01:52 -0000 --Apple-Mail=_DE717BA0-9B90-46CE-AED3-E3C21C8E8C5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Nope, we think that by canonicalizing the numbers, it works. The SBCs = munge the representation, but don=92t actually change the number. Brian On Feb 11, 2014, at 10:55 AM, Michael Hammer = wrote: > How many PSAPS are their across the U.S.? > And how good have they been about conforming to a standard for = operations? > That herd of cats might be a bridge too far. > But, I won=92t object if you can specify the logistics for that. > =20 > Michael Hammer > Principal Engineer > michael.hammer@yaanatech.com > Mobile: +1 408-202-9291 > 500 Yosemite Drive Suite 120 > Milpitas, CA 95035 USA > =20 > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, February 11, 2014 10:45 AM > To: Alex Bobotek > Cc: Michael Hammer; Paul Kyzivat; stir@ietf.org > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > =20 > We=92re signing =46rom and To, so we have the problem. > =20 > You can get a =93call back=94 from an emergency call. In most cases, = today, that is a call that is placed on the PSTN from a local PSAP or = responder, but we have some work in ecrit on a standardized marking for = call-backs. =20 > =20 > While +1911 is not an e.164, it=92s certainly unambiguous, simple to = canonicalize, and straightforward to deal with as a To. For a From, it = would be a little harder, because multiple entities would need valid = credentials, but it=92s certainly feasible to give them such. > =20 > Brian > =20 > On Feb 10, 2014, at 1:16 PM, Alex Bobotek wrote: >=20 >=20 > +1 > =20 > With the assumption that local numbering needs to be supported (an = assumption which I support), there are two non-exclusive enforcement = choices: > =20 > * provide an endpoint (or its proxy) with sufficient information with = which to enforce policy -- specifically: > - its own context and > - the context of the caller > - context(s) authorized for the caller > =20 > * rely on networks to block unauthorized calling contexts (e.g., local = numbering schemes) from reaching a called endpoint > =20 > Currently the latter is in place; it's reasonable to assume that it = will remain so.=20 > =20 > ---- > =20 > Another comment in reaction to a cert issued by a 3rd party = non-telephony-SP: > =20 > I don't believe a secure calling environment interoperable with the = PSTN can be established without a mechanism in which an originating = service provider takes responsibility for (i.e., signs) an originating = call. Is this a topic for discussion or generally agreed? > =20 > Regards, > =20 > Alex > =20 > > -----Original Message----- > > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael = Hammer > > Sent: Monday, February 10, 2014 7:09 AM > > To: pkyzivat@alum.mit.edu; stir@ietf.org > > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > > > > I think that this is opening Pandora's box. They are essentially = service codes > > that are localized. > > There could be literally thousands of termination points that those = codes go > > to. > > Not sure it helps to have calls coming from those numbers, signed or = not. > > > > We should stick to the current scope of worrying about E.164 = telephone > > numbers. > > > > Michael Hammer > > Principal Engineer > > michael.hammer@yaanatech.com > > Mobile: +1 408-202-9291 > > 500 Yosemite Drive Suite 120 > > Milpitas, CA 95035 USA > > > > > > -----Original Message----- > > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Monday, February 10, 2014 10:06 AM > > To: stir@ietf.org > > Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 > > > > On 2/10/14 3:15 AM, Anton Baskov wrote: > > > I think that by default canonization should be possible only if we = have any > > additional informational header with tel: uri to allow canonization. = But, if this > > header is accidentally missed, we can still guess full E.164 number = and if will > > match STIR signature we can be sure that all is ok, but if phone = number we > > guessed don=92t match signature we don=92t know =96 is it a problem = with > > signature or we just guessed wrong number. > > > > > > By the way, additional field can be helpful if we would like to = have signed > > call from local numbers, like tel:112 (911) and other numbers that = can=92t be > > routed globally. > > > > Note: tel:112 and tel:911 are invalid syntax for a tel uri. > > > > 112 isn't an E.164. To be syntactically valid it requires a = parameter. > > E.g., tel:112;phone-context=3D+44, tel:911;phone-context=3D+1 > > > > But is there really a case where we need to sign these? We are = talking about > > signing From, not To. I don't expect to get a call with one of these = as From. > > > > Thanks, > > Paul > > > > > > > > _______________________________________________ > > 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 --Apple-Mail=_DE717BA0-9B90-46CE-AED3-E3C21C8E8C5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Nope, = we think that by canonicalizing the numbers, it works. The SBCs = munge the representation, but don=92t actually change the = number.

Brian

On Feb 11, = 2014, at 10:55 AM, Michael Hammer <michael.hammer@yaanatech.com<= /a>> wrote:

How many PSAPS are their across the = U.S.?
And how good have they been about conforming to a = standard for operations?
That herd of cats might be a = bridge too far.
But, I won=92t object if you can specify the = logistics for that.

Michael Hammer
Principal = Engineer
michael.hammer@yaanatech.com
Mobile: +1 408-202-9291
500 = Yosemite Drive Suite 120
Milpitas, CA 95035 USA

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, February 11, 2014 = 10:45 AM
To: Alex = Bobotek
Cc: Michael Hammer; Paul = Kyzivat; stir@ietf.org
Subject: Re: [stir] Comment on = draft-jennings-stir-rfc4474bis-00

We=92re= signing =46rom and To, so we have the = problem.

You = can get a =93call back=94 from an emergency call. In most cases, = today, that is a call that is placed on the PSTN from a local PSAP or = responder, but we have some work in ecrit on a standardized marking for = call-backs.

While = +1911 is not an e.164, it=92s certainly unambiguous, simple to = canonicalize, and straightforward to deal with as a To. For a = From, it would be a little harder, because multiple entities would need = valid credentials, but it=92s certainly feasible to give them = such.

Brian

On = Feb 10, 2014, at 1:16 PM, Alex Bobotek <alex@bobotek.net> = wrote:

+1

With the assumption that local numbering needs to = be supported (an assumption which I support), there are two = non-exclusive enforcement = choices:

* provide an endpoint (or its proxy) with = sufficient information with which to enforce policy -- = specifically:
        - its own = context and
        - the context of = the caller
        - context(s) = authorized for the caller

* rely on networks to block unauthorized calling = contexts (e.g., local numbering schemes) from reaching a called = endpoint

Currently the latter is in place; it's reasonable = to assume that it will remain so.

----

Another comment in reaction to a cert issued by a = 3rd party non-telephony-SP:

I don't believe a secure calling environment = interoperable with the PSTN can be established without a mechanism in = which an originating service provider takes responsibility for (i.e., = signs) an originating call. Is this a topic for discussion or = generally agreed?

Regards,

Alex

> -----Original = Message-----
> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael = Hammer
> Sent: = Monday, February 10, 2014 7:09 AM
> To: pkyzivat@alum.mit.edu; stir@ietf.org
> Subject: Re: [stir] Comment on = draft-jennings-stir-rfc4474bis-00
>
> I think that this is opening Pandora's = box. They are essentially service = codes
> that = are localized.
> There could be literally thousands of termination = points that those codes go
> to.
> Not sure it helps to have calls coming from = those numbers, signed or not.
>
> We should stick to the current scope of = worrying about E.164 telephone
> = numbers.
>
> Michael Hammer
> Principal = Engineer
> michael.hammer@yaanatech.com
=
> Mobile: +1 = 408-202-9291
> 500 Yosemite Drive Suite = 120
> = Milpitas, CA 95035 USA
>
>
> -----Original = Message-----
> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul = Kyzivat
> Sent: = Monday, February 10, 2014 10:06 = AM
> = To: stir@ietf.org
> Subject: Re: [stir] Comment on = draft-jennings-stir-rfc4474bis-00
>
> On 2/10/14 3:15 AM, Anton Baskov = wrote:
> > I = think that by default canonization should be possible only if we have = any
> = additional informational header with tel: uri to allow canonization. = But, if this
> header is accidentally missed, we can still guess full = E.164 number and if will
> match STIR signature we can be sure that all = is ok, but if phone number we
> guessed don=92t match signature we don=92t = know =96 is it a problem with
> signature or we just guessed wrong = number.
> = >
> > = By the way, additional field can be helpful if we would like to have = signed
> call = from local numbers, like tel:112 (911) and other numbers = that can=92t be
> routed = globally.
>
> Note: tel:112 and tel:911 are invalid syntax for a = tel uri.
>
> 112 isn't an E.164. To be syntactically valid it = requires a parameter.
> E.g., tel:112;phone-context=3D+44, tel:911;phone-context=3D+1
>
> But is there really a case where we need to = sign these? We are talking about
> signing From, not To. I don't expect to get a = call with one of these as From.
>
>        = Thanks,
>        = Paul
>
>
>
> = _______________________________________________
> 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

= --Apple-Mail=_DE717BA0-9B90-46CE-AED3-E3C21C8E8C5F-- From nobody Fri Feb 14 11:49:11 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1223A1A03D5 for ; Fri, 14 Feb 2014 11:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Myl892Lg1TuS for ; Fri, 14 Feb 2014 11:49:03 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id BFB511A03D6 for ; Fri, 14 Feb 2014 11:46:02 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 8DF599A4307 for ; Fri, 14 Feb 2014 14:45:51 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 56yLTGpRxzaL for ; Fri, 14 Feb 2014 14:45:30 -0500 (EST) Received: from [192.168.2.110] (pool-71-178-10-80.washdc.fios.verizon.net [71.178.10.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A50259A42F9 for ; Fri, 14 Feb 2014 14:45:30 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: Date: Fri, 14 Feb 2014 14:45:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <896FA3DC-8B75-4B49-BC53-8C01CEA26264@vigilsec.com> References: To: IETF STIR Mail List X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/Y8kXD3450lJYxzp0PdQJdlfBW5E Subject: Re: [stir] WG Last Call on draft-ietf-stir-threats-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:49:06 -0000 https://datatracker.ietf.org/doc/draft-ietf-stir-threats/ The -02 version has been posted, and some people have indicated that = their concerns were resolved. Please speak now if you have any = lingering concerns. Russ On Jan 2, 2014, at 12:46 PM, Russ Housley wrote: > The authors have posted an updated Internet-Draft on the STIR threat = model. It can be found here: = http://www.ietf.org/id/draft-ietf-stir-threats-00.txt. >=20 > Is this document ready for the STIR WG to pass to the IESG, requesting = publication as an Informational RFC? Please provide your input on this = mail list by end-of-business on 16 January 2014. If you have issues or = concerns, please tell us what changes to the document are necessary to = resolve them. >=20 > Russ From nobody Mon Feb 17 07:55:22 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CACE1A022E for ; Mon, 17 Feb 2014 07:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtSnmwuDK05f for ; Mon, 17 Feb 2014 07:55:19 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 76EEF1A01FB for ; Mon, 17 Feb 2014 07:55:19 -0800 (PST) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1HFtFHX006116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 17 Feb 2014 09:55:16 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <530230E2.5020106@nostrum.com> Date: Mon, 17 Feb 2014 09:55:14 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 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.71.10.88 is authenticated by a trusted mechanism) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/A8PQfbJkPiHnxs2OIdHlskAm7Dc Subject: [stir] Drafts submitted X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:55:21 -0000 In case you aren't subscribed to i-d-announce: draft-jennings-stir-rfc4474bis-01.txt draft-peterson-stir-certificates-00.txt Russ already pointed out that draft-ietf-stir-threats-02 is available. I found this to be a useful way to form URLs for the archive tool: RjS From nobody Mon Feb 17 09:37:31 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECF41A03DE for ; Mon, 17 Feb 2014 09:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_14=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 636BBdPUsHrx for ; Mon, 17 Feb 2014 09:37:28 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DE2BD1A03DB for ; Mon, 17 Feb 2014 09:37:27 -0800 (PST) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1HHbPCh010330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 17 Feb 2014 11:37:25 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <530248D6.9010009@nostrum.com> Date: Mon, 17 Feb 2014 11:37:26 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 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.71.10.88 is authenticated by a trusted mechanism) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/_SolJhQ-7RPhLBreIx1XeotzjOA Subject: [stir] Planning for the STIR london meeting X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:37:29 -0000 All - We requested a 2 hour session and are preparing a 2 hour agenda even though we ended up with a 2.5 hr slot to make it easier for MMUSIC adjust the agenda of its first session to minimize conflicts for participants of both working groups. We're planning on spending the time on mechanism. So far, we've received requests for time for We're also planning to get a short update from the recent M3AAWG Voice and Telephony Anti-Abuse Workshop. We'll post more detailed agendas as soon as we can. RjS From nobody Wed Feb 19 17:36:49 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C299E1A01CD for ; Wed, 19 Feb 2014 17:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.047 X-Spam-Level: ** X-Spam-Status: No, score=2.047 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4x4wvwq5sdM for ; Wed, 19 Feb 2014 17:36:46 -0800 (PST) Received: from alt-proxy62.mail.unifiedlayer.com (alt-proxy62.mail.unifiedlayer.com [173.254.18.12]) by ietfa.amsl.com (Postfix) with SMTP id BD1A41A060C for ; Wed, 19 Feb 2014 17:36:42 -0800 (PST) Received: (qmail 1666 invoked by uid 0); 20 Feb 2014 01:36:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy18.mail.unifiedlayer.com with SMTP; 20 Feb 2014 01:36:36 -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=UnHWbMAKGGYgmXaz+EPfR3H662uSOZrG8L3cLZ1TYac=; b=XxE5WzmjiC54upiW38/8C9MiN7XZ/Fxladbp/UvIcpW2szz02EJ+YP/QZzbics02fRpwssrZvLmBlUrb0grBKEhF0ER4XgR1xPrYwpJmmMEDe8sD2zJkOrWY0E5ROhVm; Received: from [173.79.179.104] (port=59470 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WGIZ2-0006Bq-6r for stir@ietf.org; Wed, 19 Feb 2014 18:36:36 -0700 From: "Richard Shockey" To: Date: Wed, 19 Feb 2014 20:36:29 -0500 Message-ID: <002001cf2ddc$2f47bf80$8dd73e80$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CF2DB2.46733E20" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8t28S7vYv303TVR/2Y1fRRmHOgkg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/DWicInbUpvnYqHWOz0tfZxy7dbw Subject: [stir] FYI for those of you in the US. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:36:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01CF2DB2.46733E20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Key management.. Should be interesting. This points out an obvious point that as the phone networks are considered critical national infrastructure we may see lots of folks pile on to the STIR proposition eventually. ************* NIST Computer Security Division has announced three upcoming events. Mark your calendars! The NIST Computer Security Division is still planning to host more events and once the information becomes available to the general public, an email will be sent out to this mailing list. 1. Cryptographic Key Management Workshop 2014 March 4-5, 2014 NIST Gaithersburg, Maryland For more information regarding the Cryptographic Key Management workshop, please visit the workshop's webpage on the NIST Computer Security Division website: http://www.nist.gov/itl/csd/ct/ckm_workshop2014.cfm 2. FISSEA 27th Annual Conference March 18-20, 2014 NIST Gaithersburg, Maryland For more information regarding the FISSEA Conference, please visit the FISSEA website on the NIST CSRC website at: http://csrc.nist.gov/fissea/ 3. Privacy Engineering Workshop April 9-10, 2014 NIST Gaithersburg, Maryland For more information regarding the Privacy Engineering Workshop, please visit the workshop's webpage for more information on the NIST Computer Security Division website: http://www.nist.gov/itl/csd/privacy-engineering-workshop.cfm -- Richard Shockey Shockey Consulting LLC http://www.shockey.us 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_0021_01CF2DB2.46733E20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Key = management.. Should be interesting.

This points = out an obvious point that as the phone networks are considered critical = national infrastructure we may see lots of folks pile on to the STIR = proposition eventually.

*************

NIST = Computer Security Division has announced three upcoming events. Mark = your calendars! The NIST Computer Security Division is still planning to = host more events and once the information becomes available to the = general public, an email will be sent out to this mailing = list.

1. Cryptographic Key Management Workshop = 2014

March 4-5, 2014

NIST Gaithersburg, Maryland

For more information regarding the Cryptographic Key = Management workshop, please visit the workshop’s webpage on the = NIST Computer Security Division website:

http://www.n= ist.gov/itl/csd/ct/ckm_workshop2014.cfm

2. FISSEA = 27th Annual Conference

March 18-20, = 2014

NIST Gaithersburg, = Maryland

For more information = regarding the FISSEA Conference, please visit the FISSEA website on the = NIST CSRC website at: http://csrc.nist.gov/fissea/ =

3. Privacy Engineering Workshop

April 9-10, 2014

NIST Gaithersburg, Maryland

For more information regarding the Privacy Engineering = Workshop, please visit the workshop’s webpage for more information = on the NIST Computer Security Division website:

http://www.nist.gov/itl/csd/privacy-engineering-worksho= p.cfm

Richard = Shockey
Shockey Consulting LLC

http://www.shockey.us
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_0021_01CF2DB2.46733E20-- From nobody Thu Feb 20 01:26:34 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F229B1A003D for ; Thu, 20 Feb 2014 01:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.469 X-Spam-Level: * X-Spam-Status: No, score=1.469 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2bhHx8ZxrbM for ; Thu, 20 Feb 2014 01:26:31 -0800 (PST) Received: from leaf.named.informdeskmedia.ru (leaf.named.informdeskmedia.ru [IPv6:2001:470:9e0a::f:153:0]) by ietfa.amsl.com (Postfix) with ESMTP id 885721A005F for ; Thu, 20 Feb 2014 01:26:30 -0800 (PST) Received: from [92.100.239.157] (account postmaster@leaf.named.informdeskmedia.ru HELO firepaw) by leaf.named.informdeskmedia.ru (CommuniGate Pro SMTP 6.0.4 _community_) with ESMTPSA id 2311475; Thu, 20 Feb 2014 13:26:26 +0400 Date: Thu, 20 Feb 2014 11:26:13 +0200 From: Anton Baskov To: Brian Rosen Message-Id: <20140220112613.308ca157ab02c293841b90a1@ministry.int.ru> In-Reply-To: References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/J6FeUF0pVxLI1Wb8tu4zXaqk4hk Cc: "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 09:26:33 -0000 On Mon, 10 Feb 2014 09:23:36 -0500 Brian Rosen wrote: > I think we’re proposing to describe an algorithm in our document that turns the From/PAI into a canonical e.164. We need some rules for what happens when the algorithm fails. The origination side can test this and determine if it needs to do anything. So, it’s not a “guess”. Agree. In case we have an e.164 number based on our algorithm and address from From/PAI without any additional informational header we should check “sip uri + tel uri + signature” set and, if it fails, “sip uri + signature” set, because sip address can only looks similar to tel uri for our algorithm. -- Anton Baskov +7 (911) 254-77-92, +7 (916) 716-89-46 From nobody Thu Feb 20 02:37:52 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8131A00A6 for ; Thu, 20 Feb 2014 02:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.469 X-Spam-Level: * X-Spam-Status: No, score=1.469 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQUAL6-d67_d for ; Thu, 20 Feb 2014 02:37:50 -0800 (PST) Received: from leaf.named.informdeskmedia.ru (leaf.named.informdeskmedia.ru [85.17.236.2]) by ietfa.amsl.com (Postfix) with ESMTP id B97671A0097 for ; Thu, 20 Feb 2014 02:37:49 -0800 (PST) Received: from [92.100.239.157] (account postmaster@leaf.named.informdeskmedia.ru HELO firepaw) by leaf.named.informdeskmedia.ru (CommuniGate Pro SMTP 6.0.4 _community_) with ESMTPSA id 2311500; Thu, 20 Feb 2014 14:37:43 +0400 Date: Thu, 20 Feb 2014 12:37:37 +0200 From: Anton Baskov To: Paul Kyzivat Message-Id: <20140220123737.82f43587ce6e03f3b90f7ac7@ministry.int.ru> In-Reply-To: <52F8EAC1.2090701@alum.mit.edu> References: <20140130124955.36f845c83567532f445be465@ministry.int.ru> <00C069FD01E0324C9FFCADF539701DB3BBF1F3EF@sc9-ex2k10mb1.corp.yaanatech.com> <20140210101504.84a1ca2a412939e5a8446d37@ministry.int.ru> <52F8EAC1.2090701@alum.mit.edu> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/zSHGfOU3UZ18z1esHHdgab00i1Q Cc: stir@ietf.org Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 10:37:51 -0000 Paul, thank you, I missed it. It’s unlikely scenario, but here, gas service “04” can call you to schedule regular inspection of gas equipment in your home. So, we can decide, should calls from local number covered by STIR or not. I think that we can leave it out of scope. -- Anton Baskov +7 (911) 254-77-92, +7 (916) 716-89-46 On Mon, 10 Feb 2014 10:05:37 -0500 Paul Kyzivat