From nobody Thu Jan 9 21:50:19 2020 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 5E547120077; Thu, 9 Jan 2020 21:50:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Pete Resnick via Datatracker To: Cc: draft-ietf-stir-passport-divert.all@ietf.org, last-call@ietf.org, stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Pete Resnick Message-ID: <157863541224.17236.16527868532167283650@ietfa.amsl.com> Date: Thu, 09 Jan 2020 21:50:12 -0800 Archived-At: Subject: [stir] Genart last call review of draft-ietf-stir-passport-divert-07 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 05:50:12 -0000 Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Note that while this is labeled a Last Call review, this review comes well after the Last Call completed. However, the author and AD felt it would be useful anyway since the document has not yet been updated for Last Call comments. Document: draft-ietf-stir-passport-divert-07 Reviewer: Pete Resnick Review Date: 2020-01-09 IETF LC End Date: 2019-12-02 IESG Telechat date: Not scheduled for a telechat Summary: Ready with Nits While I found the document (and particularly section 4) very technically dense, I think the detail will help implementers tremendously. Nothing other than a few editorial issues. Major issues: None Minor issues: None Nits/editorial comments: Section 3, paragraph 1: Note that a new PASSporT is only necessary when the canonical form of the "dest" identifier (per the canonicalization procedures in [RFC8224] Section 8) changes due to this retargeting. If the canonical form of the "dest" identifiier is not changed during retargeting, then a new PASSporT with a "div" claim MUST NOT be produced. Seems to me that these two sentences should be in their own paragraph. It took me a second to figure out that the following sentence was not related to these. Section 4: ...Other using protocols of PASSporT Don't you mean "Other protocols using PASSporT"? Section 4.2, paragraph 2: I think you mean "necessarily", not "necessary" From nobody Fri Jan 10 08:40:34 2020 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 21F97120914; Fri, 10 Jan 2020 08:40:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: stir@ietf.org Message-ID: <157867442704.27573.9355675211465090689@ietfa.amsl.com> Date: Fri, 10 Jan 2020 08:40:27 -0800 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-rph-emergency-services-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 16:40:27 -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 WG of the IETF. Title : Assertion Values for a Resource Priority Header Claim in Support of Emergency Services Networks Authors : Martin Dolly Chris Wendt Filename : draft-ietf-stir-rph-emergency-services-00.txt Pages : 6 Date : 2020-01-10 Abstract: This document adds new assertion values for a Resource Priority Header ("rph") claim defined in RFC 8443, in support of Emergency Services Networks for emergency call origination and callback. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-rph-emergency-services-00 https://datatracker.ietf.org/doc/html/draft-ietf-stir-rph-emergency-services-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 12 11:48:53 2020 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 DD3F8120041 for ; Sun, 12 Jan 2020 11:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 fwLeE8kv2Hab for ; Sun, 12 Jan 2020 11:48:48 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750078.outbound.protection.outlook.com [40.107.75.78]) (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 1EC2F120013 for ; Sun, 12 Jan 2020 11:48:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g9WWGEVhSb0f1wcVdrVBigt67EQU16eO0hg59GtLjhHc6aAw2WMeYxSjlSmQwhpZc2CqoZT7257HYZGP6OdJbkd4gj1qALnsa8hfqUSRMmhHN5tmW5CBhaQKvUTeDIISZqAHU+WkMFkK58krMoMk9apvEF9yHMcRU8EkIvY9sYp71W2Mim2T5/B6iQyo+79joIT9Na9Kj9gNQFQAyrZeagG/kTa+NXLye+BOCGQR3uUrO6qKnJU4s2wd15WtmK6UI3dwOIiLaIKWNVSfNw8fpIVseWBYnJMgzo1rJbyCfDDcj+L+CCYUjFAXUAJ1Jl5pIveH96p/Efe/skPKw9QX9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dBLuc40KAD2vjV/AlY/SX1CC7KuBLQmQJ6gsYRKh/YE=; b=G5mYNC/xUuV9XOgvQZDvSo3Pphc6I19OKTddLdIw6odLYoACDhcSvnHu/1U4yvaBDsRkLUbj7m993o5DMV18nPuzndc4tuAQ0bGX2xi03SjvFhDziTi2dPLVyNUJIXe56FaBjvZ6z+2Gjte+cz/R1QxeyBqH7xOprHxdKgkXhzPgTnDK26ebay3o0VOezDylDxw6ZMQe4ubYs+Bo8qIdHeVl3k2G3ypjmJycVpLMyoXRRwPQ+/rGbZVSujX5yR0FOtIDMK4AvpEl7Ah7RgU+Mh/B0/N26WC92kqn40PbuAVnX4qo1oPcjBRnny4FeXRRouOn9IJ5BWB2ZLuH+E9bTw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dBLuc40KAD2vjV/AlY/SX1CC7KuBLQmQJ6gsYRKh/YE=; b=Bn0DYmGhboxEii2UlU663FYC3s+R8xowgQclGHK20tNjGOTXRFE7gmywlF7ZqQu1CjIfo8X3He3sxYGW5xUvdpIu+rA9etML3epdnWc0IvJVEOV9DiDgOV1t9lsTb5Yq/FH4jt3zaPPqbKXlgJJnPGfhJ0jBtMY2vN8ZYKoFDuE= Received: from DM6PR12CA0019.namprd12.prod.outlook.com (2603:10b6:5:1c0::32) by SN6PR12MB2829.namprd12.prod.outlook.com (2603:10b6:805:e8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10; Sun, 12 Jan 2020 19:48:45 +0000 Received: from SN1NAM02FT012.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::202) by DM6PR12CA0019.outlook.office365.com (2603:10b6:5:1c0::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13 via Frontend Transport; Sun, 12 Jan 2020 19:48:45 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT012.mail.protection.outlook.com (10.152.72.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9 via Frontend Transport; Sun, 12 Jan 2020 19:48:44 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 00CJmhji014888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Jan 2020 14:48:43 -0500 To: stir@ietf.org References: <157867442704.27573.9355675211465090689@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <3dd56be2-c6a0-6d9b-28b0-147d0a850d52@alum.mit.edu> Date: Sun, 12 Jan 2020 14:48:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <157867442704.27573.9355675211465090689@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(136003)(346002)(376002)(39860400002)(199004)(189003)(70586007)(478600001)(186003)(70206006)(26005)(53546011)(246002)(2906002)(8936002)(336012)(26826003)(8676002)(966005)(2616005)(7596002)(956004)(356004)(75432002)(6916009)(31686004)(66574012)(31696002)(36906005)(786003)(86362001)(316002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR12MB2829; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1bbb8d7c-4858-4d58-08a8-08d797986f06 X-MS-TrafficTypeDiagnostic: SN6PR12MB2829: X-LD-Processed: 3326b102-c043-408b-a990-b89e477d582f,ExtAddr,ExtFwd X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 02801ACE41 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: GvGT8A3zpqdbr9JAA02pZiWETrQUux5dW653dul3Fv75gMP5PxEfo6AYzkZRnsQuUxAa2NTDoJrm4MdhnFzzj7YVyJlNyrBYupyEBqbaD3dFw+fL9RExESMeHfFrUnPz7YMBHtf/G02v3k4ZdSGVO4VAm2Pcvz7FO2NIXTYOzXTZVcjx373rsPZGJtjQTZTJf3A/SW0yyV8KAvT3y5gJkcymr88q7tOLRUgPK97i+NZ2qv9flJkJ+tWMM2UMMtUDiK6xnMC7l2oLhanghBygJxnbRM0q+MoQKsYMfaAayYeGoYNb9xa3x1KXb7GbbSQcU19br6g5NPwn/J+f8r9ek1Zpn/GO4qN3V0dMMgReZ/3gQ78t3k75ItlZmgEvUzobcCDokV11pGN48DgNSDOWao2AcXZorRZ+fXav8AniGQYEVMCHCYTdtxOBdmriilJDT6Jb56VVbdBKZEOollc7D+vM690W1zjQkLou/oy0PF4= X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2020 19:48:44.8282 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1bbb8d7c-4858-4d58-08a8-08d797986f06 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR12MB2829 Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-rph-emergency-services-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 19:48:52 -0000 I'm having a little difficulty understanding the details of what constitutes a valid assertion. In section 3 I see: { "orig":{"tn":"CgPN"}, "dest":{["tn":"911 or URN-SOS"]}, "iat":1443208345, "rph":{"ESorig":["esnet,x"]} } This isn't ABNF so I don't know the rules for interpreting it. Some of the stuff enclosed in quotes is obviously intended to be literal. But other parts, also included in quotes, seem to placeholders. For instance "911 or URN-SOS" - I presume the assertion isn't actually supposed to literally include this. Rather, I guess it should be either "911" or "urn:service:sos". Similarly I *guess* "CgPN" is not intended to be literal. Do I get that right? If so, I think there needs to be some additional work to specify this clearly. You could specify the assertion format in ABNF, but maybe there is a better way. Thanks, Paul On 1/10/20 11:40 AM, 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 WG of the IETF. > > Title : Assertion Values for a Resource Priority Header Claim in Support of Emergency Services Networks > Authors : Martin Dolly > Chris Wendt > Filename : draft-ietf-stir-rph-emergency-services-00.txt > Pages : 6 > Date : 2020-01-10 > > Abstract: > This document adds new assertion values for a Resource Priority > Header ("rph") claim defined in RFC 8443, in support of Emergency > Services Networks for emergency call origination and callback. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-stir-rph-emergency-services-00 > https://datatracker.ietf.org/doc/html/draft-ietf-stir-rph-emergency-services-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From nobody Sun Jan 12 16:26:08 2020 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 930A3120045 for ; Sun, 12 Jan 2020 16:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 MPj7q8_hC3zN for ; Sun, 12 Jan 2020 16:26:05 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 A1FFE120013 for ; Sun, 12 Jan 2020 16:26:05 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id x129so7073182qke.8 for ; Sun, 12 Jan 2020 16:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kuSHizC4H6aNIjplX2H0GGfec225apZHaVoU104sprU=; b=UQAjHhAggqI8U2Fp1xeVV3u0GGAMIiKJlZRenJKWZ2NFMBBvCSlTUml3euMeJz/tjg V6m141ERcBY9oOWesZqh2+MlG7066ngq9bAKIsb+wtuXS5KxVfnLI4UJOfD4CKHXoq/n HR+vZ3UbJGLhHWfndrN1ojzg6tA2uhYLZWpnpzIicveJXTfyyIPXGKITCex3USEOFhdS SbT57S/VH6GId0K44WGabs+7wXXp64RGnyU2iz+dlWNMLmrFXyW4R457WAonMBCn70Mv uOoXBRmfLyu0rDGSc74YWkP9YhMtfQM4fUUKaGrEYgqU4sIp0+TIpibKBdRfh1UYg6dC QFRQ== 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=kuSHizC4H6aNIjplX2H0GGfec225apZHaVoU104sprU=; b=nOD+IizvpzBMWcKMC2IT24Hz7njGpuZwPVdIMHJrqGCTRjzCqfzNrRAevPoa+LDSAv SPSstryfx/VA4ogU54CGwT2EyfrxnY7GwUHByI5amirU5wQ8+ObZb8aKMT1qVL4cDxXZ VzR+dR3LU8SadBWA6GlVM+AH/U9CTVDmgap5Kjsp8QOYNIW/s1zNUCKbU0FNxOAlL3uH C1sb4j86iIEEb7wbNdYi/A+Ie5yeFC9TEwka9ktvHxEF6QDdk4i/VSJOAAKtcpxPE2CX QwgrAKX81R/3fNCJo7/DE/nojzbk/U9PA2aS/7qF283ow0jKuzMRvUTEEPELdU4GFZzE uXDQ== X-Gm-Message-State: APjAAAXkNV0JDaSgPAL3Xb4sXgFhn7iU5k/R3MTygWzErvusqeZtEJF2 KBYEzaDHqjGo2L8WdqSxmBBHUQ== X-Google-Smtp-Source: APXvYqx0kAhkPVJi7wcyOLGxCnLdiMlMwBWz2PzLmsfr2ms3HCextUaSeEGC47jVT7cfWioZ9KC2Hg== X-Received: by 2002:a05:620a:136e:: with SMTP id d14mr13614073qkl.342.1578875164665; Sun, 12 Jan 2020 16:26:04 -0800 (PST) Received: from [10.0.0.111] (c-69-139-1-231.hsd1.pa.comcast.net. [69.139.1.231]) by smtp.gmail.com with ESMTPSA id w1sm4950267qtk.31.2020.01.12.16.26.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jan 2020 16:26:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Chris Wendt In-Reply-To: <3dd56be2-c6a0-6d9b-28b0-147d0a850d52@alum.mit.edu> Date: Sun, 12 Jan 2020 19:26:03 -0500 Cc: stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7C5A6A7A-4EF2-40EF-8302-3FBD47D69B09@chriswendt.net> References: <157867442704.27573.9355675211465090689@ietfa.amsl.com> <3dd56be2-c6a0-6d9b-28b0-147d0a850d52@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-rph-emergency-services-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 00:26:07 -0000 Hi Paul, I think we do intend to make that clearer and provide explicit rules. = We had a discussion at the meeting about what the URN should be, etc. So = hoping we can make progress on that for next version. -Chris > On Jan 12, 2020, at 2:48 PM, Paul Kyzivat = wrote: >=20 > I'm having a little difficulty understanding the details of what = constitutes a valid assertion. In section 3 I see: >=20 > { > "orig":{"tn":"CgPN"}, > "dest":{["tn":"911 or URN-SOS"]}, > "iat":1443208345, > "rph":{"ESorig":["esnet,x"]} > } >=20 > This isn't ABNF so I don't know the rules for interpreting it. Some of = the stuff enclosed in quotes is obviously intended to be literal. But = other parts, also included in quotes, seem to placeholders. >=20 > For instance "911 or URN-SOS" - I presume the assertion isn't actually = supposed to literally include this. Rather, I guess it should be either = "911" or "urn:service:sos". Similarly I *guess* "CgPN" is not intended = to be literal. >=20 > Do I get that right? >=20 > If so, I think there needs to be some additional work to specify this = clearly. You could specify the assertion format in ABNF, but maybe there = is a better way. >=20 > Thanks, > Paul >=20 > On 1/10/20 11:40 AM, 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 = WG of the IETF. >> Title : Assertion Values for a Resource Priority = Header Claim in Support of Emergency Services Networks >> Authors : Martin Dolly >> Chris Wendt >> Filename : draft-ietf-stir-rph-emergency-services-00.txt >> Pages : 6 >> Date : 2020-01-10 >> Abstract: >> This document adds new assertion values for a Resource Priority >> Header ("rph") claim defined in RFC 8443, in support of Emergency >> Services Networks for emergency call origination and callback. >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/ >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-stir-rph-emergency-services-00 >> = https://datatracker.ietf.org/doc/html/draft-ietf-stir-rph-emergency-servic= es-00 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Jan 23 15:23:15 2020 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 4DA1D1200F9 for ; Thu, 23 Jan 2020 15:23:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157982179331.22601.523633373193652345.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2020 15:23:13 -0800 From: IETF Secretariat Archived-At: Subject: [stir] Milestones changed for stir WG X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 23:23:13 -0000 Changed milestone "Submit PASSPorT extension for diverted calls as Proposed Standard", resolved as "Done". Changed milestone "Submit out-of-band architecture and use-cases for Informational", resolved as "Done". Changed milestone "Submit Privacy analysis for Informational", Milestone order changed from 9 to 11. URL: https://datatracker.ietf.org/wg/stir/about/ From nobody Thu Jan 23 15:29:29 2020 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 16FEF1200F3 for ; Thu, 23 Jan 2020 15:29:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157982216809.22847.17798272962839232098.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2020 15:29:28 -0800 From: IETF Secretariat Archived-At: Subject: [stir] Milestones changed for stir WG X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 23:29:28 -0000 Changed milestone "Submit Assertion Values for a Resource Priority Header Claim in Support of Emergency Services Networks as Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Submit STIR Certificate Delegation as Proposed Standard", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/stir/about/ From nobody Thu Jan 23 15:32:12 2020 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 B42A61200CD for ; Thu, 23 Jan 2020 15:32:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157982233073.22810.16901516854421766722.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2020 15:32:10 -0800 From: IETF Secretariat Archived-At: Subject: [stir] Milestones changed for stir WG X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 23:32:11 -0000 Changed milestone "Submit PASSPorT Extension for rich call data for publication as Proposed Standard", added draft-ietf-stir-passport-rcd to milestone. URL: https://datatracker.ietf.org/wg/stir/about/ From nobody Wed Jan 29 12:01:19 2020 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 16AB6120969 for ; Wed, 29 Jan 2020 12:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 joDTVtl7Go-k for ; Wed, 29 Jan 2020 12:01:06 -0800 (PST) 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 ECEDA12087A for ; Wed, 29 Jan 2020 12:00:25 -0800 (PST) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 00TK09re034723 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 Jan 2020 14:00:10 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1580328011; bh=nAy/mUWs+h7xBMZmIKJdwAWlwjWwNLT5Eya18HxtK8c=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=qfevTY3of1M1UXzLOBNw+VXpC0hcYOxIBUXQw+AN3Iww12FJpMkU0tD+ZXixHTOAA mX9fSyhA/34BhIPLZJQOwWyAyy3BxkzAIhnbhRRDkLlONz8uUoxtYuxZ/bQrH9DH1q kEKL97CWgxmRA9osR37X7BqS7/rBemcjPePgt2V0= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Paul Kyzivat , "DOLLY, MARTIN C" Cc: "stir@ietf.org" References: <00593B03-11CE-4364-97AF-79B53881FCF6@vigilsec.com> <13e7729e-38e4-9e6e-5c66-1c8b680ee7d0@alum.mit.edu> <22C9E60D-45A4-4DA1-A78D-0720BE8B90AE@att.com> From: Robert Sparks Message-ID: <31a8d160-1315-f11d-366f-9fc4ee1cb7a8@nostrum.com> Date: Wed, 29 Jan 2020 14:00:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [stir] URN SOS X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 20:01:16 -0000 Just to make sure this part of the thread is addressed: The context was a discussion about allowing calls that used an SOS URI as the call destination (the To: header field value) to be covered by STIR. The concern was raised on whether STIR supports that at the moment.  There was concern that the discussion of identities in RFC8225, constrained the use of 'uri' to really only mean SIP urls. Discussion started, and should continue here about whether that's correct, and if so, what changes would need to be made. I don't think anyone intended to propose a _new_ URI. I think speaking/typing quickly introduced that confusion, and I believe we're past that. My own opinion is that 8224/8225 don't constrain the use of 'uri' in a way that prevents putting the sos urn in the dest, and that the most we need to do is think about the consequences of doing so (to look for unexpected rough edges), and possibly provide some information guidance on their use. RjS > On 12/23/19 11:51 AM, DOLLY, MARTIN C wrote: >> Paul >> >> That is what was discussed in the meeting > > If it is to be discussed on this list, then can some of the context be > brought here to the list as well? > >     Thanks, >     Paul > >> Regards >> >> Martin C. Dolly >> >> Lead Member of Technical Staff >> >> Government & Services Standards >> >> AT&T >> >> Cell: +1.609.903.3360 >> >> Email: md3135@att.com >> >> >> On Dec 23, 2019, at 10:09 AM, Paul Kyzivat > > wrote: >> >>> On 12/23/19 9:02 AM, Anders Kristensen wrote: >>>> May have to do with the fact that RFC 8224 does not cover URNs: >>> >>> If the problem is that URNs aren't covered, then how would replacing >>> urn:service:sos with urn:sos solve the problem??? >>> >>> The use of urn:service:sos is institutionalized now in a lot of >>> documents. Changing that seems like a hard problem. How about fixing >>> RFC 8224? >>> >>>    Thanks, >>>    Paul >>> >>>>    1 >>>> >>> >. Introduction >>>>    This document provides enhancements to the existing mechanisms for >>>>    authenticated identity management in the Session Initiation >>>> Protocol >>>>    (SIP) [RFC3261 >>>>  >>> >].  An identity, for the purposes of this document, is >>>>    defined as either >>>>    o  a canonical address-of-record (AoR) SIP URI employed to reach a >>>>       user (such as "sip:alice@atlanta.example.com >>>>  ") or >>>>    o  a telephone number, which commonly appears either in a tel URI >>>>       [RFC3966 >>>>  >>> >] or as the user portion of a SIP URI. >>>> On Sun, Dec 22, 2019 at 1:14 PM Russ Housley >>> > wrote: >>>>    Richard: >>>>    It seems to meet the need that was raised in the discussion.  >>>> Others >>>>    can comment if I missed some important context. >>>>    Russ >>>>>    On Dec 22, 2019, at 3:38 PM, Richard Barnes >>>> >>>>>    > wrote: >>>>> >>>>>    Not sure if this is what you’re thinking of, or if this has >>>>>    already been mentioned, but: urn:service:sos exists. >>>>> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5031&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=YFxpwD-sFZG8qj0YD1Q3dYHCnMgjeMIRRHjMWcakYeI&e= >>>>> >>>>> >>>>>    On Sat, Dec 21, 2019 at 17:26 Russ Housley >>>>> >>>>>    > wrote: >>>>> >>>>>        At the session at IETF 106, there was a suggestion that a URN >>>>>        SOS be defined.  I am sending this note to start a discussion >>>>>        on that topic. >>>>> >>>>>        Russ >>>>>        _______________________________________________ >>>>>        stir mailing list >>>>> stir@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= >>>>> >>>>>    _______________________________________________ >>>>>    stir mailing list >>>>> stir@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= >>>>> >>>>    _______________________________________________ >>>>    stir mailing list >>>> stir@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= >>>> >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= >>> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Jan 29 12:17:37 2020 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 C316612008B for ; Wed, 29 Jan 2020 12:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=alum.mit.edu 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 Ub9Rqb5R-xb4 for ; Wed, 29 Jan 2020 12:17:32 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2082.outbound.protection.outlook.com [40.107.220.82]) (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 A9C5C120048 for ; Wed, 29 Jan 2020 12:17:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dlQpatN3T73FwKqKOGrL6EQj3yeG8siNiXSahttwAH7aLg2AB2lJM7brHhwNTQgQP8Md01NBJ6qJcvrOFaCGn/ERd0xoBXhwXAI3c9RbnER+d+TH1jSKVds5RhnNiJz5e8dFkGowFeYHwUdZOW8d5/6ec3DFbRSmTUdApsReJWZHoo8gFalGT4kvRybAtPQ45xPPodgLWkS+ZB1IdKUNDPUenxmreTFxhXOY1ga4xFgEN19o6EQWl/ukE462aaKEmN53Uh0FqKtZJRKAbNL837+pqpRngSPgVg6SiKFcGC8uOXYLIdp8GA9zn42Z2BgMaUqUJ5g91B78MDAKf+oaVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JN2DOLqXtsiqxwvFyCm9Y1fatsCmY5znyiH1XP2S0tI=; b=oePfY1VpjMY9LPhqMGhBnXElX2yC9+b1AS0AKvtLlUnNONDSD2kLw/AmFvUA5S4uzcGHsNdblXYu92TAwh87CmI0oCgAgbVbsdO4V+5dYRhfmiZxGaUQySn8yThq+OaUeIA3Z9t9fECUzmfy7ri3m7wMTkqoMiCVkn4J4otP+90T8SkgZH2s9HpaMMK1UbrrCxz77iSbpoeCEJMBPNS+1S5Q0kJ5UUTJW0AzFwE6XWY8ehHgcmYFoLGf0N+WvPuo5SnxH0qOYLq1vEbwO8n5H62lJG81GBftJC10bWcjcUwHCXPhCeX7XOUMybtH3KpSve+0gce1rT2an3AIzJ+ayA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=nostrum.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JN2DOLqXtsiqxwvFyCm9Y1fatsCmY5znyiH1XP2S0tI=; b=Dda9xc/4Rvu8uh9pO2PyBkCuUub9KoNTx0+1k8ZF+WHyIW7drBVtK1vftM04Flw+4BQpBUinxaFqui0v2AAydrKVoiG3x4DabUg/BGormRp30oqNjanKg+8yzP5+sBTVKi5NgRZNKb4kmHxc0SlHPYdTz8kbIpy2lzo3ItTLOek= Received: from DM5PR12CA0002.namprd12.prod.outlook.com (2603:10b6:4:1::12) by MN2PR12MB3245.namprd12.prod.outlook.com (2603:10b6:208:103::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.24; Wed, 29 Jan 2020 20:17:30 +0000 Received: from SN1NAM02FT036.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::205) by DM5PR12CA0002.outlook.office365.com (2603:10b6:4:1::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.19 via Frontend Transport; Wed, 29 Jan 2020 20:17:30 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT036.mail.protection.outlook.com (10.152.72.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.25 via Frontend Transport; Wed, 29 Jan 2020 20:17:29 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 00TKHPIu001867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jan 2020 15:17:26 -0500 To: Robert Sparks , "DOLLY, MARTIN C" Cc: "stir@ietf.org" References: <00593B03-11CE-4364-97AF-79B53881FCF6@vigilsec.com> <13e7729e-38e4-9e6e-5c66-1c8b680ee7d0@alum.mit.edu> <22C9E60D-45A4-4DA1-A78D-0720BE8B90AE@att.com> <31a8d160-1315-f11d-366f-9fc4ee1cb7a8@nostrum.com> From: Paul Kyzivat Message-ID: <15992fa6-5852-c706-04df-52302dfc3920@alum.mit.edu> Date: Wed, 29 Jan 2020 15:17:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <31a8d160-1315-f11d-366f-9fc4ee1cb7a8@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(346002)(376002)(199004)(189003)(26005)(7596002)(31696002)(956004)(5660300002)(186003)(336012)(31686004)(70206006)(53546011)(4326008)(356004)(2616005)(70586007)(8936002)(36906005)(110136005)(316002)(786003)(75432002)(2906002)(966005)(246002)(8676002)(478600001)(26826003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR12MB3245; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cda3f724-0fb4-4d0b-f37e-08d7a4f84423 X-MS-TrafficTypeDiagnostic: MN2PR12MB3245: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3513; X-Forefront-PRVS: 02973C87BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: WgITp8WM2My5ghnQSL/GPxPvec0NCh7iYmOawg6SWHNoQ2J9LR7GymoB+GgpP9n1qbihjpn1cTZZjZ4YAvbPGT3HW1kUn0ly80jqYeNhhtLDRHQghFuHbsAI/Ez22S/BI+AK30et9vtksXo7v/Ki7aXK8jqv/1JaR8hsGi4RLs0BN9mU2lJVBhw9lNZdoyqaseXodzzW2j6GsXV/D1bA/AzxuJ7Ptp2TlH1THY3woXwEEwBa/irJgDp9GPcTMxZGAS1Y4z46WtbsfGWxRo7iO0B1qVuiMrao3mKRCl+D5mIUh5bBJYbbpXG5Qpkdh5URjHcImCJ9xqHwgstC0fcZ3qqYiWFChoI1d38HOp44KukFAOlKNHQXibL01nJq2eD5zOMV/C/KZjUmpGpVuPHTyr9UZ+Ob7hfLS+tGXtOgxzvEDbDayC4puw091txCiCZSSxOvDx+nc0Tr+dsJcp0CTxLJZt9d+avUhglr/gAiZAuXPxt+5h/8FAKsghiCWkU8cR73CdCDk5M/f3Dcoal2Mw== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2020 20:17:29.6034 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cda3f724-0fb4-4d0b-f37e-08d7a4f84423 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3245 Archived-At: Subject: Re: [stir] URN SOS X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 20:17:35 -0000 On 1/29/20 3:00 PM, Robert Sparks wrote: > Just to make sure this part of the thread is addressed: > > The context was a discussion about allowing calls that used an SOS URI > as the call destination (the To: header field value) to be covered by > STIR. The concern was raised on whether STIR supports that at the > moment.  There was concern that the discussion of identities in RFC8225, > constrained the use of 'uri' to really only mean SIP urls. Discussion > started, and should continue here about whether that's correct, and if > so, what changes would need to be made. > > I don't think anyone intended to propose a _new_ URI. I think > speaking/typing quickly introduced that confusion, and I believe we're > past that. > > My own opinion is that 8224/8225 don't constrain the use of 'uri' in a > way that prevents putting the sos urn in the dest, and that the most we > need to do is think about the consequences of doing so (to look for > unexpected rough edges), and possibly provide some information guidance > on their use. Thanks. That relieves my concern. I look forward to seeing more on this. Thanks, Paul > RjS > >> On 12/23/19 11:51 AM, DOLLY, MARTIN C wrote: >>> Paul >>> >>> That is what was discussed in the meeting >> >> If it is to be discussed on this list, then can some of the context be >> brought here to the list as well? >> >>     Thanks, >>     Paul >> >>> Regards >>> >>> Martin C. Dolly >>> >>> Lead Member of Technical Staff >>> >>> Government & Services Standards >>> >>> AT&T >>> >>> Cell: +1.609.903.3360 >>> >>> Email: md3135@att.com >>> >>> >>> On Dec 23, 2019, at 10:09 AM, Paul Kyzivat >> > wrote: >>> >>>> On 12/23/19 9:02 AM, Anders Kristensen wrote: >>>>> May have to do with the fact that RFC 8224 does not cover URNs: >>>> >>>> If the problem is that URNs aren't covered, then how would replacing >>>> urn:service:sos with urn:sos solve the problem??? >>>> >>>> The use of urn:service:sos is institutionalized now in a lot of >>>> documents. Changing that seems like a hard problem. How about fixing >>>> RFC 8224? >>>> >>>>    Thanks, >>>>    Paul >>>> >>>>>    1 >>>>> >>>> >. Introduction >>>>>    This document provides enhancements to the existing mechanisms for >>>>>    authenticated identity management in the Session Initiation >>>>> Protocol >>>>>    (SIP) [RFC3261 >>>>>  >>>> >].  An identity, for the purposes of this document, is >>>>>    defined as either >>>>>    o  a canonical address-of-record (AoR) SIP URI employed to reach a >>>>>       user (such as "sip:alice@atlanta.example.com >>>>>  ") or >>>>>    o  a telephone number, which commonly appears either in a tel URI >>>>>       [RFC3966 >>>>>  >>>> >] or as the user portion of a SIP URI. >>>>> On Sun, Dec 22, 2019 at 1:14 PM Russ Housley >>>> > wrote: >>>>>    Richard: >>>>>    It seems to meet the need that was raised in the discussion. Others >>>>>    can comment if I missed some important context. >>>>>    Russ >>>>>>    On Dec 22, 2019, at 3:38 PM, Richard Barnes >>>>> >>>>>>    > wrote: >>>>>> >>>>>>    Not sure if this is what you’re thinking of, or if this has >>>>>>    already been mentioned, but: urn:service:sos exists. >>>>>> >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5031&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=YFxpwD-sFZG8qj0YD1Q3dYHCnMgjeMIRRHjMWcakYeI&e= >>>>>> >>>>>> >>>>>>    On Sat, Dec 21, 2019 at 17:26 Russ Housley >>>>>> >>>>>>    > wrote: >>>>>> >>>>>>        At the session at IETF 106, there was a suggestion that a URN >>>>>>        SOS be defined.  I am sending this note to start a discussion >>>>>>        on that topic. >>>>>> >>>>>>        Russ >>>>>>        _______________________________________________ >>>>>>        stir mailing list >>>>>> stir@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= >>>>>> >>>>>>    _______________________________________________ >>>>>>    stir mailing list >>>>>> stir@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= >>>>>> >>>>>    _______________________________________________ >>>>>    stir mailing list >>>>> stir@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= >>>>> >>>> >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= >>>> >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir