From nobody Tue Aug 1 08:07:40 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CAD132195 for ; Tue, 1 Aug 2017 08:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 c0pp2y9QL6XZ for ; Tue, 1 Aug 2017 08:07:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E304B131D1D for ; Tue, 1 Aug 2017 08:07:37 -0700 (PDT) Received: from unescapeable.local ([47.186.15.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v71F7a7r066915 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 1 Aug 2017 10:07:37 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.15.50] claimed to be unescapeable.local To: "stir@ietf.org" From: Robert Sparks Message-ID: <1e0d996a-bb5d-e2f0-d4e2-8fe1111a17e5@nostrum.com> Date: Tue, 1 Aug 2017 10:07:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [stir] Minutes for STIR at IETF99 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 15:07:39 -0000 Minutes for the STIR session at IETF 99 are at Please send any needed corrections to the list or the chairs. RjS From nobody Mon Aug 14 11:07:09 2017 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0A81323D7; Mon, 14 Aug 2017 11:07:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: stir@ietf.org, adam@nostrum.com, stir-chairs@ietf.org, rjsparks@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150273402599.420.4193295090536801418.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 11:07:05 -0700 Archived-At: Subject: [stir] stir - New Meeting Session Request for IETF 100 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 18:07:06 -0000 A new meeting session request has just been submitted by Robert Sparks, a Chair of the stir working group. --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Robert Sparks Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: lamps acme tls ecrit avtcore rtcweb mmusic sipcore dispatch ice modern ipwave sipbrandy curdle Second Priority: perc slim netvc clue tcpinc uta ace saag oauth People who must be present: Russ Housley Sean Turner Adam Roach Robert Sparks Jon Peterson Chris Wendt Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Aug 14 13:51:30 2017 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AFD126E64; Mon, 14 Aug 2017 13:51:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: stir@ietf.org, adam@nostrum.com, stir-chairs@ietf.org, rjsparks@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150274388806.10501.16548909146849529065.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 13:51:28 -0700 Archived-At: Subject: [stir] stir - Update to a Meeting Session Request for IETF 100 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:51:29 -0000 An update to a meeting session request has just been submitted by Robert Sparks, a Chair of the stir working group. --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Robert Sparks Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: lamps acme tls ecrit avtcore rtcweb mmusic sipcore dispatch ice modern ipwave sipbrandy curdle fud Second Priority: perc slim netvc clue tcpinc uta ace saag oauth People who must be present: Russ Housley Sean Turner Adam Roach Robert Sparks Jon Peterson Chris Wendt Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Aug 15 12:39:04 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC141200F3 for ; Tue, 15 Aug 2017 12:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 N8ODhLoEWFgZ for ; Tue, 15 Aug 2017 12:38:55 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21595132250 for ; Tue, 15 Aug 2017 12:38:55 -0700 (PDT) Received: from cmgw2 (unknown [10.0.90.83]) by qproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 030E0120441 for ; Tue, 15 Aug 2017 13:38:54 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id xXZr1v00j1MNPNq01XZuJD; Tue, 15 Aug 2017 13:33:54 -0600 X-Authority-Analysis: v=2.2 cv=T7z8d7CQ c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=KeKAF7QvOSUA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=pYvlLwShxMgfBbJAXV0A:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID: To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VT6lgiPX3BqDiZVsWmbzZAEqWfVytDVVrR3grsEw4js=; b=EdVwaUactqdNqqdCPAjswjaHvo Af+vQ8dck2ZlliEIpkaR2zjsxuxMJnlF+h3ERRFtJ5o2qUTrhpzhhdFaxj0lFJ5pOZPpUmSXhzDsq 6hvCCOFHMVbu13lK2EAAyDBhn; Received: from pool-100-36-44-145.washdc.fios.verizon.net ([100.36.44.145]:59064 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1dhhb5-004Abp-9e for stir@ietf.org; Tue, 15 Aug 2017 13:33:51 -0600 User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Tue, 15 Aug 2017 15:33:49 -0400 From: Richard Shockey To: "stir@ietf.org" Message-ID: Thread-Topic: FYI .. FCC Docket 17-97 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.145 X-Exim-ID: 1dhhb5-004Abp-9e X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-145.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.145]:59064 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [stir] FYI .. FCC Docket 17-97 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 19:39:04 -0000 Comments Filed on Call Authentication/Robocall NOI=20 Comments were filed on August 14, 2017, on the NOI on authenticating teleph= one calls to reduce instances of robocalling. NTCA said the Commission shoul= d remove current constraints on USF budget caps that impede the ability of s= mall rural carriers to update network infrastructure to SIP-based systems th= at would be compatible with the SHAKEN/STIR call authentication proposal. It= also said: current numbering bodies and practices may serve as an effective= model for the governance, certification and administration of any eventual = call authentication method, including SHAKEN/STIR; the Commission should con= tinue to solicit the advice of the NANC, but implementation and ongoing admi= nistrative costs should be fully factored into any call authentication solut= ion; and full cost recovery must be available for small carriers serving hig= h-cost rural areas. USTelecom supported industry-led efforts to develop and = deploy the SHAKEN and STIR standards and best-practice implementations, and = said the Commission should encourage, but not mandate, authentication soluti= ons that are currently under development by ATIS, the SIP Forum and the IETF= . It also suggested the Commission support and promote international efforts= to deploy the SHAKEN and STIR standards and best-practice implementations b= eyond domestic carriers. CTIA said the Commission should: promote flexible g= overnance that supports industry leadership in promoting authentication; enc= ourage but not mandate authentication solutions and encourage industry to wo= rk out implementation issues in standards bodies; and recognize that call au= thentication is a global problem and take a leadership role to encourage oth= er nations to participate in call authentication efforts. CTIA supported a h= ybrid governance model where industry defines and operates the structure, wi= th regulatory endorsement from the FCC. The Consumers Union, et al. suggeste= d the FCC take additional steps to ensure this system offers effective prote= ction against illegal and unwanted calls, including: directing voice provide= rs to implement caller ID authentication by the end of 2018, at no cost to c= onsumers; direct voice providers to offer consumers the option of blocking c= alls that fail to verify their caller ID information, for no extra charge; a= ll voice customers, including those using traditional wireline service, shou= ld have effective protections from fraudulently spoofed calls; the caller ID= authentication system should protect consumers from fraudulently spoofed ca= lls originating overseas; and consumers should be given the option of verify= ing the legitimacy of calls they make while withholding their personal ident= ifying information from the call recipient. Replies are due September 13, 20= 17. Comments also filed by: Internet Architecture Board Inconnectiv Professional Association for Customer Engagement American Financial Services Association VON Coalition Comcast ATIS Neustar CTIA NCTA Shockey Consulting Edison Electric Institute =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 From nobody Wed Aug 16 02:21:58 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353D7132025 for ; Wed, 16 Aug 2017 02:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 xCMzzoFHP99c for ; Wed, 16 Aug 2017 02:21:54 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F231200B9 for ; Wed, 16 Aug 2017 02:21:54 -0700 (PDT) X-AuditID: c1b4fb2d-4e93a9c0000057a4-40-59940eb056ca Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 35.53.22436.0BE04995; Wed, 16 Aug 2017 11:21:52 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 16 Aug 2017 11:21:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vFeVb/Rv2EaAjsc05009raJaWz9lwWXSop+uHGGvdeg=; b=fz5QBeLWkhaAuUEevTC7e7J2DDaotQHQFQrMGI9tKzkCrf6kNfglnuZ+SONGtJ0CuK3PEWBnWZhBO509XNDb0mtNnx0xUpp/nqUQ4++RF4ayxPaXXwLs1fQWS332mvt3QOg0Y9AvRm8X7D5A8s1lA+A3l/p5BJ/2Pd0NPTjAizc= Received: from DB5PR07MB1127.eurprd07.prod.outlook.com (10.163.103.157) by DB5PR07MB0887.eurprd07.prod.outlook.com (10.161.196.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Wed, 16 Aug 2017 09:21:28 +0000 Received: from DB5PR07MB1127.eurprd07.prod.outlook.com ([fe80::9090:5fed:5bcf:1aff]) by DB5PR07MB1127.eurprd07.prod.outlook.com ([fe80::9090:5fed:5bcf:1aff%14]) with mapi id 15.01.1362.018; Wed, 16 Aug 2017 09:21:28 +0000 From: Julio Martinez-Minguito To: "stir@ietf.org" Thread-Topic: Validating TN authority together with number portability Thread-Index: AdMWbZ5Gal6PDfc1QQq1QCbE62ZgWA== Date: Wed, 16 Aug 2017 09:21:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=julio.martinez-minguito@ericsson.com; x-originating-ip: [192.176.1.93] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB0887; 6:n9RhdJBZiCtMrHYttHjVN9sFFIA96fipZTiC+BhPCRB9UDrHG04PtRAkoAsffdaytwkgBZptRw3suh1W0hhO+Fw0033SySFUAdB4Ym0NlTdii39+Gki643zd0X+OGQEY2qBkQPkGl+7O3fk5MOFOQvA/Ad6aiANPl3TrfTmmVj6c+OPnVkL5uMTK1byTGmlISNx/lJgsXkOhlsBLmTOhv0tw4fcOMlIhjvBTxquJsO+RBh/1cXQwLFRmkw7a/WMwlj+dqqmK8Xdf57LpZLYrZI5vG7bz1iUeCkedPE9hg2Hk730A5tk8FSa85xNhg461p76/lZrfYYlXqeGFbhQKRw==; 5:FzCFolM6AsrtGc4rySxkhaQQp4mHgQ7iqDKtUEqK3ppNp5WxKDf/1FF/5Bm641rX58av3tKdvwDK8wwexG+rpXVIFbRKxuFvhfY8Chr75DEYy8aCAdv2CFRLPhGvvuL80m2RKLE8KLFsnja0muQvXA==; 24:lQKe28XOcNYuou2ytO/dLl8LvqFo04L40pWmo2gzjPI18D5qYEeANBa9OjM/E1SvnbNIr7DtxjHFYDV7vcEulEhB3t/zkyv25UB1e2/9e4M=; 7:yAPc2u5ovPG4Tw/4jEpOt4VCCgRwckyGXL2eJcEeugvcg6E3AwNZPl8giTmzo/+jXh8AgztLO3yEJq+nF1eUHtaiopVVU2Q2l7XmvDsi1DshniLV8apMo8c+vugyTT+w8XYI/tZ9XFFDuwt6d3oO8oeDmL0Cu/L7Se5pEd70L07PiNCGoz/cnT5djdRa9hU2nFUfTrcG1TbJk9FpW/DFiSe2wyMzYVIbqsv8kaLMFvk= x-ms-office365-filtering-correlation-id: 1b37ec83-86a7-4f4c-ca2e-08d4e4882cfe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB0887; x-ms-traffictypediagnostic: DB5PR07MB0887: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(21532816269658); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB0887; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB0887; x-forefront-prvs: 0401647B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(199003)(189002)(6436002)(81166006)(105586002)(8676002)(81156014)(106356001)(1730700003)(2351001)(2501003)(5250100002)(6506006)(66066001)(2906002)(3660700001)(6116002)(790700001)(19609705001)(3280700002)(8936002)(3846002)(102836003)(110136004)(86362001)(74316002)(189998001)(2900100001)(5660300001)(25786009)(53936002)(9686003)(54896002)(6306002)(7736002)(5640700003)(55016002)(99286003)(478600001)(68736007)(14454004)(9326002)(6916009)(5630700001)(54356999)(7696004)(33656002)(50986999)(97736004)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB0887; H:DB5PR07MB1127.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB1127A3D6068F833DC04C9A06C7820DB5PR07MB1127eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2017 09:21:28.6256 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0887 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUyM2K7ve4GvimRBr37FC2Wr93G5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNmdKxgL9jhULDzdzdzAuNa8i5GTQ0LARGLHo4NsXYxcHEIC Rxglpi9eD+WcYJQ4sOQdO4jDItDLLLH/bC9UZiaTxOR1z1lA+oUEHjNKrLnDBWKzCbhI3Dpx lxHEFhFQltiy7g47iC0s4Cixd+oTNoi4m8TczcuYIWw9iRmXn4HVsAioSsx/vxoszisQI3H7 5HSwOYwCYhLfT61hArGZBcQlbj2ZzwRxt4DEkj3nmSFsUYmXj/+xQtSnS3xvPgdkcwDFFSTu 34yCKJGVuDS/mxHkfgmBNnaJpw8WskHU+ErM2qICEX/EJNF/ei/UfC2JlZNmQ9nREseuXYay syWmbv7DBtFwmVVi4cG/UAkZiQst56A2nGGV+Hq3nxUSQqkSy9e2MkJCQkri7pVOKFtG4sWd vawTGDVmIXkOws6XWNbZzjILHBiCEidnPmGBiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzs qxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECk83BLb91dzCufu14iFGAg1GJh/cS+5RIIdbE suLK3EOMEhzMSiK8V39MjhTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67DvQoSQQHpiSWp2ampB ahFMlomDU6qB0fyz1F5ln/Wv+V25uEPc53wyqunvnhdem+fc3JDS6SeqMnOfX2pk+cWWZQp9 kxy/vUo/NnvuXwP9xH9SErLXlvgInlxxa/mdSouwR5Kv0g8FrG6OrAi9uCk0Uagp4/eGczKn rRb2Xl3bVNPTe7W7eN733n5D0fZXvk+Cl9dXd36d47MsSzJKiaU4I9FQi7moOBEAnL4vlTID AAA= Archived-At: Subject: [stir] Validating TN authority together with number portability X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 09:21:57 -0000 --_000_DB5PR07MB1127A3D6068F833DC04C9A06C7820DB5PR07MB1127eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The current drafts for RFC4474bis and certificates describe how to validate= that a telephone number is owned by the operator signing the calling Ident= ity. A TNAuthorizationList may be included in the certificate listing the n= umbers the operator is authoritative for. However, I see some issues handling this together with number portability w= hich need to be clarified. Subscribers will be ported in and out quite frequently, making the informat= ion in the certificates obsolete. To keep up the pace with the number porta= bility, the operators certificates would have to be updated frequently. Sho= uld the certificates have short validity times? E.g. 1 week, or even shorte= r? Instead of having the TN information in the certificate and need to update = it constantly, it would be more appropriate to have a trusted server connec= ted to the national Number Portability DB (to update the information) to wh= ich the verifiers can connect and retrieve the authority information. Each = verifier could retrieve the TN lists for operators and refresh the list dai= ly, without needing to re-issue operator certificates, so it would be updat= ed with the latest portability. About how to represent the TN lists, e.g. if an operator owns the range 555= -xxxx, with the current definitions it will be easy to describe: TelephoneNumberRange ::=3D SEQUENCE { start TelephoneNumber =3D 5550000, count INTEGER (2..MAX) =3D 10000 } Now, if number 555-6789 moves to another operator we have to represent with= : ({start =3D 5550000, count =3D 6789}, {start =3D 5556790, count =3D 3210}) As more numbers are moved out from the range, this representation format wi= ll get messy and difficult to manage. To handle NP it would be easier to keep the original range, and include a l= ist of excluded numbers which have been ported out, e.g.: TelephoneNumberRange ::=3D SEQUENCE { start TelephoneNumber, count INTEGER (2..MAX), excludedNumbers SEQUENCE SIZE (1..MAX) OF TNEntry } Is this a feasible solution? Is it too late to handle now due to the curren= t state? --_000_DB5PR07MB1127A3D6068F833DC04C9A06C7820DB5PR07MB1127eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The current drafts for RFC4474bis and certificates describe how to va=
lidate that a telephone number is owned by the operator signing the calling=
 Identity. A TNAuthorizationList may be included in the certificate listing=
 the numbers the operator is authoritative for.

 

However, I see some issues handling this together wi= th number portability which need to be clarified.

Subscribers will be ported in and out quite frequent= ly, making the information in the certificates obsolete. To keep up the pac= e with the number portability, the operators certificates would have to be = updated frequently. Should the certificates have short validity times? E.g. 1 week, or even shorter?

 

Instead of having the TN information in the certific= ate and need to update it constantly, it would be more appropriate to have = a trusted server connected to the national Number Portability DB (to update= the information) to which the verifiers can connect and retrieve the authority information. Each verifier could re= trieve the TN lists for operators and refresh the list daily, without needi= ng to re-issue operator certificates, so it would be updated with the lates= t portability.

 

About how to represent the TN lists, e.g. if an oper= ator owns the range 555-xxxx, with the current definitions it will be easy = to describe:

TelephoneNumberRange ::=3D SEQUENCE {

      start TelephoneNumber= =3D 5550000,

      count INTEGER (2..MAX= ) =3D 10000

      }

 

Now, if number 555-6789 moves to another operator we= have to represent with:

({start =3D 5550000, count =3D 6789}, {start =3D 555= 6790, count =3D 3210})

 

As more numbers are moved out from the range, this r= epresentation format will get messy and difficult to manage.

 

To handle NP it would be easier to keep the original= range, and include a list of excluded numbers which have been ported out, = e.g.:

 

TelephoneNumberRange ::=3D SEQUENCE {

      start TelephoneNumber= ,

      count INTEGER (2..MAX= ),

      excludedNumbers SEQUENCE SIZE (1..MAX)=
 OF TNEntry

      }

 

 

Is this a feasible solution? Is it too late to handl= e now due to the current state?

--_000_DB5PR07MB1127A3D6068F833DC04C9A06C7820DB5PR07MB1127eurp_-- From nobody Wed Aug 16 05:27:42 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C7D1326B0 for ; Wed, 16 Aug 2017 05:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com 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 syydde7ZbaCB for ; Wed, 16 Aug 2017 05:27:39 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A46132697 for ; Wed, 16 Aug 2017 05:27:38 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id o124so10400680qke.3 for ; Wed, 16 Aug 2017 05:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xqu9XXGoOP7eObExuaNZC0fksniO2/4j1LHfJneO954=; b=QPAC+pN8jRaavfCC7LO8zL4HI46i4celtxGWtaHTKc2PRfcVtaksdKZ2fmckqe39sE QLkxFW/mtPZk7km8Pc8mx1GhrfCSVl+OGHYpttgeCLksCIzcWtmWqN470PrWvnzgibyi 8QTsggVaJt90KrZe1QlvOxP6BYaI1KM9zJJxG190JWLLdCpGAcr6xLJl3T0MopZUO+Jt 3GNqNlTtlWa+vDzKLimxOOBF5DwLKrFYLM7sxGOezHuHv2bZoNNRWSLg3gfueMhP+KU2 I4O92pOJUrJgnq4SKfOMLad4vYVCbn5mwmfXyxtqi1yzVOKOFcCiThCXDR3xrcWYM+eZ F6fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xqu9XXGoOP7eObExuaNZC0fksniO2/4j1LHfJneO954=; b=J+x7qFcXrQz1cFV+DuNMaaVitUTxGGDzLP2irM1CtyrOM1rT6/uUvn2CHHj/Vzi4XV SWrXmFPau+9M1g182nIIf3XIuogTFTXlUIq0mt+jTFJqF3OdT8H9qGTlZMSR4iUJGpCT NxC5PM9jfAwCwo7Kf5mqcqXpPGxyuzOQwhdZN8Iw+cPZKmUBn5Zz556d5UaXcw2gW4bD dohcQx4tFQvs4nXfcPDqVnFNbvnH3euzEiWddjYwXOrTnB3xCPXUjzwez8lYrjPvItXQ /fxDC5afyHIbrxJOo5QE+L9sQ/BRPW5ld0veHDwDCC3IzddfA2wR573c7lKzt4+5eS0o +H6g== X-Gm-Message-State: AHYfb5hMDGToXl1YukPNZaPlGYOwc26KSwEDGb1UDQ2nK/pVMb4y69nA BK2WZq4eUmOs4aoM X-Received: by 10.55.79.9 with SMTP id d9mr1978068qkb.335.1502886457835; Wed, 16 Aug 2017 05:27:37 -0700 (PDT) Received: from ?IPv6:2601:41:c101:1475:3d0a:48c3:4873:9732? ([2601:41:c101:1475:3d0a:48c3:4873:9732]) by smtp.gmail.com with ESMTPSA id z1sm480024qtz.1.2017.08.16.05.27.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 05:27:36 -0700 (PDT) From: Chris Wendt Message-Id: <391A1CF8-4CED-4ECF-92EF-FA988B4881C4@chriswendt.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_3A2B44FE-4556-491F-85C6-83E23E63D699" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.3\)) Date: Wed, 16 Aug 2017 08:27:35 -0400 In-Reply-To: Cc: "stir@ietf.org" To: Julio Martinez-Minguito References: X-Mailer: Apple Mail (2.3445.1.3) Archived-At: Subject: Re: [stir] Validating TN authority together with number portability X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:27:41 -0000 --Apple-Mail=_3A2B44FE-4556-491F-85C6-83E23E63D699 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think you would just cover this scenario with two different = certificates with the two smaller ranges. That said, for North America the SHAKEN approach is not to use = certificates for number blocks, so not sure if you looking at a generic = solution or not. > On Aug 16, 2017, at 5:21 AM, Julio Martinez-Minguito = wrote: >=20 > Hi, > =20 > The current drafts for RFC4474bis and certificates describe how to = validate that a telephone number is owned by the operator signing the = calling Identity. A TNAuthorizationList may be included in the = certificate listing the numbers the operator is authoritative for. > =20 > However, I see some issues handling this together with number = portability which need to be clarified. > Subscribers will be ported in and out quite frequently, making the = information in the certificates obsolete. To keep up the pace with the = number portability, the operators certificates would have to be updated = frequently. Should the certificates have short validity times? E.g. 1 = week, or even shorter? > =20 > Instead of having the TN information in the certificate and need to = update it constantly, it would be more appropriate to have a trusted = server connected to the national Number Portability DB (to update the = information) to which the verifiers can connect and retrieve the = authority information. Each verifier could retrieve the TN lists for = operators and refresh the list daily, without needing to re-issue = operator certificates, so it would be updated with the latest = portability. > =20 > About how to represent the TN lists, e.g. if an operator owns the = range 555-xxxx, with the current definitions it will be easy to = describe: > TelephoneNumberRange ::=3D SEQUENCE { > start TelephoneNumber =3D 5550000, > count INTEGER (2..MAX) =3D 10000 > } > =20 > Now, if number 555-6789 moves to another operator we have to represent = with: > ({start =3D 5550000, count =3D 6789}, {start =3D 5556790, count =3D = 3210}) > =20 > As more numbers are moved out from the range, this representation = format will get messy and difficult to manage. > =20 > To handle NP it would be easier to keep the original range, and = include a list of excluded numbers which have been ported out, e.g.: > =20 > TelephoneNumberRange ::=3D SEQUENCE { > start TelephoneNumber, > count INTEGER (2..MAX), > excludedNumbers SEQUENCE SIZE (1..MAX) OF TNEntry > } > =20 > =20 > Is this a feasible solution? Is it too late to handle now due to the = current state? > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_3A2B44FE-4556-491F-85C6-83E23E63D699 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = think you would just cover this scenario with two different certificates = with the two smaller ranges.

That said, for North America the SHAKEN approach is not to = use certificates for number blocks, so not sure if you looking at a = generic solution or not.

On Aug = 16, 2017, at 5:21 AM, Julio Martinez-Minguito <julio.martinez-minguito@ericsson.com> wrote:

Hi,
 
The current drafts for RFC4474bis and =
certificates describe how to validate that a telephone number is owned =
by the operator signing the calling Identity. A TNAuthorizationList may =
be included in the certificate listing the numbers the operator is =
authoritative for.
 
However, I see some issues handling this together with number = portability which need to be clarified.
Subscribers will be ported in and out = quite frequently, making the information in the certificates obsolete. = To keep up the pace with the number portability, the operators = certificates would have to be updated frequently. Should the = certificates have short validity times? E.g. 1 week, or even = shorter?
 
Instead of having the TN information in the certificate and = need to update it constantly, it would be more appropriate to have a = trusted server connected to the national Number Portability DB (to = update the information) to which the verifiers can connect and retrieve = the authority information. Each verifier could retrieve the TN lists for = operators and refresh the list daily, without needing to re-issue = operator certificates, so it would be updated with the latest = portability.
 
About how to represent the TN lists, e.g. if an operator owns = the range 555-xxxx, with the current definitions it will be easy to = describe:
TelephoneNumberRange ::=3D SEQUENCE {
      start TelephoneNumber =3D = 5550000,
      count INTEGER (2..MAX) =3D = 10000
      }
 
Now, if = number 555-6789 moves to another operator we have to represent with:
({start =3D= 5550000, count =3D 6789}, {start =3D 5556790, count =3D 3210})
 
As more = numbers are moved out from the range, this representation format will = get messy and difficult to manage.
 
To handle NP it would be easier to keep = the original range, and include a list of excluded numbers which have = been ported out, e.g.:
 
TelephoneNumberRange ::=3D SEQUENCE {
      start TelephoneNumber,
      count INTEGER (2..MAX),
      excludedNumbers SEQUENCE SIZE =
(1..MAX) OF TNEntry
      }
 
 
Is this a = feasible solution? Is it too late to handle now due to the current = state?
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_3A2B44FE-4556-491F-85C6-83E23E63D699-- From nobody Wed Aug 23 07:01:37 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE789132C21 for ; Wed, 23 Aug 2017 07:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com 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 nACOCQ4wIqET for ; Wed, 23 Aug 2017 07:01:35 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39339132C20 for ; Wed, 23 Aug 2017 07:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8BTKQk6MrqhPLWwwu/BcguBXIhDq6lX8LSEw7xn96IQ=; b=QcOa+DyCLD7MCG09zZD//sxgc hwTXRz8vq/4HE8LX9PEWZDd9+xaNW/S2znhxkcy5ePEp2/htTEwaDNA2FKuED3Ryv6xaWlfYX3kzf FzLUh7mVm5TdyUA8//wXrTHTOKIAjOPN2+XcGQ8kTKfQcx1Si7Ty1Knb3DUdtvg9CZXZE=; Received: from ip68-100-196-217.dc.dc.cox.net ([68.100.196.217]:64354 helo=[192.168.10.25]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dkWDj-000aYd-Fv for stir@ietf.org; Wed, 23 Aug 2017 07:01:34 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_A2478964-3182-4595-BDFA-FD255D53B8E2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 23 Aug 2017 10:01:22 -0400 References: <391A1CF8-4CED-4ECF-92EF-FA988B4881C4@chriswendt.net> To: "stir@ietf.org" In-Reply-To: <391A1CF8-4CED-4ECF-92EF-FA988B4881C4@chriswendt.net> Message-Id: <4FF3FCD1-16AE-4FF6-B066-D1373E587B9B@standardstrack.com> X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [stir] Validating TN authority together with number portability X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 14:01:37 -0000 --Apple-Mail=_A2478964-3182-4595-BDFA-FD255D53B8E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For that matter, in North America the NPAC already has which operator is = supposed to manage a given ported TN. I=E2=80=99m not sure I see the = issue here. I suppose one could cross check to make sure the right = operator is signing, or is the root of distribution, for a given number. > On Aug 16, 2017, at 8:27 AM, Chris Wendt = wrote: >=20 > I think you would just cover this scenario with two different = certificates with the two smaller ranges. >=20 > That said, for North America the SHAKEN approach is not to use = certificates for number blocks, so not sure if you looking at a generic = solution or not. >=20 >> On Aug 16, 2017, at 5:21 AM, Julio Martinez-Minguito = wrote: >>=20 >> Hi, >>=20 >> The current drafts for RFC4474bis and certificates describe how to = validate that a telephone number is owned by the operator signing the = calling Identity. A TNAuthorizationList may be included in the = certificate listing the numbers the operator is authoritative for. >>=20 >> However, I see some issues handling this together with number = portability which need to be clarified. >> Subscribers will be ported in and out quite frequently, making the = information in the certificates obsolete. To keep up the pace with the = number portability, the operators certificates would have to be updated = frequently. Should the certificates have short validity times? E.g. 1 = week, or even shorter? >>=20 >> Instead of having the TN information in the certificate and need to = update it constantly, it would be more appropriate to have a trusted = server connected to the national Number Portability DB (to update the = information) to which the verifiers can connect and retrieve the = authority information. Each verifier could retrieve the TN lists for = operators and refresh the list daily, without needing to re-issue = operator certificates, so it would be updated with the latest = portability. >>=20 >> About how to represent the TN lists, e.g. if an operator owns the = range 555-xxxx, with the current definitions it will be easy to = describe: >> TelephoneNumberRange ::=3D SEQUENCE { >> start TelephoneNumber =3D 5550000, >> count INTEGER (2..MAX) =3D 10000 >> } >>=20 >> Now, if number 555-6789 moves to another operator we have to = represent with: >> ({start =3D 5550000, count =3D 6789}, {start =3D 5556790, count =3D = 3210}) >>=20 >> As more numbers are moved out from the range, this representation = format will get messy and difficult to manage. >>=20 >> To handle NP it would be easier to keep the original range, and = include a list of excluded numbers which have been ported out, e.g.: >>=20 >> TelephoneNumberRange ::=3D SEQUENCE { >> start TelephoneNumber, >> count INTEGER (2..MAX), >> excludedNumbers SEQUENCE SIZE (1..MAX) OF TNEntry >> } >>=20 >>=20 >> Is this a feasible solution? Is it too late to handle now due to the = current state? >> _______________________________________________ >> 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=_A2478964-3182-4595-BDFA-FD255D53B8E2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZnYqyAAoJEAwwhoe+fK7JGNgP/0+NWDcZVoRc0pCHw6/NEM5y +cv+oz/cp/z05Fq8Ew8iPPRjxr+vuxF2b+p4JyUnw3Ir8Ojjk1I5V5VKDZAul4Gs hZCdmTe9VMoJGYL3kFbU7A1DCb8H9inrlJU6jBxyk0nRq8hft5n6b8jGYsZj5MED tloM7/3WQ3UcIeBapqmaxwU5hNyI4z9UwfdY0dn3P5Pv/PverElp5GxzeeTa2T59 HaFhPsc/qrMOn/P+ghs1zbMGzWrXLB7Wi5XLwTHEgIU5fdr2EBgdikdV1Z8OHLWt +OUJhrNkcgSf/d68Ax4S8WoSOTBAKnwmOHMJd281xkHnAIFtuidkDFrqzNIJYF0F v+0ZTJWfFzJCwWF8H6SbWhdMt9b7x/q00ZRynFLd5iROtaM0nE8n6utPx/ZpzhaE v7ghne5gVwcxSRDcNZN+dzG0YwS9LPUbSyJCKqdZ2Ygp2yfHjMkhXdHOOf4dZVfy s+RXGf+QhaBjfwLNEACXnFIIG1/fsFDzgdHyWrsjM/iEMN5Fuz5xdGh2qqot2JLZ rYsPV5upn3JfembV+t27dL6Xd5pKw64JTKR9MJ2QctLn2p0DkzZRxKB3hxQaINqW myM7CcHK8hkQMWeS9FOD6/xO/XwM1Q52udGp+tcVZT3UYf595vVI6O+uIS0/nYOy WqsJnzfVKO800Qldotud =BPIV -----END PGP SIGNATURE----- --Apple-Mail=_A2478964-3182-4595-BDFA-FD255D53B8E2-- From nobody Wed Aug 23 07:32:23 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32719132C38 for ; Wed, 23 Aug 2017 07:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 OkeEG3dvf12F for ; Wed, 23 Aug 2017 07:32:19 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45BA132C37 for ; Wed, 23 Aug 2017 07:32:19 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id s143so1876502ywg.1 for ; Wed, 23 Aug 2017 07:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NOzWfbkHh++ieKYmNKpHIfmyDvlY++2qPL/oQRwKmHg=; b=bYU6wA7JX9TufpRAFLAfFL/TeLFxxioSH9JDvhCQKThX8B/v1By6qKBJ70HEh3hZS0 crZY4AuHRxVqcUmYOqpLAqB/kAE0otBBDct9EFEoLKgJAg88D8J3oZZYVbn2qxvJ0aEM LFxP4l7AtgyQ7vQ79Yw49OIIU17HpZuNshNZfIeZoseF3/vynpQm0Y2tZvfF8Qf+f1mQ L6yn9isQ2CiEdU8bobCALSgTEYIYM93mW3fptJb90KfVyrphq0IGlF/MzYmpzjfmozIO luBXDXgPAayEFsous8/WARbnQkGPxLZVG1EQpvIlKEEqG116ybuwylLFppa0g1Gg1MX4 cIeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NOzWfbkHh++ieKYmNKpHIfmyDvlY++2qPL/oQRwKmHg=; b=d80Kyf26fNlT9l5wGsgpdFbZf8TyH+A/Rup8PzQdy8WC/ErSXc1rSyUCGx289RU+vk 3LJ/IaS7RFzxpgyvTnrvUXJxCb6bglEUhBPr50Zln1coKI5zzyb1bafE3ryYmRsbh1Yf /1rC1SxJoaHs7L6/2C9YyG9bauZ7OJjTNiYe3OK2GwQXW/6DgGYBm6HLNGjRRymuMmHi tURHnXhwgAKFBAh3t8E6bH62Vu/f7SrkdLF6NbRy8DlwlvgiRw5kuWOvGBGFBs8PDqnJ AV/JoWkGtgIpOEavFVbF23LRs8TkwXav6hohRP+ovVlE3pwtyHpu+ubL+Pv5/9IxzgQe u44g== X-Gm-Message-State: AHYfb5g6rzTbd9aH5fctY8HDVzl4ziwjahIEkAGR0FNbcii80JisUCim 47vekbfZGxKvOm/1 X-Received: by 10.129.80.137 with SMTP id e131mr2299006ywb.309.1503498738769; Wed, 23 Aug 2017 07:32:18 -0700 (PDT) Received: from [10.33.193.3] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id d195sm598128ywe.103.2017.08.23.07.32.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 07:32:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: <4FF3FCD1-16AE-4FF6-B066-D1373E587B9B@standardstrack.com> Date: Wed, 23 Aug 2017 10:32:16 -0400 Cc: "stir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <649BEDC4-65D3-46D5-B2FC-059316CB6614@brianrosen.net> References: <391A1CF8-4CED-4ECF-92EF-FA988B4881C4@chriswendt.net> <4FF3FCD1-16AE-4FF6-B066-D1373E587B9B@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] Validating TN authority together with number portability X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 14:32:22 -0000 Resellers complicate it. > On Aug 23, 2017, at 10:01 AM, Eric Burger = wrote: >=20 > For that matter, in North America the NPAC already has which operator = is supposed to manage a given ported TN. I=E2=80=99m not sure I see the = issue here. I suppose one could cross check to make sure the right = operator is signing, or is the root of distribution, for a given number. >=20 >> On Aug 16, 2017, at 8:27 AM, Chris Wendt = wrote: >>=20 >> I think you would just cover this scenario with two different = certificates with the two smaller ranges. >>=20 >> That said, for North America the SHAKEN approach is not to use = certificates for number blocks, so not sure if you looking at a generic = solution or not. >>=20 >>> On Aug 16, 2017, at 5:21 AM, Julio Martinez-Minguito = wrote: >>>=20 >>> Hi, >>>=20 >>> The current drafts for RFC4474bis and certificates describe how to = validate that a telephone number is owned by the operator signing the = calling Identity. A TNAuthorizationList may be included in the = certificate listing the numbers the operator is authoritative for. >>>=20 >>> However, I see some issues handling this together with number = portability which need to be clarified. >>> Subscribers will be ported in and out quite frequently, making the = information in the certificates obsolete. To keep up the pace with the = number portability, the operators certificates would have to be updated = frequently. Should the certificates have short validity times? E.g. 1 = week, or even shorter? >>>=20 >>> Instead of having the TN information in the certificate and need to = update it constantly, it would be more appropriate to have a trusted = server connected to the national Number Portability DB (to update the = information) to which the verifiers can connect and retrieve the = authority information. Each verifier could retrieve the TN lists for = operators and refresh the list daily, without needing to re-issue = operator certificates, so it would be updated with the latest = portability. >>>=20 >>> About how to represent the TN lists, e.g. if an operator owns the = range 555-xxxx, with the current definitions it will be easy to = describe: >>> TelephoneNumberRange ::=3D SEQUENCE { >>> start TelephoneNumber =3D 5550000, >>> count INTEGER (2..MAX) =3D 10000 >>> } >>>=20 >>> Now, if number 555-6789 moves to another operator we have to = represent with: >>> ({start =3D 5550000, count =3D 6789}, {start =3D 5556790, count =3D = 3210}) >>>=20 >>> As more numbers are moved out from the range, this representation = format will get messy and difficult to manage. >>>=20 >>> To handle NP it would be easier to keep the original range, and = include a list of excluded numbers which have been ported out, e.g.: >>>=20 >>> TelephoneNumberRange ::=3D SEQUENCE { >>> start TelephoneNumber, >>> count INTEGER (2..MAX), >>> excludedNumbers SEQUENCE SIZE (1..MAX) OF TNEntry >>> } >>>=20 >>>=20 >>> Is this a feasible solution? Is it too late to handle now due to the = current state? >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Aug 23 14:38:20 2017 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6F3132A09 for ; Wed, 23 Aug 2017 14:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 4DosAKIZLxMY for ; Wed, 23 Aug 2017 14:38:16 -0700 (PDT) Received: from forward102p.mail.yandex.net (forward102p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BDE132A13 for ; Wed, 23 Aug 2017 14:38:14 -0700 (PDT) Received: from mxback12j.mail.yandex.net (mxback12j.mail.yandex.net [IPv6:2a02:6b8:0:1619::87]) by forward102p.mail.yandex.net (Yandex) with ESMTP id A932343033FE; Thu, 24 Aug 2017 00:38:11 +0300 (MSK) Received: from web4g.yandex.ru (web4g.yandex.ru [95.108.252.104]) by mxback12j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id aGmmyuN14H-cAOGTUuv; Thu, 24 Aug 2017 00:38:11 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1503524291; bh=M7GshBwH/ovf+p1tJiiIgK4A1WAb+srbADSo9WIYIW8=; h=From:To:Subject:Message-Id:Date; b=aQf+v/w84VOPkhlbo2SZAFiN05MfbDDI0EVCOkjFWc8RZ8XRoSpWx1wr7ZoDtuteH C07VwIPzNkO3RcOf9ayuo9IJIZ7IqUcNGTTYlefPCOV3ZBI9+t4f5qpEegZEd+Qaxk xP7FGMScIelJck2tmfyUrAW4aHlQ/q4VBr/qiMms= Authentication-Results: mxback12j.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web4g.yandex.ru with HTTP; Thu, 24 Aug 2017 00:38:10 +0300 From: Anton Tveretin To: "stir@ietf.org" , Richard Shockey MIME-Version: 1.0 Message-Id: <639281503524290@web4g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 24 Aug 2017 02:38:10 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: Re: [stir] FYI .. FCC Docket 17-97 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 21:38:19 -0000 This all gives me impression to do hop-to-hop authenticaton...