From nobody Fri Sep 18 08:52:36 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F883A0F11 for ; Fri, 18 Sep 2020 08:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 U9M51a2ycHdP for ; Fri, 18 Sep 2020 08:52:27 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2076.outbound.protection.outlook.com [40.107.243.76]) (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 389AC3A0F24 for ; Fri, 18 Sep 2020 08:52:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JnI51qzJCeQA6jzTb7fva6rIMQ5baDWfmbI+jpfTKI8oKwRbX1ltGeOpJXR2zyhxrl6hdN4FmKHFd5klDO23tucOtB/VneWP7JXhhlh9mnIy97sL/ON1pyZ7tDVruVI4bhpWIzVz7V3trpp2sYpPlHNDWIsqC1wU5iSiRgxc1l3ObuwpxbI/c7eakzR7oNSO9LxUvT54Ju9lMEg8dTERQ4X+c1e61r2D5JIeYPQHSV2/RqBdKpDpGRPXrG/zpt0Hrvidb+KrYm/nyHwnstu52kYXpXykJmr+zVOrGe4nbAUoGK4TotOLSwDF9SxIoWDgrpbUTvwL/f4OfKMQNGhDBA== 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=RHtWYZX+UNc+Z98r44MerOXmF/XrkJ+493Nbjqmw1qo=; b=OzvzwFPqvt8frUxk3BgGTVD9wz/qK+0IEid4zYFpjwKr04PEEeIFnveYytcTRCWg14WvGr/Q+0rvJHE6j+C999bViwFHlVXD/Q+Qk/+nYdzBqQGtMLZFiUE139xaXuRdTFhwAjE82WqkUiQjqfwGjpUizePskI0AkBjmD+eocEtO6Zku9cHJ8m3syvaYNqAkzBpThhu5QwTZSxcX3q+GXg6W+S07CXBrPQtobtf1gdBk79AtBkQhGdvpfvLvmDbkk6wVUxCOXqDBoCxD46CM1Rpdg4qGRUTOGx+9ZGS7P7YOdZVBtOaE1WH/yPc0cIFsOlOURtjUyvx+VG7ygBfg5w== 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=RHtWYZX+UNc+Z98r44MerOXmF/XrkJ+493Nbjqmw1qo=; b=fGZKWxlJucDWniOG8T0ErZArRcBzHrcRu3YQIX7JUj5iWLFhOCm2uzFuN61DM3U24PDXZanf9sSkGGee0JfTT9/OA1q71UE6A3rovKCATE/WFawgXMp0cGMVdQQNdLvMqsJP56AOkTx0CE/zvZ37R0mFwy6E0lLlCQrEa0oFJLQ= Received: from MN2PR05CA0043.namprd05.prod.outlook.com (2603:10b6:208:236::12) by CY4PR1201MB0165.namprd12.prod.outlook.com (2603:10b6:910:1c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.17; Fri, 18 Sep 2020 15:52:24 +0000 Received: from BL2NAM02FT053.eop-nam02.prod.protection.outlook.com (2603:10b6:208:236:cafe::71) by MN2PR05CA0043.outlook.office365.com (2603:10b6:208:236::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.9 via Frontend Transport; Fri, 18 Sep 2020 15:52:24 +0000 X-MS-Exchange-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 BL2NAM02FT053.mail.protection.outlook.com (10.152.76.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15 via Frontend Transport; Fri, 18 Sep 2020 15:52:24 +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 08IFqMIO003688 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 18 Sep 2020 11:52:23 -0400 To: rum@ietf.org References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Fri, 18 Sep 2020 11:52:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 60a9cc5d-9a49-409e-c21e-08d85bead5d5 X-MS-TrafficTypeDiagnostic: CY4PR1201MB0165: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eKMo81AGPRnxL91dDXjds4nbtwNpNh2yUKGNgFYxlHFGtdX8FjCGrYOOleCVCCy+oP10AIzj+K+pXHS9OmI7C4vr18pHnHkCTzZqL1fjokj5mNQVGKujwY7C0FzfEPGHawRoBfQgCDBKx4NjcoxZebxrSkjNuKSUzwl6IP4zj2X+jJ3fq3lYOv/5YQtYNmWe+1FItrFqFmyW/PsOe/q68A015fkF+6L8TjaQu2ZOZmN1Buu4ElG2KnYOczTQKVWTGL9/wazKT3PGPwciUnU49P9t1MCr1dxJyZzekAYk1yebhyaZ/af/UzsreKGAZJ4BlZlSLm4eHG4UBQQGfBiotr9/X7o+0/dv+vmXxNNzcZWoU+GbFrZXGlp+xOP5gTglch8hU93Owf9tifJ0HYZrpKaidGngMMbKJMdrte4QqxHlw2KlMDoDwVlFxiCtzNk+8ndHVBVLcwp5uDecND5Bajnzof1+vp97dXmbCpmYIUeiHSFKWRoJm+o2jMGe3b68 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(346002)(376002)(396003)(136003)(39860400002)(46966005)(186003)(478600001)(53546011)(5660300002)(786003)(316002)(956004)(336012)(31686004)(2616005)(36906005)(6916009)(86362001)(31696002)(2906002)(26005)(8676002)(75432002)(8936002)(83380400001)(66574015)(7596003)(47076004)(82740400003)(356005)(82310400003)(70586007)(70206006)(966005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2020 15:52:24.0376 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 60a9cc5d-9a49-409e-c21e-08d85bead5d5 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-AuthSource: BL2NAM02FT053.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1201MB0165 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2020 15:52:35 -0000 Brian, Thanks for reviving this and resolving some of the open issues. I hope we can soon identify and resolve remaining issues. I do think the password issue is going to be tricky to sort out. We should get a discussion going on it. I'm thinking that we may need a whole section discussing the security model. The new text about uploading the geoloc to the registrar seems to introduce an additional issue for the security considerations section. Another thing not discussed here is the desire by the providers to have a mechanism to restrict access to client implementations that have been previously validated. AFAIK this is hard to achieve. I don't think a workable mechanism has been proposed. Thanks, Paul On 8/25/20 5:00 PM, Brian Rosen wrote: > This version tries to address comments made.  The most extensive change > is the schemas, which are now full json schemas and pass validation, as > well as a check to make sure the examples validate to the schemas. > > I haven’t done anything about the config file password issue yet, and > there are at least 2 or 3 other dangling items.  I’ll start separate > threads on those. > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-03.txt >  may be > helpful for you to see what I did. > > Brian > > >> On Aug 25, 2020, at 4:49 PM, internet-drafts@ietf.org >> wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Relay User Machine WG of the IETF. >> >>        Title           : Interoperability Profile for Relay User Equipment >>        Author          : Brian Rosen >> Filename        : draft-ietf-rum-rue-03.txt >> Pages           : 32 >> Date            : 2020-08-25 >> >> Abstract: >>   Video Relay Service (VRS) is a term used to describe a method by >>   which a hearing persons can communicate with deaf/Hard of Hearing >>   user using an interpreter ("Communications Assistant") connected via >>   a videophone to the deaf/HoH user and an audio telephone call to the >>   hearing user.  The CA interprets using sign language on the >>   videophone link and voice on the telephone link.  Often the >>   interpreters may be supplied by a company or agency termed a >>   "provider" in this document.  The provider also provides a video >>   service that allows users to connect video devices to their service, >>   and subsequently to CAs and other dead/HoH users.  It is desirable >>   that the videophones used by the deaf/HoH/H-I user conform to a >>   standard so that any device may be used with any provider and that >>   video calls direct between deaf/HoH users work.  This document >>   describes the interface between a videophone and a provider. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ >> >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-rum-rue-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-03 >> >> >> 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/ >> >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum > > From nobody Mon Sep 21 02:04:39 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7759B3A0AF6 for ; Mon, 21 Sep 2020 02:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 9Nu-L2TDxG6L for ; Mon, 21 Sep 2020 02:04:37 -0700 (PDT) Received: from outbound-ip1a.ess.barracuda.com (outbound-ip1a.ess.barracuda.com [209.222.82.168]) (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 608993A0AF1 for ; Mon, 21 Sep 2020 02:04:37 -0700 (PDT) Received: from smtp.purple.us (smtp01.purple.us.91.17.208.in-addr.arpa [208.17.91.143]) by mx3.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 21 Sep 2020 09:04:34 +0000 Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 21 Sep 2020 02:04:33 -0700 Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Mon, 21 Sep 2020 02:04:33 -0700 From: James Hamlin To: "rum@ietf.org" Thread-Topic: [Rum] I-D Action: draft-ietf-rum-rue-03.txt Thread-Index: AQHWj/Gl4E/+9/1icEKqjKU/sGCygg== Date: Mon, 21 Sep 2020 09:04:32 +0000 Message-ID: <1600679072074.473@purple.us> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_1600679072074473purpleus_" MIME-Version: 1.0 X-BESS-ID: 1600679073-893004-18708-162632-1 X-BESS-VER: 2019.1_20200918.2058 X-BESS-Apparent-Source-IP: 208.17.91.143 X-BESS-Outbound-Spam-Score: 0.20 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.227041 [from cloudscan20-197.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound 0.20 BSF_SC0_SA953 META: Custom Rule BSF_SC0_SA953 0.00 HTML_IMAGE_ONLY_20 BODY: HTML: images with 1600-2000 bytes of words X-BESS-Outbound-Spam-Status: SCORE=0.20 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND, BSF_SC0_SA953, HTML_IMAGE_ONLY_20 X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 09:04:38 -0000 --_000_1600679072074473purpleus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian Thanks for the new draft. I think the final sentence in section 5.2.5. "Emergency Calls" is out of sc= ope, as it tries to define the interface between the VRS provider and the P= SAP. From the rest of the text, the purpose of the data exchange between RU= E and VRS provider is already clear; the final sentence could be dropped wi= thout detracting from the description of the RUM interface. I propose dropp= ing the text: "Providers MUST implement Data Provider and Service Informati= on blocks as the call is forwarded to the PSAP.". Best Regards James [X][X] [X]James Hamlin Contractor Purple, a Division of ZP Better Together, LLC purplevrs.com The information contained in this e-mail message is intended only for the p= ersonal and confidential use of the recipient(s) named above. If you have r= eceived this communication in error, please notify us immediately by e-mail= , and delete the original message. --_000_1600679072074473purpleus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Brian


Thanks for the new draft.


I think the final sentence in section 5.2.5. "Emergency Calls"=  is out of scope, as it tries to define the interface b= etween the VRS provider and the PSAP. From the rest of the text, the purpos= e of the data exchange between RUE and VRS provider is already clear; the final sentence could be dropped without det= racting from the description of the RUM interface. I propose= dropping the text: "Providers MUST implement Data Provider and Se= rvice Information blocks as the call is forwarded to the PSAP.".<= br>


Best Regards


James


J= ames Hamlin
Contractor
Purple, a Division of ZP Better Together, LLC
purplevrs.com

The information cont= ained in this e-mail message is intended only for the personal and confiden= tial use of the recipient(s) named above. If you have received this communi= cation in error, please notify us immediately by e-mail, and delete the original message.

--_000_1600679072074473purpleus_-- From nobody Mon Sep 21 07:47:51 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53C23A1066 for ; Mon, 21 Sep 2020 07:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 f12f-0wAVY0d for ; Mon, 21 Sep 2020 07:47:48 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2049.outbound.protection.outlook.com [40.107.237.49]) (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 29D873A1058 for ; Mon, 21 Sep 2020 07:47:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lavLSnKNvzXpGk15ur0wEYhz3jMJ0LybM62IZJjTdk4wDniT2QIRHKk18tWa8TbDrRElXSU6DSo5G48MzGdsoNDkIZjuaz33CzV/EtyQoGO1xI094VRYvstxQt24bS4tQ0YU9T2dphnPWJGH4F6J9jIY01WOQ1CrFnfFsa/KgblyOq+5ZP5oKMUpkYtciCekFnWZQTrJz1hglQ1n5f41m/81Hxve52BAMvlYXtQJtFJ2jIpefbBlAquPXBaSvAG9q69M6Mgco/qe3ljfEU5iEjZi9vvIk0JamyCcE3ivcGINNE+KponNo0DYeAqMbCz9ioAWPgscdgZY01P2aZm61A== 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=qHBmTxc82ZLiHi/+jviCek+oUm3Clx8EuJVTYkstZVY=; b=SMEZkWkiPpmA5M1P6+s1784wCribmSkgiD84DK+uDgBIn3mlCMXBHK7LDnqAs9nl99hhqRnuRznwb4NgRAZXoTw1gxuT0+8HuYNVnpm5FJW+ePyYZVjz9ry9rk7ZO9URMBzdedrqg99M+5t5bppS26W91CCfHRA4FACIQdJykb74dS1XjuB8mwoOnxZU1WJA+BqJyO6UpY1D98m/c1CQ0TH/QmhpQ/Werua9L9mgoODkiv7dRFMyedtKaiEMoN+gT5mkOFmdsNlU3vPw1kaZujzJsLV12hGw5H3VCT/wpbNdEIRJjTswYTgiBjrN5U+piF4DMNYSy4cThDK8JT5BOw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=purple.us 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=qHBmTxc82ZLiHi/+jviCek+oUm3Clx8EuJVTYkstZVY=; b=EH48OXhkdj747qOFVtvW4Hrx8ULjTyXMU8YuqpMrzKdeIPTxUeTIoB0Aqu4c780dtrNRYa7FurJTbSUnGcaWhiDaX3IAgTZOvxvcgwyJB+B0aY0nbqDTMYug/dX5mswQqQ0sr+kQsEEOwe8mNuidCDWEjXmLO/h73gt7MLVUemA= Received: from MN2PR04CA0025.namprd04.prod.outlook.com (2603:10b6:208:d4::38) by CH2PR12MB4293.namprd12.prod.outlook.com (2603:10b6:610:7e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.11; Mon, 21 Sep 2020 14:47:46 +0000 Received: from BL2NAM02FT057.eop-nam02.prod.protection.outlook.com (2603:10b6:208:d4:cafe::3a) by MN2PR04CA0025.outlook.office365.com (2603:10b6:208:d4::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14 via Frontend Transport; Mon, 21 Sep 2020 14:47:46 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; purple.us; dkim=none (message not signed) header.d=none;purple.us; 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 BL2NAM02FT057.mail.protection.outlook.com (10.152.77.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15 via Frontend Transport; Mon, 21 Sep 2020 14:47:45 +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 08LElgtC026250 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 21 Sep 2020 10:47:43 -0400 To: James Hamlin References: <1600679072074.473@purple.us> From: Paul Kyzivat Cc: "rum@ietf.org" Message-ID: <13bd7883-da42-9c48-5cfe-8eaac47c8886@alum.mit.edu> Date: Mon, 21 Sep 2020 10:47:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <1600679072074.473@purple.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7b5bfc7c-ee0a-4dbb-84ff-08d85e3d4d74 X-MS-TrafficTypeDiagnostic: CH2PR12MB4293: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FBNIQFSqlZpwM0FvpM+GeYi4NqL0XcS5m4ek01m6KwbMwpWmEeCOsFaC6O4BMXI5nAMKkvbF4LmH3W0PgH/bdAkVfpWeqExeg9ojgAmg3RWuuoA8PD3ipjDwnHfQKHrJPV6lpb2od3ZTeXSgoBAH4nV2rvZrsc4Ydh46HLRNfr9RK28p6E3w+KTTN6TfHfAg/bhNFTaUbn8eMikoQjHxxPua25IDVZCU9HEVbM0QAHb6aalYikizwBHkbXUTgr13CNSkjUcLWXzGuA9cuHSXyzA95EgOpV2Q+gphfc2mKxvRbZ5CDu9rxduRAhf+KxvEyC1Xh3C5uD8/OXKGVTImo3699ydB847M39kE7Xq5LZmFRsjKpPGnPdizdJsIYp8lqIF94KTpoW/zk4OkP5vVay6u8W227tdgMKXoWKyVSwIKTJ62abm1gDLKOYvxKdD0ep31OVU/lMomCF2ciSAKQUngBRPlBjq7Ad4sHnLc5WY= X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(39860400002)(136003)(376002)(346002)(396003)(46966005)(53546011)(336012)(2616005)(186003)(8936002)(36906005)(786003)(8676002)(47076004)(70586007)(478600001)(82740400003)(86362001)(316002)(82310400003)(70206006)(31686004)(26005)(956004)(5660300002)(2906002)(75432002)(4326008)(83380400001)(6916009)(7596003)(356005)(31696002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2020 14:47:45.7819 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7b5bfc7c-ee0a-4dbb-84ff-08d85e3d4d74 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-AuthSource: BL2NAM02FT057.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4293 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 14:47:50 -0000 James, Since you are the one VRS Provider person who regularly contributes here, can I ask you to help a bit more? Back when we started this work with Henning several years ago a major concern of the providers was to find a mechanism to easily and cheaply restrict access to RUE implementations that have been tested/certified. The goal as I understand it was to avoid subjecting the provider systems to attacks. But to date we haven't identified a mechanism for doing this that actually works. At the moment there is nothing in the draft for that. I have been arguing that web servers don't limit access to certified web browsers and they manage to survive. But still I am willing to entertain including a mechanism if we could find one that is workable. Would you be willing to work on this with us? In particular, to start, identify the particular concerns and the level of effort that is/isn't acceptable to identify and reject uncertified clients. Thanks, Paul On 9/21/20 5:04 AM, James Hamlin wrote: > Brian > > > Thanks for the new draft. > > > I think the final sentence in section 5.2.5. "Emergency Calls" is out of > scope, as it tries to define the interface between the VRS provider and > the PSAP. From the rest of the text, the purpose of the data exchange > between RUE and VRS provider is already clear; the final sentence could > be dropped without detracting from the description of the RUM interface. > I propose dropping the text/: "Providers MUST implement Data Provider > and Service Information blocks as the call is forwarded to the PSAP."./ > > > Best Regards > > > James > > > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > > The information contained in this e-mail message is intended only for > the personal and confidential use of the recipient(s) named above. If > you have received this communication in error, please notify us > immediately by e-mail, and delete the original message. > > From nobody Wed Sep 23 23:59:09 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BE33A0770 for ; Wed, 23 Sep 2020 23:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 oeQSIclM6P-h for ; Wed, 23 Sep 2020 23:59:06 -0700 (PDT) Received: from outbound-ip1a.ess.barracuda.com (outbound-ip1a.ess.barracuda.com [209.222.82.168]) (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 2C88F3A0772 for ; Wed, 23 Sep 2020 23:59:04 -0700 (PDT) Received: from smtp.purple.us (smtp02.purple.us.91.17.208.in-addr.arpa [208.17.91.144]) by mx3.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Thu, 24 Sep 2020 06:59:01 +0000 Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 23 Sep 2020 23:59:00 -0700 Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Wed, 23 Sep 2020 23:59:00 -0700 From: James Hamlin To: Paul Kyzivat CC: "rum@ietf.org" Thread-Topic: [Rum] I-D Action: draft-ietf-rum-rue-03.txt Thread-Index: AQHWj/Gl4E/+9/1icEKqjKU/sGCygqlzocYAgAO+W9Y= Date: Thu, 24 Sep 2020 06:58:59 +0000 Message-ID: <1600930740003.80867@purple.us> References: <1600679072074.473@purple.us>, <13bd7883-da42-9c48-5cfe-8eaac47c8886@alum.mit.edu> In-Reply-To: <13bd7883-da42-9c48-5cfe-8eaac47c8886@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BESS-ID: 1600930741-893004-1313-65002-1 X-BESS-VER: 2019.1_20200923.1534 X-BESS-Apparent-Source-IP: 208.17.91.144 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.227108 [from cloudscan12-95.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 06:59:07 -0000 Hi Paul=0A= =0A= Agreed, the background to this is that VRS Providers wish to provide contro= lled, limited access to 3rd party applications so as to protect their servi= ces from bad actors and misbehaving Apps. And I don't think a solution had = been fully agreed.=0A= =0A= Best regards=0A= =0A= James=0A= =0A= =0A= James Hamlin=0A= Contractor=0A= Purple, a Division of ZP Better Together, LLC=0A= purplevrs.com=0A= The information contained in this e-mail message is intended only for the p= ersonal and confidential use of the recipient(s) named above. If you have r= eceived this communication in error, please notify us immediately by e-mail= , and delete the original message.=0A= =0A= ________________________________________=0A= From: Paul Kyzivat =0A= Sent: 21 September 2020 15:47=0A= To: James Hamlin=0A= Cc: rum@ietf.org=0A= Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt=0A= =0A= James,=0A= =0A= Since you are the one VRS Provider person who regularly contributes=0A= here, can I ask you to help a bit more?=0A= =0A= Back when we started this work with Henning several years ago a major=0A= concern of the providers was to find a mechanism to easily and cheaply=0A= restrict access to RUE implementations that have been tested/certified.=0A= The goal as I understand it was to avoid subjecting the provider systems=0A= to attacks. But to date we haven't identified a mechanism for doing this=0A= that actually works. At the moment there is nothing in the draft for that.= =0A= =0A= I have been arguing that web servers don't limit access to certified web=0A= browsers and they manage to survive. But still I am willing to entertain=0A= including a mechanism if we could find one that is workable.=0A= =0A= Would you be willing to work on this with us? In particular, to start,=0A= identify the particular concerns and the level of effort that is/isn't=0A= acceptable to identify and reject uncertified clients.=0A= =0A= Thanks,=0A= Paul=0A= =0A= On 9/21/20 5:04 AM, James Hamlin wrote:=0A= > Brian=0A= >=0A= >=0A= > Thanks for the new draft.=0A= >=0A= >=0A= > I think the final sentence in section 5.2.5. "Emergency Calls"=A0is out o= f=0A= > scope, as it tries to define the interface between the VRS provider and= =0A= > the PSAP. From the rest of the text, the purpose of the data exchange=0A= > between RUE and VRS provider is already clear; the final sentence could= =0A= > be dropped without detracting from the description of the RUM interface.= =0A= > I propose dropping the text/: "Providers MUST implement Data Provider=0A= > and Service Information blocks as the call is forwarded to the PSAP."./= =0A= >=0A= >=0A= > Best Regards=0A= >=0A= >=0A= > James=0A= >=0A= >=0A= > James Hamlin=0A= > Contractor=0A= > Purple, a Division of ZP Better Together, LLC=0A= > purplevrs.com=0A= >=0A= > The information contained in this e-mail message is intended only for=0A= > the personal and confidential use of the recipient(s) named above. If=0A= > you have received this communication in error, please notify us=0A= > immediately by e-mail, and delete the original message.=0A= >=0A= >=0A= =0A= From nobody Thu Sep 24 06:39:38 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3F03A0A6E for ; Thu, 24 Sep 2020 06:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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 cfSBoHn-6SNb for ; Thu, 24 Sep 2020 06:39:34 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 25F5A3A0C97 for ; Thu, 24 Sep 2020 06:39:34 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id d190so3344490iof.3 for ; Thu, 24 Sep 2020 06:39:34 -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=eeE69LumU5hYC232w2CNM8XB2z+F70OLSJ98gGlBvTs=; b=amJGCDege1UVxuqxehpjvm70YUsSF3KYU9pNXaNjM5FluVRY0IfA9vekzw+6mCP4tv W2a0PbuZrkcOw+a+Rji1wnhNQlYNqDuueOecO6+kWMCfF1tdM3FhUyFgLsHtGJfymspM O+Md8p9VnMiNAMDF97E3vq4varriGxSC4Op2r1pdNfNctZ3ubNelKZgKPA3/lhMDiB42 DLYxJhfKFYMKgZFl9NvqFGTBYEMMn6Dk31nKA6EKTBrwlQK6Ns7Om14qVkC4eKiw/fi6 LNdIG06idW7dwnv4/tIGXgXBrPYngpJJZD5zBF+zvcsPYE3leVTWa1hJHb4K5F8N5ZhR Douw== 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=eeE69LumU5hYC232w2CNM8XB2z+F70OLSJ98gGlBvTs=; b=cHrTY3JgaUX3EhVLSdm2UFvzBVx9wAMFgEWO/bGPA/gplivqBZT4rSesD0nO3+dOcC /HH+GQBP2fsY+8csMKR7on5nIgJzXVHlXNNk07ZjhpaPKN7FP+JCRoQVgKDsjiAnm2Qp 2oC/po4YKcI6/rWWCjPmZjaM5yVpHpf6c7ywEDVzVdvUmPqvwPw6H6/+BJCoQ1QCUgB+ uC+1zbOI+4Ld02jfhQRsOUa4WRXGeE9+ROwpB7kx1berGWiEe9ZRjQjdQIkdfyZDPcdT veS8t0uSnZ9V8NLU33ROtm6URShcHQZwBv3BUM+f4t69QaZaDzkDpOGvSz+qMHrCNvXa 4xcg== X-Gm-Message-State: AOAM531c/XEr7Mu7OcgsO7JxUZoBjzbh7EDD20E2ANaRSaAGF8CisAYN OkqZ906n8goN/hdvIUf64qZI2Q== X-Google-Smtp-Source: ABdhPJy2tBFgj3MnaofKi/0R/X5l4E9GL918te1IgtDA5L2rhQCHmbkWEqsYNZcdost2xEszZ9W3sw== X-Received: by 2002:a6b:8fc9:: with SMTP id r192mr3302476iod.24.1600954773234; Thu, 24 Sep 2020 06:39:33 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id p12sm1403764iom.47.2020.09.24.06.39.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2020 06:39:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Brian Rosen In-Reply-To: <1600930740003.80867@purple.us> Date: Thu, 24 Sep 2020 09:39:29 -0400 Cc: Paul Kyzivat , "rum@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5E0F41A3-A096-40C1-B055-3D33F76E7D84@brianrosen.net> References: <1600679072074.473@purple.us> <13bd7883-da42-9c48-5cfe-8eaac47c8886@alum.mit.edu> <1600930740003.80867@purple.us> To: James Hamlin X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 13:39:37 -0000 Are there any solution proposals? The solutions for this class of problem that I know about require a = closed environment, where there is some trust (here between the = environment creator and the providers), and there is some kind of = signature on the code. The environment refuses to execute code that is = not signed, and checks the signature digest against the code digest. We don=E2=80=99t have such an environment, so I am at a loss to suggest = any solution. > On Sep 24, 2020, at 2:58 AM, James Hamlin = wrote: >=20 > Hi Paul >=20 > Agreed, the background to this is that VRS Providers wish to provide = controlled, limited access to 3rd party applications so as to protect = their services from bad actors and misbehaving Apps. And I don't think a = solution had been fully agreed. >=20 > Best regards >=20 > James >=20 >=20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >=20 > ________________________________________ > From: Paul Kyzivat > Sent: 21 September 2020 15:47 > To: James Hamlin > Cc: rum@ietf.org > Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt >=20 > James, >=20 > Since you are the one VRS Provider person who regularly contributes > here, can I ask you to help a bit more? >=20 > Back when we started this work with Henning several years ago a major > concern of the providers was to find a mechanism to easily and cheaply > restrict access to RUE implementations that have been = tested/certified. > The goal as I understand it was to avoid subjecting the provider = systems > to attacks. But to date we haven't identified a mechanism for doing = this > that actually works. At the moment there is nothing in the draft for = that. >=20 > I have been arguing that web servers don't limit access to certified = web > browsers and they manage to survive. But still I am willing to = entertain > including a mechanism if we could find one that is workable. >=20 > Would you be willing to work on this with us? In particular, to start, > identify the particular concerns and the level of effort that is/isn't > acceptable to identify and reject uncertified clients. >=20 > Thanks, > Paul >=20 > On 9/21/20 5:04 AM, James Hamlin wrote: >> Brian >>=20 >>=20 >> Thanks for the new draft. >>=20 >>=20 >> I think the final sentence in section 5.2.5. "Emergency Calls" is out = of >> scope, as it tries to define the interface between the VRS provider = and >> the PSAP. =46rom the rest of the text, the purpose of the data = exchange >> between RUE and VRS provider is already clear; the final sentence = could >> be dropped without detracting from the description of the RUM = interface. >> I propose dropping the text/: "Providers MUST implement Data Provider >> and Service Information blocks as the call is forwarded to the = PSAP."./ >>=20 >>=20 >> Best Regards >>=20 >>=20 >> James >>=20 >>=20 >> James Hamlin >> Contractor >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com >>=20 >> The information contained in this e-mail message is intended only for >> the personal and confidential use of the recipient(s) named above. If >> you have received this communication in error, please notify us >> immediately by e-mail, and delete the original message. >>=20 >>=20 >=20 >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Thu Sep 24 07:55:40 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284AA3A0D75 for ; Thu, 24 Sep 2020 07:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 gXIS4hxPCsW7 for ; Thu, 24 Sep 2020 07:55:36 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2068.outbound.protection.outlook.com [40.107.236.68]) (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 B06613A0D7B for ; Thu, 24 Sep 2020 07:55:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fGSnPHOKcFvHrJdTUL/bfqBF++zkjHcwMhJ3AomMf/2RK3/wSVKHOAdOFDBfkMY8QKSIZ6HSvRl0L6bGeDVzoqKzWqr0dSCzGuqGwi8zyackGGVKZWqBPT1RGVMa96smzxtXsNKBb8ftwp1w5yShd8KJ67IWidDE0n1T33Gf0f1zZETL/RZyHOhFmqSW2M1/fnbYHpVxoik843a1vI15Ygag+alcnmtrtCk2tmZ2g1BZHtjmwISsZIVs/dkjSI4D+zV9zXtNvo7QpgKmRkbxupihbSrLbQruPwAySh5b9GgbDE3Bvi8uczKRV/l8igktNfW/Su04zpGRY6l8vueYvg== 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=yGn6nYtYUmwSD1LqC9hnzs6UkiXNtZvS1kw/kB2IBVg=; b=HAfIBm3ZUwVhYMW0Vvt76jJe9WHLZgN67ZjCKgwYwWlKHGmBA1D2clPDvZQ83VslYjnelklLjAPbPd05A8ShUgbMUjsWL94FaTE9FenE3nSbJtWr7kU4b5ZvgO80J5DKGROoIx9EBY58HKiEujcwZ/bBSdzupFDresKzJOm23F1JWrzd7kXccslE26b5H16v6BVN2rgD+sAp9sFGxnXOmvN4HQTRV3SjfTBtx9+pDp4cCeqE8gD8rdM/oZjQUjTMCgKs1VP/8e5LY/UK35waA8C4xyOC89NTZn/JHPdoPQ8FcyKbtuDL69Hses1nf49lSkErPRHxh2quUujP1ZmNww== 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=yGn6nYtYUmwSD1LqC9hnzs6UkiXNtZvS1kw/kB2IBVg=; b=EhbHwWkg6IZPdvJJyOYdVmZIgGvpS1gy4mvT6wQWgCvs/qnbQ9r30jKNhucce9JVLd2tPTx/arLMJ2GXGHfJ+3ZUTYAbWgLlFwKB/NEk1lH0hU9myQp9L+rTTId/KsdREDBjKp70AhtjTFOu1NF6WtKAbXYvssthg+L0XDemXeU= Received: from CY4PR03CA0008.namprd03.prod.outlook.com (2603:10b6:903:33::18) by BN6PR12MB1875.namprd12.prod.outlook.com (2603:10b6:404:103::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22; Thu, 24 Sep 2020 14:55:27 +0000 Received: from CY1NAM02FT064.eop-nam02.prod.protection.outlook.com (2603:10b6:903:33:cafe::19) by CY4PR03CA0008.outlook.office365.com (2603:10b6:903:33::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22 via Frontend Transport; Thu, 24 Sep 2020 14:55:27 +0000 X-MS-Exchange-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 CY1NAM02FT064.mail.protection.outlook.com (10.152.74.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Thu, 24 Sep 2020 14:55:25 +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 08OEtNoH007147 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 24 Sep 2020 10:55:24 -0400 To: rum@ietf.org References: <1600679072074.473@purple.us> <13bd7883-da42-9c48-5cfe-8eaac47c8886@alum.mit.edu> <1600930740003.80867@purple.us> <5E0F41A3-A096-40C1-B055-3D33F76E7D84@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Thu, 24 Sep 2020 10:55:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <5E0F41A3-A096-40C1-B055-3D33F76E7D84@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 53bb5542-a73e-412e-5ae6-08d86099dee9 X-MS-TrafficTypeDiagnostic: BN6PR12MB1875: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nRm3qEvupqgWNhLBChuFR8p0lI+mWhbQh7LG7cylfDIqNK8HhpozSHgYSu/XmMl8sr/kSQ9LZ3kRL0bwoZDtnYW3ryLbyDNORvLEi8dAuwASS/2jAG5yh2hxGzx1OGNNXLiB6mmc8tQAbmA+k7w9/9nBTGFx+L7VzZlUz52rrWjM1AzIcvrpwFfpFlGYRNQdmwQy9LDt/N9ijTDguT72AAwvCNblibSLwKkcVLzbsawWolV2SkKLkLTdiCsB8vWHw4Qyr7Doa4lUaFVN+xmTJE36lJ1JrGoPkCBjP+fO4RUExiFQVr4ehQQRaeNUjs3c2Bz3WGKFCYpwwfONyw6cjEmG0v2pKxtrXcAfDDqg2AEBKJpLmFxv9rK9x5+6wNgyHEdb3/sUgySAUUEMKwgS8yqOQcrz0hT7AdVDnyGdW9fTDUnDJSajgHEVdSbndkKwOLLSsOVvjmgn7qOgEBpYJjvO5aKMPHp6s0KeZ3B7zaSjncUthnMJH1IxHAHmwJG+HY5JOfJX9Ryu5xtGctBc3icHaC5whr2tFrBZaiKjSjxa7OUjgBdErrvVEhJE6Iwy X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(136003)(376002)(346002)(39860400002)(396003)(46966005)(70586007)(2906002)(966005)(186003)(53546011)(26005)(75432002)(356005)(82740400003)(31686004)(5660300002)(336012)(7596003)(86362001)(786003)(316002)(36906005)(2616005)(956004)(478600001)(83380400001)(6916009)(82310400003)(70206006)(47076004)(8676002)(31696002)(8936002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2020 14:55:25.6224 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 53bb5542-a73e-412e-5ae6-08d86099dee9 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-AuthSource: CY1NAM02FT064.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1875 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 14:55:38 -0000 On 9/24/20 9:39 AM, Brian Rosen wrote: > Are there any solution proposals? > > The solutions for this class of problem that I know about require a closed environment, where there is some trust (here between the environment creator and the providers), and there is some kind of signature on the code. The environment refuses to execute code that is not signed, and checks the signature digest against the code digest. > > We don’t have such an environment, so I am at a loss to suggest any solution. +1. That has been the problem from the beginning. So James, do you have an idea for how to solve this, or know someone who does? Thanks, Paul >> On Sep 24, 2020, at 2:58 AM, James Hamlin wrote: >> >> Hi Paul >> >> Agreed, the background to this is that VRS Providers wish to provide controlled, limited access to 3rd party applications so as to protect their services from bad actors and misbehaving Apps. And I don't think a solution had been fully agreed. >> >> Best regards >> >> James >> >> >> James Hamlin >> Contractor >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com >> The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. >> >> ________________________________________ >> From: Paul Kyzivat >> Sent: 21 September 2020 15:47 >> To: James Hamlin >> Cc: rum@ietf.org >> Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt >> >> James, >> >> Since you are the one VRS Provider person who regularly contributes >> here, can I ask you to help a bit more? >> >> Back when we started this work with Henning several years ago a major >> concern of the providers was to find a mechanism to easily and cheaply >> restrict access to RUE implementations that have been tested/certified. >> The goal as I understand it was to avoid subjecting the provider systems >> to attacks. But to date we haven't identified a mechanism for doing this >> that actually works. At the moment there is nothing in the draft for that. >> >> I have been arguing that web servers don't limit access to certified web >> browsers and they manage to survive. But still I am willing to entertain >> including a mechanism if we could find one that is workable. >> >> Would you be willing to work on this with us? In particular, to start, >> identify the particular concerns and the level of effort that is/isn't >> acceptable to identify and reject uncertified clients. >> >> Thanks, >> Paul >> >> On 9/21/20 5:04 AM, James Hamlin wrote: >>> Brian >>> >>> >>> Thanks for the new draft. >>> >>> >>> I think the final sentence in section 5.2.5. "Emergency Calls" is out of >>> scope, as it tries to define the interface between the VRS provider and >>> the PSAP. From the rest of the text, the purpose of the data exchange >>> between RUE and VRS provider is already clear; the final sentence could >>> be dropped without detracting from the description of the RUM interface. >>> I propose dropping the text/: "Providers MUST implement Data Provider >>> and Service Information blocks as the call is forwarded to the PSAP."./ >>> >>> >>> Best Regards >>> >>> >>> James >>> >>> >>> James Hamlin >>> Contractor >>> Purple, a Division of ZP Better Together, LLC >>> purplevrs.com >>> >>> The information contained in this e-mail message is intended only for >>> the personal and confidential use of the recipient(s) named above. If >>> you have received this communication in error, please notify us >>> immediately by e-mail, and delete the original message. >>> >>> >> >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum > From nobody Thu Sep 24 08:04:09 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B453A0E52 for ; Thu, 24 Sep 2020 08:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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=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 SZ6COumybYny for ; Thu, 24 Sep 2020 08:04:06 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2043.outbound.protection.outlook.com [40.107.94.43]) (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 ABCF33A0E54 for ; Thu, 24 Sep 2020 08:03:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OtsdjXd2H+F4JzNx567yDu9bHcxnyv6A8uha2+8LLgOT6jn6bxwKxF0Gg2FNUmF0NwOl+5AG61U4DQZbKV+Mr2fneHfhQ36yHB96QqXhKDZkPMQgm2AiZMRCYuOX26sPFmacyh9pZhLP+0tcjadi/rgNyo2YyD1ei52uyV5IHzetrH1SDz7pUDmIp/ReXrbnUgMk8wfPndmZBBLSbpZnUY8ej83JQrRBNx+1YDcwTf14fSr0XUrM+bPXPMdL4NHE8i8bsVQohkI/QPN7u1fsmA4XyFAynwNnixpZPJPbw7SzuI5iBtbq0Dgx4bsK876gFYZ/UnpCG5VsQD9zMTtacg== 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=XFqfygsrM204y3QinsbXtaJvWvOBoSn4kmglc9DVrcc=; b=TodYG9zAN8WjNN23NepVb9ZVlhUjeCNIB/qybSWqHnB8kCbH/0eRwmR294vMdkYu/8qNaGYmVSHpp8N/DnteDmKUWr5aoobOs4SBje0khvBtGvV49iNO6RmEfyg88JSGD6TTlzX6dI6Gmc8YWszEqh0OY8gmtK5cU8Nb5sPxHRWjaGQirPzX0KWko1ZVv4X1vN5lJ1eCHM0Nkkjjwgw7mgr3Gytnihc40ihUaFEYUzcGh+klDe3XcNqEnBbcka920lfZ2dIjTV1QWpAu3e7YeFscIdB6TGy1fr/aMjnmSAEcN2/vWhsH8YNYnxOa54u3siCOPogNzYJjo5CVQA1fLQ== 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=XFqfygsrM204y3QinsbXtaJvWvOBoSn4kmglc9DVrcc=; b=FRdjRo5RSk1MyWn6DYblCTQa7Q9CRk/NR5WAnIBH/R1vkG0JHBi15e4wqTCYDrEu6qvDgIWv6GFvVD2+5fa5psXyJreeZQxYwnK7cujDq1TVoiyydDMosni8aJ5LiLGb0JbhKGjdo/RLln+3uyZB8Spth6XFDXUWgBd9PoUHAiE= Received: from BL0PR0102CA0008.prod.exchangelabs.com (2603:10b6:207:18::21) by MN2PR12MB4520.namprd12.prod.outlook.com (2603:10b6:208:26f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Thu, 24 Sep 2020 15:03:46 +0000 Received: from BL2NAM02FT004.eop-nam02.prod.protection.outlook.com (2603:10b6:207:18:cafe::90) by BL0PR0102CA0008.outlook.office365.com (2603:10b6:207:18::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20 via Frontend Transport; Thu, 24 Sep 2020 15:03:46 +0000 X-MS-Exchange-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 BL2NAM02FT004.mail.protection.outlook.com (10.152.76.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Thu, 24 Sep 2020 15:03:45 +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 08OF3i9Y007945 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 24 Sep 2020 11:03:45 -0400 To: rum@ietf.org References: <1600679072074.473@purple.us> <13bd7883-da42-9c48-5cfe-8eaac47c8886@alum.mit.edu> <1600930740003.80867@purple.us> <5E0F41A3-A096-40C1-B055-3D33F76E7D84@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Thu, 24 Sep 2020 11:03:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7e40be61-75a2-4e4f-d2b6-08d8609b08d5 X-MS-TrafficTypeDiagnostic: MN2PR12MB4520: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Q6kGAxR3uQddq803ggn3ghR4q5rVXsxBE+NhJguxm2deSu5DvWyxPpHQ8RQQOJJh2Wji234HzO3U8gKamXZROidLOHH3JX2s+iNgKqbHPMUYcYw+4Sg0H5DT+00SY0ozVJ6e8ntFxSB0rMzKFnCnuQ8De1fQaM4yQwu2jI4DShUm44YDYzVEHzKTr25Elus3fUEZ3BoRANvcHgvAnY92qfC88GmCjP/F/EPS15FZAeEp+7ClA8AAg5+b7LXsdIrnSfJncjV/4cZ7xG5qVSpSPyp9IBJrkHc7/OBqf7XrEz0p2J7GBtIhkYVo11YAODC76teUcgxmczjHV19wIZlR3eegFPnFpH6WFrv76FQcV/nTid792xo5O623UhwqBofx7686BQFWamkWTLQzmDz9mxNWsMI7R71rYThHCqvZpUk= X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(376002)(136003)(346002)(396003)(39860400002)(46966005)(70206006)(70586007)(186003)(2906002)(53546011)(26005)(75432002)(31686004)(356005)(5660300002)(82740400003)(336012)(7596003)(86362001)(786003)(316002)(36906005)(4744005)(6916009)(478600001)(956004)(83380400001)(8676002)(82310400003)(47076004)(2616005)(31696002)(8936002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2020 15:03:45.6094 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7e40be61-75a2-4e4f-d2b6-08d8609b08d5 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-AuthSource: BL2NAM02FT004.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4520 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 15:04:08 -0000 James, On 9/24/20 10:55 AM, Paul Kyzivat wrote: > On 9/24/20 9:39 AM, Brian Rosen wrote: >> Are there any solution proposals? >> >> The solutions for this class of problem that I know about require a >> closed environment, where there is some trust (here between the >> environment creator and the providers), and there is some kind of >> signature on the code.  The environment refuses to execute code that >> is not signed, and checks the signature digest against the code digest. >> >> We don’t have such an environment, so I am at a loss to suggest any >> solution. > > +1. That has been the problem from the beginning. > > So James, do you have an idea for how to solve this, or know someone who > does? Some further questions on this: With your existing proprietary solutions do you have a way to prevent someone from emulating your client device, and possibly hacking it is a malicious way? Are you depending on security by obscurity? Thanks, Paul From nobody Sat Sep 26 10:21:14 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559063A0C70 for ; Sat, 26 Sep 2020 10:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_MSPIKE_H2=-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=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 r32as6sT2jmX for ; Sat, 26 Sep 2020 10:21:06 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2041.outbound.protection.outlook.com [40.107.93.41]) (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 4A1863A0C16 for ; Sat, 26 Sep 2020 10:21:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c/9Lj6eDg+Lh7HrOWGHhbOwYgEwT8xCDuPrBZemnLyVMDlygYBvT7tG/2yAsrFi1Bi6Qq/p0+v0Cjqrve5rXB6vBybSGZ+wfAACzLF6cholfPD4Wo7H6UrxN18rwKPcMfC56YQYzUJ1xCLUC5h2xMW6D8rrUhuDwM1wKf10J/tLylE5oXHDcta02TCpqOwOtEGR4BQBI2tlZOhlxC0RhpcRtKfpirx7dAhU8/xiYdra3NIzUa6+mWP3SyX/M6Ake6ypl5xXiKd7ER5cHe4SUuu7vCwfMCN5D6oWq0ODP/OFhBGGodsXEX2RxppMyVvZNwX1R6gQMGRyXL17pUrkrug== 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=PotLnNspvKqNUa8/YBZ4bLkco+QkC5Oxk5DWQ5jv42Y=; b=JYT+O2BfsR7SxDCwYr+kn8b3aTGqsju3Kwy5ElO3wcEP9vm1G1cNkaZBS5QITGam7MQHdT5hDb0gmknk4vpalJqkty+VOAM7k2mMNsYFMut9Zw30Ae/d1RZIR3q0LqLBOWuJE3/BapMEVJpnLSMnRhKbKnf7LxI8OMALmGLCL/IhN/BVKWYusKPpziRfUZprG6bSp3ju83cab1VpYkEywvuZmf35ZhuXEdP8gHRHxyMJ/S3IItV/Hp0LsVrEZNPJD59cYjIfERFhmE3jOPHVoV/8JuXXnf0UcKpAXQPIt7p19HvnfFH+g50aRHH/1y1d3A92lgs8YkskKBWR5hWaRg== 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=PotLnNspvKqNUa8/YBZ4bLkco+QkC5Oxk5DWQ5jv42Y=; b=F68loMsIfl2D5xnB8g24KE/r5iO+/yvv2pQCdgDG2maBguroEGdfs4/HniwhjFMgDfF/Yt5w5Mktpzbxv90GibPZI1JKuJ9tihCBbMQpeyfJnHhCsxms/b4nywN23Cb746cQjMT3Wa+kpoikiMgrew1lGJurj2s2nxsIOVI7Rto= Received: from SN6PR2101CA0030.namprd21.prod.outlook.com (2603:10b6:805:106::40) by DM5PR12MB2373.namprd12.prod.outlook.com (2603:10b6:4:b1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22; Sat, 26 Sep 2020 17:21:00 +0000 Received: from SN1NAM02FT018.eop-nam02.prod.protection.outlook.com (2603:10b6:805:106:cafe::2b) by SN6PR2101CA0030.outlook.office365.com (2603:10b6:805:106::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.7 via Frontend Transport; Sat, 26 Sep 2020 17:21:00 +0000 X-MS-Exchange-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 SN1NAM02FT018.mail.protection.outlook.com (10.152.72.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Sat, 26 Sep 2020 17:21:00 +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 08QHKvLi019895 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 26 Sep 2020 13:20:58 -0400 To: rum@ietf.org References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Sat, 26 Sep 2020 13:20:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 74b0c072-a85b-4eab-cbe8-08d8624089cd X-MS-TrafficTypeDiagnostic: DM5PR12MB2373: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tryrf4peaeNG23ocCTV6eB90Jif50R71m/wRIxbgznBKJ+mZVr5U0LkPE5R3Zz7iCklZP0wetGD8eFBxJxUYsGfdb4ruY+afa8BT+mjR5BmdIfzTWZJCK4i2oidDYGqoSHKId7I7L7xh/SbQbhPa5IOgPMxKh3pgcTqf4R/hKoicXa1tHfpUX6rbbQyWcM3M9eV6ABDMM02OrlQdRqaGBaUSeO81aaBM30M4VV/e7gLlkHIQoqyf5/d8pkxsr2NN/XgPztLVd8twNNKsMypa8wQdrexhQKklSg/Bs75AXp6ze+mgToRjuerAIyvE5BYT4g5eQp+Ik++oiKM0xLoSrkO2j6COlVMaTLW2ZhW6BIFIRtmoN2HQC+YZ/atVDxdel5IeCZ9CqYz63TXw6+s3+SJKtg6g5oKxZY47pB0otakwiVX7igwg7eaH1KdJfr1aiTUEk3b6K5ltzjPtYoN6hL7q0nl87EQpmW/NyUJOMHg= X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(396003)(136003)(39860400002)(376002)(346002)(46966005)(336012)(8676002)(5660300002)(6916009)(70206006)(82310400003)(31686004)(70586007)(8936002)(15650500001)(82740400003)(3480700007)(75432002)(47076004)(186003)(478600001)(83380400001)(53546011)(86362001)(26005)(7116003)(956004)(356005)(2616005)(2906002)(31696002)(316002)(36906005)(7596003)(786003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2020 17:21:00.0480 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 74b0c072-a85b-4eab-cbe8-08d8624089cd 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-AuthSource: SN1NAM02FT018.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB2373 Archived-At: Subject: [Rum] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 17:21:13 -0000 On 9/18/20 11:52 AM, Paul Kyzivat wrote: > Brian, > > Thanks for reviving this and resolving some of the open issues. I hope > we can soon identify and resolve remaining issues. > > I do think the password issue is going to be tricky to sort out. We > should get a discussion going on it. I'm thinking that we may need a > whole section discussing the security model. Some brainstorming on this - half baked thoughts: 1) In many cases a RUM device is an always-on device. It must possess credentials that allow it to remain authenticated to a registrar even when no user is present. (Not different from many sip devices, but worth calling out.) 2) It is the user (owner?) of the RUM device that must first authenticate to a provider. This authentication then needs to be delegated to the RUM device to satisfy the requirements of (1). 3) There will be a need for the *user* to periodically reauthenticate. This may sometimes be time based, but may also be required when the device or server have been compromised, etc. This can be a problem if it occurs when the user isn't immediately available. In most cases the RUM device should still be allowed to remain registered for receipt of incoming calls until such time as a user is present to participate in reauthentication. 4) Credentials held by the RUM device in support of (1) and (2) must be secured. It should be impossible for an attacker to extract these credentials and reuse them in another device. (This is hard. We may not be able to fully achieve it in the spec. But we need to consider it.) 5) The security system for RUM devices must be compatible with RUM devices that support simultaneous registration to multiple VRS providers. However there is no requirement for a RUM device to support this feature. (It isn't clear to me if this requirement imposes any particular burden on the spec. I only bring it up to cover all the bases.) Note: In the above I keep using the term "RUM device". I did this because I *think* RUE is a more generic term that encompasses both RUM compliant devices and non-compliant ones like existing proprietary VRS provider supplied user devices. I think it is too late to restrict the definition of RUE to being compliant to RUM, since it is used in the more generic sense in the provider profile. I'm content to keep using "RUM device" but I'm open to other suggestions. In any case, whatever we decide should go into the definitions. From nobody Sat Sep 26 17:58:29 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AC73A0E15 for ; Sat, 26 Sep 2020 17:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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 vCv_5hfNfbkU for ; Sat, 26 Sep 2020 17:58:26 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 EF4EA3A0D65 for ; Sat, 26 Sep 2020 17:58:25 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id z25so7456330iol.10 for ; Sat, 26 Sep 2020 17:58:25 -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=0E7gc1TZtFlos1SK+vS0YHwEMCu1RnPTppLiKGABuy4=; b=VXFqwr6bVclMJQ0lx5LV9ljIdsCfvVJ6YXf0CXqnOYYjXILCE65YAlNQWUT71jHPLS DMCcQdXR3BdZ3SKvFUgg0ZkMu0g2JDDe00JeM2iRLU6qsCS42Exd0Z5TcDCk2JHqxjrH zXmt5ZUbqW5Dgi7NXdoIdXLrub+u7TULslDBx59yUm3TK3nPwE7cl2mNNrFqClAmhfIg 09LZnutDtGRi/hmGFJPzBpJsl5YbMLhJdUzeDyh7jOgn3u0hta4Mm8OaF387DOdFEMWU 0R/WNeKv5mrpwjHzxjqhEK6FMRdH5pvgw0AvKyeDjSj5YWd9+zwnDYQ5k7TLNHHAiJTo djIQ== 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=0E7gc1TZtFlos1SK+vS0YHwEMCu1RnPTppLiKGABuy4=; b=ZtFvwuMIswVMhm704t/BIbvlieuP8OlrioN+EwlHe0PHSlb31nSOAGB3mS2kvCL36Z qluN1SHpVlS63mM9wQzhFy24bVVuN7jLbaiyk2NCF9SeSNDSHTvyoP1ed9MPF+t4AZoy Vzl8z0yeC6rmuSa0QgYZkjw+w/GL42LMmQpa1GJOx4UQ/0a7jxLDi/bqSKa3nTqoUkr4 ZC5hAfCZkJXd/sQEqTv8O6we28tHzEiJ7JsT2cTTJ9k1s7Je18RXZhnWMxbAeg6/11MS obBUiZ7snZTKxuLhSk4W0klzAsAJSI94QxHwnxA8u3wKgzC5+PEXe4vnWoLM5xIGussI qn7w== X-Gm-Message-State: AOAM532NJog9J2XyvgKUKHFuHschN+pI1CEWjqIW4aFAPhq15Q0CF8cu 5BujHcaM8SB2gVil9oM/i6JIsQ== X-Google-Smtp-Source: ABdhPJx+EyP359uqcryTZYFtkki5Al3DEQv2SQfw/2ZcDnEtdxh8u/n15xb2W27s80aXRmFKZke6qw== X-Received: by 2002:a05:6638:8d:: with SMTP id v13mr4249935jao.44.1601168305004; Sat, 26 Sep 2020 17:58:25 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id a6sm1620235ilq.29.2020.09.26.17.58.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Sep 2020 17:58:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Brian Rosen In-Reply-To: Date: Sat, 26 Sep 2020 20:58:18 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <303CFB8D-1323-4237-8D84-91BF6201B6F5@brianrosen.net> References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 00:58:28 -0000 I think we do want the spec to support multiple providers on one = device/user. I think that=E2=80=99s the point of having the file. If = it wasn=E2=80=99t them the user could just use the password for the = single provider directly and not need any other mechanism. ISTM that if the user has a password (and possibly a second factor like = a USB security device), then it can securely unlock a local resource = that contains the credentials. They can be stored encrypted, where the = decrypt requires the passwords at least initially. The simplest model is perhaps too simple: a local encrypted file = containing sign-on credentials that is decrypted with the user entering = a password. That is one password per user regardless of how many = providers they use. > On Sep 26, 2020, at 1:20 PM, Paul Kyzivat = wrote: >=20 > On 9/18/20 11:52 AM, Paul Kyzivat wrote: >> Brian, >> Thanks for reviving this and resolving some of the open issues. I = hope we can soon identify and resolve remaining issues. >> I do think the password issue is going to be tricky to sort out. We = should get a discussion going on it. I'm thinking that we may need a = whole section discussing the security model. >=20 > Some brainstorming on this - half baked thoughts: >=20 > 1) In many cases a RUM device is an always-on device. It must possess = credentials that allow it to remain authenticated to a registrar even = when no user is present. (Not different from many sip devices, but worth = calling out.) >=20 > 2) It is the user (owner?) of the RUM device that must first = authenticate to a provider. This authentication then needs to be = delegated to the RUM device to satisfy the requirements of (1). >=20 > 3) There will be a need for the *user* to periodically reauthenticate. = This may sometimes be time based, but may also be required when the = device or server have been compromised, etc. This can be a problem if it = occurs when the user isn't immediately available. In most cases the RUM = device should still be allowed to remain registered for receipt of = incoming calls until such time as a user is present to participate in = reauthentication. >=20 > 4) Credentials held by the RUM device in support of (1) and (2) must = be secured. It should be impossible for an attacker to extract these = credentials and reuse them in another device. (This is hard. We may not = be able to fully achieve it in the spec. But we need to consider it.) >=20 > 5) The security system for RUM devices must be compatible with RUM = devices that support simultaneous registration to multiple VRS = providers. However there is no requirement for a RUM device to support = this feature. (It isn't clear to me if this requirement imposes any = particular burden on the spec. I only bring it up to cover all the = bases.) >=20 > Note: >=20 > In the above I keep using the term "RUM device". I did this because I = *think* RUE is a more generic term that encompasses both RUM compliant = devices and non-compliant ones like existing proprietary VRS provider = supplied user devices. >=20 > I think it is too late to restrict the definition of RUE to being = compliant to RUM, since it is used in the more generic sense in the = provider profile. I'm content to keep using "RUM device" but I'm open to = other suggestions. In any case, whatever we decide should go into the = definitions. >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Sat Sep 26 21:36:08 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EAF3A0ED3 for ; Sat, 26 Sep 2020 21:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, 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 WyBmSyi0Y5jr for ; Sat, 26 Sep 2020 21:36:04 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2076.outbound.protection.outlook.com [40.107.92.76]) (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 4976D3A0ED1 for ; Sat, 26 Sep 2020 21:36:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KpLYWDR87CQgMRjCqXnBWhBVndTCu//yYHMqzdAtW93yQeqGWxi1rmUqeV8Y+4FrqaQYs8pmig62K1ebPHhzpz9cvDQ8KXq9wAdwcn+D5/MUX2mkkOHyaMrbNV86Xs/64kxAbkVBau0ul3JIDoFHuDl2/j9PSDkP3GatG08WF4S82QHlzISM/Xqo3SNhdHbxZk9fKyXbA36LJ/iBKQQ/iyBEW5AsL011NkBY8uQXY840xhgm1tZBtKcY7RoDPh/kUMWQRJQq3cqMtRBHQyJIYx0NYTRDRr5lms9gSm4iZSEX9EQNwNi897W0uPvvJMNqTK2USN/iYFfTFKRStuYwdA== 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=KsRZwcnXuBCAgfi4onfD59QtHDOR0JUo0Wxqt16hm/g=; b=KonvX1V5FusHZ/fGl+qhUfDL36PoSRLV62uvVad1iWPxnOmXc+DiQbBy9zUxAP4vsxsLgR/zvtmfzILBOVNlsRZGHqiK1JRPtieri9loQVmmxXkJ/GJr1pzdidFpKyLOlM7Yx+hOpKOqBQQlOj7icCzrFAoDoaaqoZgYRKBkBu/NWC26qz6eXXGsJntrnFPJxhSxRbrca+3gnBBnjQW5oJsNL5/BZ9rwJgPjsn67bjUzqpfaejYhW3+H4XF7QEg4+g0OT7MhICSzTpKrTfZxezE95DALU56fME3SHG0mju0KLsLHEP6Q3v76Gqf5QhJx9fy0ReeqxfjYqieaP0+3Ww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=brianrosen.net 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=KsRZwcnXuBCAgfi4onfD59QtHDOR0JUo0Wxqt16hm/g=; b=UPP54mqxodNUNkZkl6vZ5uNw83wqNwBMXTMUGCM/0GjWs94yHJJ8d+QghtR9I67p0ULqigTz+7XWAyKvBE/tuzRyn/+c2ejktASdmHLsOIbTR4307p8L47xALkj4Bn3xlht5oTuG67WfWVuZXUtrWLaiwA0pe+8bF532Pm0NgQs= Received: from CY4PR13CA0088.namprd13.prod.outlook.com (2603:10b6:903:152::26) by MN2PR12MB4504.namprd12.prod.outlook.com (2603:10b6:208:24f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Sun, 27 Sep 2020 04:35:59 +0000 Received: from CY1NAM02FT061.eop-nam02.prod.protection.outlook.com (2603:10b6:903:152:cafe::e6) by CY4PR13CA0088.outlook.office365.com (2603:10b6:903:152::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.13 via Frontend Transport; Sun, 27 Sep 2020 04:35:58 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; 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 CY1NAM02FT061.mail.protection.outlook.com (10.152.75.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Sun, 27 Sep 2020 04:35:57 +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 08R4ZsTw031278 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 27 Sep 2020 00:35:55 -0400 To: Brian Rosen Cc: rum@ietf.org References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <303CFB8D-1323-4237-8D84-91BF6201B6F5@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Sun, 27 Sep 2020 00:35:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <303CFB8D-1323-4237-8D84-91BF6201B6F5@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cb1d0ff7-16a9-4928-d623-08d8629ed45a X-MS-TrafficTypeDiagnostic: MN2PR12MB4504: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: c2wxAHGNUnIdWAWIqx2PWusXr4GrR11T4OwV4y0wfat/izoR2zdT52rMF/VZtk7x7foplVmLlCSLNx86B8AGDxD8zVV19wlHO5o2PX18cYNqtFjm4hDAMRAJhTqZbqKB8kXSufQdWpEWfV1eORJ+RL8Lynss3ABwEq2UNscQcr3z2WxsIvJNTcKi9Lm0lFRM/70AIDiWDyXH+6Gje8+VkZc0u8YyC0RIbM8Irov7ENj5NZ5Elc5m7gDfR1K62MgHj/7ue6ITG3YfYYSgEW1LhYEyfvEWVYU2+ABl0mBu5fNUziykD5wuXxbYOeF5hvA1YyzoEsNMJll+93V8uMG4YsBUN+fpa/5sOXoYQFHftgfiBV1Rss/u8SxPqo59y+KT7wOc5u2WUoWiPU5wye4bwblZ0kSDWOZLLL7ekXDybXD9OpZrLDTOT9ilk8qxGTtyJRTppGIeEXE12jExhq6NgqiAMMO7AShDP0yXHLqdTiVf7/3i6ml+aZg4lXgcvipNfGItKhPo/tVydgzQFaMG0ONcj6+IqOL+3FK/EKs58ZBcstkLKfzJDoFepT49Uo/L X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(376002)(136003)(346002)(396003)(39860400002)(46966005)(2616005)(26005)(5660300002)(186003)(31696002)(36906005)(70206006)(53546011)(82310400003)(8936002)(70586007)(966005)(8676002)(786003)(82740400003)(2906002)(47076004)(7596003)(336012)(956004)(83380400001)(15650500001)(4326008)(478600001)(6916009)(356005)(75432002)(316002)(86362001)(31686004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2020 04:35:57.7174 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cb1d0ff7-16a9-4928-d623-08d8629ed45a 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-AuthSource: CY1NAM02FT061.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4504 Archived-At: Subject: Re: [Rum] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 04:36:08 -0000 On 9/26/20 8:58 PM, Brian Rosen wrote: > I think we do want the spec to support multiple providers on one device/user. I think that’s the point of having the file. If it wasn’t them the user could just use the password for the single provider directly and not need any other mechanism. > > ISTM that if the user has a password (and possibly a second factor like a USB security device), then it can securely unlock a local resource that contains the credentials. They can be stored encrypted, where the decrypt requires the passwords at least initially. > > The simplest model is perhaps too simple: a local encrypted file containing sign-on credentials that is decrypted with the user entering a password. That is one password per user regardless of how many providers they use. Yes, I think it is too simple. The RUE needs access to those sign-on credentials in situations where the user isn't present. For instance, suppose it is restarted due to power failure. Then it must reregister ASAP in order to be available to receive incoming calls. There are lots of other cases as well. Thanks, Paul >> On Sep 26, 2020, at 1:20 PM, Paul Kyzivat wrote: >> >> On 9/18/20 11:52 AM, Paul Kyzivat wrote: >>> Brian, >>> Thanks for reviving this and resolving some of the open issues. I hope we can soon identify and resolve remaining issues. >>> I do think the password issue is going to be tricky to sort out. We should get a discussion going on it. I'm thinking that we may need a whole section discussing the security model. >> >> Some brainstorming on this - half baked thoughts: >> >> 1) In many cases a RUM device is an always-on device. It must possess credentials that allow it to remain authenticated to a registrar even when no user is present. (Not different from many sip devices, but worth calling out.) >> >> 2) It is the user (owner?) of the RUM device that must first authenticate to a provider. This authentication then needs to be delegated to the RUM device to satisfy the requirements of (1). >> >> 3) There will be a need for the *user* to periodically reauthenticate. This may sometimes be time based, but may also be required when the device or server have been compromised, etc. This can be a problem if it occurs when the user isn't immediately available. In most cases the RUM device should still be allowed to remain registered for receipt of incoming calls until such time as a user is present to participate in reauthentication. >> >> 4) Credentials held by the RUM device in support of (1) and (2) must be secured. It should be impossible for an attacker to extract these credentials and reuse them in another device. (This is hard. We may not be able to fully achieve it in the spec. But we need to consider it.) >> >> 5) The security system for RUM devices must be compatible with RUM devices that support simultaneous registration to multiple VRS providers. However there is no requirement for a RUM device to support this feature. (It isn't clear to me if this requirement imposes any particular burden on the spec. I only bring it up to cover all the bases.) >> >> Note: >> >> In the above I keep using the term "RUM device". I did this because I *think* RUE is a more generic term that encompasses both RUM compliant devices and non-compliant ones like existing proprietary VRS provider supplied user devices. >> >> I think it is too late to restrict the definition of RUE to being compliant to RUM, since it is used in the more generic sense in the provider profile. I'm content to keep using "RUM device" but I'm open to other suggestions. In any case, whatever we decide should go into the definitions. >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum > From nobody Mon Sep 28 12:33:08 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4023A0962 for ; Mon, 28 Sep 2020 12:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-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=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 8z5Rip4bOD2X for ; Mon, 28 Sep 2020 12:33:05 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2068.outbound.protection.outlook.com [40.107.243.68]) (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 586633A095D for ; Mon, 28 Sep 2020 12:33:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C+WCUB/spVAE2vy462TuSP+niM04DMQAaeVsUpB3dSFwnhsnfweye4UFru1qf8Y+zMdcIVUcYfsKGG4Xek9NAiMkqBGQ/L4EXgC3M5l/UJqMPPww4MF1UmXGsBERm7DdacI+rrdcU9OKcvGn1jAuBW0hu6f3M5OFK8Jkm0sys95vLne0wtWl+YdecxLNyb6dR8uO2LNXMe2/maYaMRFR7Fh0zFyMrN9qs2DWv6+30jEtk3fDLbK9SR91jfcXcjsIkJ4+TwvxdqoBr1W1FjYUHmhs7cknYFnOiqPyfbeviZ3vqMfB6NHDJjZTDwVBPhPWkVkBhW7HX8ohjuNHmLDS8A== 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=tTy9OTVzOQ4TfF48yOzz82fEHDWLvxPEj7Ae/J6fTRs=; b=BghAKBGQRrZ4Y7kEHQ0qVPag7xZO0vvCFosCq3NLbzml4KHwq/Lddoyuva0PON+gW04YNDyJbl7JY05V0xzo26pp2rHJ/8tRA6DhiYVDiYzQ+oz9UxFMxdUq5hWgdEg3TsPMPO68wQTyAfVlPFqpnCw7TALS9exoRC6/BPlVdqvlZGyHL9bXtJukbnLlKHhhsurFyQEp496a1YMFSJ7w7Zq4u9b5X9JAsIfJCcOM4Yc0v+pCcPtGL2ffsTOS+jIVOfgBDO/aD4AjhyWAmCLkwu3a0B9iZbjHm8I3o8lF0toAI3zbmSXhK9JPTNJh1OhSxGFjAriM0Nefb2FBiIya5Q== 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=tTy9OTVzOQ4TfF48yOzz82fEHDWLvxPEj7Ae/J6fTRs=; b=GAGGatDjnuAtbM0o5gp5ZRqB3i0oiPxsTzhtF+o2pHsQgXQQmdKQpc+zTYHiB/P1GKlo5/sklMHqMRdC2F5OrJdLg/L1nfjvOG9JsScX+CVzlw3P35ER0P0JQmnGkYIcjei/V11ZYnGIwK+3IZG7Vt7o0AD+Nz9RrB9P4OHD5Bc= Received: from SA0PR11CA0021.namprd11.prod.outlook.com (2603:10b6:806:d3::26) by DM5PR12MB1932.namprd12.prod.outlook.com (2603:10b6:3:10e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Mon, 28 Sep 2020 19:33:04 +0000 Received: from SN1NAM02FT061.eop-nam02.prod.protection.outlook.com (2603:10b6:806:d3:cafe::c3) by SA0PR11CA0021.outlook.office365.com (2603:10b6:806:d3::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22 via Frontend Transport; Mon, 28 Sep 2020 19:33:03 +0000 X-MS-Exchange-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 SN1NAM02FT061.mail.protection.outlook.com (10.152.72.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Mon, 28 Sep 2020 19:33:03 +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 08SJX13J019979 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 28 Sep 2020 15:33:02 -0400 To: rum@ietf.org References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <303CFB8D-1323-4237-8D84-91BF6201B6F5@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Mon, 28 Sep 2020 15:33:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 049df7e1-1a10-43d4-b275-08d863e55148 X-MS-TrafficTypeDiagnostic: DM5PR12MB1932: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: T0tbRVZwCdb9jk5ZBL+JuMZ/iRqfMR5ltQTNm81ayQcls+k16ijRDnv7i1PKvM/D8Lx1hv2yVBE8heWq1BoVF1qGhf5WKSfKyP5Eup7gJ5IQv0goTA2lIYFDKrsnF5+JO32hkFBPKablxzgWEPnJPYf1fnj0D4TxG7CfxOHtG//d9iEN94fBYdlmzyuhvevyT7jscN6Uy01wY9mXJWzJL/YX4ZuUdYPielQh1anBytS5kTEM+hrtqPNPdTf4GEMCjX8NU4CkchyFd9+mJoEsae8SIyQrYyR5XuAjIy4foDP3dRaCxfBoNIC0Ll3rBMroIES3Lxq8MRkvmZpVPPA+mY/0Rlg4swA1dReDJhQYuhyO4ftOnQlK0ttKy5yRi7Pcfj3gWarSGmf1Q+U3PBQ49BKXWhGcPZUWWq2tWQLqFCEnghM6MiZiQN/SZnVDssZe58JzI5GE8JkWJMv17CRFFshBBRvtfme+mT+4sYtaqK8= X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(39860400002)(376002)(346002)(396003)(136003)(46966005)(316002)(786003)(356005)(36906005)(186003)(5660300002)(26005)(82310400003)(70206006)(70586007)(83380400001)(8936002)(86362001)(8676002)(31696002)(7596003)(75432002)(31686004)(53546011)(336012)(478600001)(2906002)(2616005)(956004)(82740400003)(47076004)(6916009)(15650500001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2020 19:33:03.3465 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 049df7e1-1a10-43d4-b275-08d863e55148 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-AuthSource: SN1NAM02FT061.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1932 Archived-At: Subject: Re: [Rum] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 19:33:07 -0000 On 9/27/20 12:35 AM, Paul Kyzivat wrote: > On 9/26/20 8:58 PM, Brian Rosen wrote: >> I think we do want the spec to support multiple providers on one >> device/user.  I think that’s the point of having the file.  If it >> wasn’t them the user could just use the password for the single >> provider directly and not need any other mechanism. >> >> ISTM that if the user has a password (and possibly a second factor >> like a USB security device), then it can securely unlock a local >> resource that contains the credentials.  They can be stored encrypted, >> where the decrypt requires the passwords at least initially. >> >> The simplest model is perhaps too simple: a local encrypted file >> containing sign-on credentials that is decrypted with the user >> entering a password.  That is one password per user regardless of how >> many providers they use. > > Yes, I think it is too simple. The RUE needs access to those sign-on > credentials in situations where the user isn't present. For instance, > suppose it is restarted due to power failure. Then it must reregister > ASAP in order to be available to receive incoming calls. There are lots > of other cases as well. I definitely am not up to speed on the state of the art in this area. I wonder if we can recruit an expert to help. Perhaps request a security review. Paul From nobody Mon Sep 28 23:08:05 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8873A07BD for ; Mon, 28 Sep 2020 23:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 KJ_zsnKzN-fJ for ; Mon, 28 Sep 2020 23:08:00 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 098793A0822 for ; Mon, 28 Sep 2020 23:07:59 -0700 (PDT) Received: from macbook-pro.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 7795B2361; Tue, 29 Sep 2020 08:07:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 29 Sep 2020 08:07:36 +0200 Cc: Olle E Johansson , rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <303CFB8D-1323-4237-8D84-91BF6201B6F5@brianrosen.net> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 06:08:03 -0000 > On 28 Sep 2020, at 21:33, Paul Kyzivat wrote: >=20 > On 9/27/20 12:35 AM, Paul Kyzivat wrote: >> On 9/26/20 8:58 PM, Brian Rosen wrote: >>> I think we do want the spec to support multiple providers on one = device/user. I think that=E2=80=99s the point of having the file. If = it wasn=E2=80=99t them the user could just use the password for the = single provider directly and not need any other mechanism. >>>=20 >>> ISTM that if the user has a password (and possibly a second factor = like a USB security device), then it can securely unlock a local = resource that contains the credentials. They can be stored encrypted, = where the decrypt requires the passwords at least initially. >>>=20 >>> The simplest model is perhaps too simple: a local encrypted file = containing sign-on credentials that is decrypted with the user entering = a password. That is one password per user regardless of how many = providers they use. >> Yes, I think it is too simple. The RUE needs access to those sign-on = credentials in situations where the user isn't present. For instance, = suppose it is restarted due to power failure. Then it must reregister = ASAP in order to be available to receive incoming calls. There are lots = of other cases as well. >=20 > I definitely am not up to speed on the state of the art in this area. = I wonder if we can recruit an expert to help. Perhaps request a security = review. >=20 I think RUM is a perfect use-case for the new Oauth2/OpenID Connect auth = mechanism in SIP. /O From nobody Tue Sep 29 04:49:00 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E433A0C82 for ; Tue, 29 Sep 2020 04:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=mitre.org 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 cUDUHuH9tBeR for ; Tue, 29 Sep 2020 04:48:57 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (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 D65473A0C81 for ; Tue, 29 Sep 2020 04:48:56 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7A0741BE05D; Tue, 29 Sep 2020 07:48:54 -0400 (EDT) Received: from smtprhbv1.mitre.org (unknown [129.83.19.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id 379351BE024; Tue, 29 Sep 2020 07:48:54 -0400 (EDT) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 281B780C790; Tue, 29 Sep 2020 07:48:54 -0400 (EDT) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4C0yMp153yz3D5mM; Tue, 29 Sep 2020 11:48:47 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2104.outbound.protection.outlook.com [104.47.64.104]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4C0yMb4LBwz3D5rn; Tue, 29 Sep 2020 11:48:43 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FyNwIo+6OrK/tPmzHHQVdFjzZsgqXjQnYXfhw6kySf7FMcxYgsUYrMjBx4UYYvavyI5w4uQIgO4/eDoCVtZEgnIre57ee0ELChCF5eWIKyht6+fQi5OpoQYAGl6TjsrgN11DGDWwsrT8ymlZh7/5cac4uTiRJESjjcE3keQxtYtWsHiqqWTv9pjUJSl+2+io5lHDvRf3Xb4w0FV6kOwkGY2xwGM4KXBtl2sUOu7GGYYDDJalc9UknkQ80JAF1SXKG62qwkgSB7kCr2vUA4kyIA87ocbW8WagdfXBbuYlyjzH/pkSku/77bXQiLMdwVk/i88OJcoZV7pku3j4r3t0ag== 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=yOcEdnzRujD+d2lKjsIUpugk4hoo+pMwWEzuQvUjVwE=; b=elXfhi5+pIC0S88IPLDEAlhkDPn8HN3U+6egNUqibMLwORm5aFPBnivE8oCPqm6NV4ihmNNRJQIH7jmZf5fYJKHboe+3Io1qNv5/7f+2ek9zGD2XlRUY2soOPUIRP7Lr3NQrVX630KQr9cw5GcptD8ndzgmK0/395AXdC+dfGiEDLlEuTuNt9F9NIN6DbdK8Qqjmrl60bL3yD0jJpXoDcq89l2js7jGVMjG5yvbGnbl1N6KX1hgs9k2BNxHfjRZBpI0Or/Rzd4dk0K07zXQxUI0SxRUnBEp7rISpGmC0ta+I9dCMDCxaVj8Co3mt/9bhSpEdmZimfLhtGhDlfaJllg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from MN2PR09MB5948.namprd09.prod.outlook.com (2603:10b6:208:21f::14) by MN2PR09MB5660.namprd09.prod.outlook.com (2603:10b6:208:213::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32; Tue, 29 Sep 2020 11:48:42 +0000 Received: from MN2PR09MB5948.namprd09.prod.outlook.com ([fe80::5194:f4fa:c7d:9ff3]) by MN2PR09MB5948.namprd09.prod.outlook.com ([fe80::5194:f4fa:c7d:9ff3%4]) with mapi id 15.20.3412.029; Tue, 29 Sep 2020 11:48:42 +0000 From: Jim Malloy To: "Kyzivat, Paul" , "rum@ietf.org" Thread-Topic: [EXT] [Rum] RUM security model Thread-Index: AQHWlCmH4D+WsfOq+kWpKC9HQwSQkal/gr+w Date: Tue, 29 Sep 2020 11:48:42 +0000 Message-ID: References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <3757_1601140882_5F6F7891_3757_32_1_a4a62f53-1571-56ec-35b9-7faecd4fa480@alum.mit.edu> In-Reply-To: <3757_1601140882_5F6F7891_3757_32_1_a4a62f53-1571-56ec-35b9-7faecd4fa480@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=mitre.org; x-originating-ip: [192.160.51.88] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 592daf8d-bb32-4819-3645-08d8646d9d18 x-ms-traffictypediagnostic: MN2PR09MB5660: x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Cm0W4vBSKMai64WrzFU4X4KbCgEARlhYzn0Hyxr1BvW7Zn+7OIUkeg6VQRHTPVYLm8PMLwMUUQ1KgjHRXtKwNW5NLKpaLayCP0N4XIUkZ0uzMHUCcIKcB6Tzc1vRt1VLbUIeuE55POX0HMy/ijzio4xflLmxmolyUS+VxOenf6IxVdwu3YyDV3dW/x5TBMe/nNyHmQzuaGzY5OJspVMpOPY2M5OzFnp/dfAwVcy8z0xdOpEaBdnpYcS0qi4NaVK89mbghS0JVI1Iu8TuXzr9GuvMVlzyVREmtadh6jR7ORg1Ghx9qs71fLK8lg43Dvj3coonlbKeHjLDdlg253DDMvx3iExRriLTsCfAfIxFPdn/4ihRL3va0EHwmbT/8i0D4DT1kVy11QrHYj5JWFqU8Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB5948.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(136003)(376002)(396003)(346002)(9686003)(2906002)(15650500001)(55016002)(83080400001)(8936002)(83380400001)(478600001)(76116006)(8676002)(316002)(966005)(86362001)(110136005)(5660300002)(7696005)(6506007)(52536014)(53546011)(26005)(186003)(66446008)(33656002)(66946007)(64756008)(66556008)(66476007)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +rkhy3JGeXcC85zr8goOPS6CuxEkkZgOPWBOfX9zm7Lkf8UvpwqQ6K1r2z6zV87CtkTsNzQDHBNGaH34ZMUdxAvf0H8bguEhgzdV9tZpEWUJNPUWNlavdltC2Yw+87mz+lG3HI8y9YTCuR2tlh52T6ZUuDMsyyizuU6R+hnBB5ppr4PmSFOlOpaL5rNLGZBVjOF3+kWhxQEuqwPwws+MGDFc0GsjH4H1G32U2KXNsrvKwnDuqCYfE1S9iOrLozCR/MhfllxwZiU9X9cAvC//0MKb0C4FTTAPzC8We+kPh9uo5y4kqF07KlMDFPX+H8ZRdckdDNrIlFwJFw+tMgMMaAQXa7UXOLRTVfWBECp5xiydmAXHMf3vWzgdFF9xytXk12yT5npQmnE/zaU+BEeOKDSMKRYjRDBsk8GucxSwxNXKXwHDw8GFEdHiit8kvM2uhVRiN9pKJ82xSXGJeinDNIJYTs3iWKmPYorNOb8+SM10kQu+dNCbnBfcwRtgLnyC50TofS4Fg0lp386FCdS0lGBblSPKLYMq6kyKVoGsnn8/wmuXL1VJDoa50O5j7SJ9bFPtLl954fvYOu5syeLeUBWLrgJPWNqgbi1sbv2oKIiWkLK6xIBrA2U2/M8GgT5zNmecQ7057jpC/v1f586N6g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB5948.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 592daf8d-bb32-4819-3645-08d8646d9d18 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2020 11:48:42.1134 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R0Neal9gN02STYxSMJwKkZhtfuPtKck33YIUWUTgbits4G9lPxREweb54BPc+dWzmM2hscyOhW4cMPe1wfdeKA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB5660 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:subject:date:message-id:references:in-reply-to:content-type:content-transfer-encoding:mime-version; s=selector1; bh=yOcEdnzRujD+d2lKjsIUpugk4hoo+pMwWEzuQvUjVwE=; b=V/XHImOMWmSIHhbd+/L1LEX+g+9hiQO7wIi7DCbYt5uWAwP8pWMU+wvTZVSHv2mifgU1/Uf9Or78zJgJ2vK/wjkegR0ffu53gixxRwnHGDz5Advy5CClzeJa7eltJA8MOY0jsQpLcno+Vw0X+9Vik24ZYHSFZuL/5+J4CzFo9ok= Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 11:48:59 -0000 Paul -=20 Quick clarification - when you said "Credentials held by the RUM device in = support of (1) and (2) must be secured", were you referring to secured in t= ransit or secured while stored on the RUM device? If the latter, does this= fall within the scope of this document? ("This document describes the int= erface between a videophone and a provider".) I agree that device characteristics, including security, is an important to= pic, but not one we've been addressing.=20 Thanks, Jim Malloy Principal Information System Engineer The MITRE Corp. 703 983 2835 -----Original Message----- From: Rum On Behalf Of Paul Kyzivat Sent: Saturday, September 26, 2020 1:21 PM To: rum@ietf.org Subject: [EXT] [Rum] RUM security model On 9/18/20 11:52 AM, Paul Kyzivat wrote: > Brian, >=20 > Thanks for reviving this and resolving some of the open issues. I hope=20 > we can soon identify and resolve remaining issues. >=20 > I do think the password issue is going to be tricky to sort out. We=20 > should get a discussion going on it. I'm thinking that we may need a=20 > whole section discussing the security model. Some brainstorming on this - half baked thoughts: 1) In many cases a RUM device is an always-on device. It must possess crede= ntials that allow it to remain authenticated to a registrar even when no us= er is present. (Not different from many sip devices, but worth calling out.= ) 2) It is the user (owner?) of the RUM device that must first authenticate t= o a provider. This authentication then needs to be delegated to the RUM dev= ice to satisfy the requirements of (1). 3) There will be a need for the *user* to periodically reauthenticate.=20 This may sometimes be time based, but may also be required when the device = or server have been compromised, etc. This can be a problem if it occurs wh= en the user isn't immediately available. In most cases the RUM device shoul= d still be allowed to remain registered for receipt of incoming calls until= such time as a user is present to participate in reauthentication. 4) Credentials held by the RUM device in support of (1) and (2) must be sec= ured. It should be impossible for an attacker to extract these credentials = and reuse them in another device. (This is hard. We may not be able to full= y achieve it in the spec. But we need to consider it.) 5) The security system for RUM devices must be compatible with RUM devices = that support simultaneous registration to multiple VRS providers. However t= here is no requirement for a RUM device to support this feature. (It isn't = clear to me if this requirement imposes any particular burden on the spec. = I only bring it up to cover all the bases.) Note: In the above I keep using the term "RUM device". I did this because I *think* RUE is a more generic term that encompasses both RUM compliant devi= ces and non-compliant ones like existing proprietary VRS provider supplied = user devices. I think it is too late to restrict the definition of RUE to being compliant= to RUM, since it is used in the more generic sense in the provider profile= . I'm content to keep using "RUM device" but I'm open to other suggestions.= In any case, whatever we decide should go into the definitions. --=20 Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Tue Sep 29 05:58:29 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0063A0C32 for ; Tue, 29 Sep 2020 05:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 T750JpytaqnZ for ; Tue, 29 Sep 2020 05:58:13 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 577253A0C22 for ; Tue, 29 Sep 2020 05:58:13 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id o5so4126120qke.12 for ; Tue, 29 Sep 2020 05:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SzgEdX3Rp7Ptj73fhxVsB5mOi+A0+EPKa0ilZBD+q+c=; b=ph8kPPxiCB8Dp1lGW7r4Zds/WOuxmHO26jHSp4Ni/2/jyA+nFsNYzIS0bfvFhbwVAS nx0by5MYaap0XudqIMat33PPcDBFDukKxvuiX+zQRBVr7pc7nA6O9VjQsV6mnUlis5gC W7x+zzvKaw2ng6iGavrhEnsfSptStk7TvRgRrWRaNhHCekdlakguhUwcbviZSyqvzQkP 9EryRyFqIPxqzCWKUmCkOsXM9xWxUCJh7rvS/0vK7bvv0Je9jwSQ6QA+Zzw5cgpaLUW3 8ZARKYU4wx3RbrvCt3Ln246RXnY68aOh17vdNTHPlzY592BiMHjiad81OpSO5W8nDTsJ az0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SzgEdX3Rp7Ptj73fhxVsB5mOi+A0+EPKa0ilZBD+q+c=; b=uOc4AkCbG4UvG4YLB3UCVes1ZBWcyDKPRMBzES3/HO200/etl1mRCyoIq6eDDn3CSN Qdgo4RHPNPOo35dt5xYe+ybpD6rnDtJYyXjgiiyKVLbC7WVcWAaesWml8fEPYUf5YMcw ieT1tOaeT6qv1bZeS6GqzccFLDjU4VMxrtE2aY6tfwcPev054mdxwunMF65MDg4SRL0E g9jX1EQPUqYLCxGOGFyLOtOXH1ceoisXHxM+NzKH4li4fzQdl8BNyxLwO5g4d9oOTKuW Qe/uKOPWCVSkw3VI8boi1hsycNgz6eTG1nvEjjHvPNvAgOuo/4IQeMH4QPE3hNu29xg5 STRw== X-Gm-Message-State: AOAM533OiYeKc7hEgWrgJH+TbSM9CJiSBynczRMLckiYDHLwTVwUP507 msjWCAbAy4fLBQ7dKuuBEM3OWWNoJBqe7kGYCgbImVF5aDUp6w== X-Google-Smtp-Source: ABdhPJy8OT9ipgwORSTNqp4YVqaaj4Tv38g+7kP8Tom7xt5PYNiRFkriT+1CNl7080DMI8c/gflZPxKU4qHWf655G4A= X-Received: by 2002:a37:6301:: with SMTP id x1mr4096846qkb.323.1601384292332; Tue, 29 Sep 2020 05:58:12 -0700 (PDT) MIME-Version: 1.0 References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <303CFB8D-1323-4237-8D84-91BF6201B6F5@brianrosen.net> In-Reply-To: From: Brian Rosen Date: Tue, 29 Sep 2020 08:58:01 -0400 Message-ID: To: "Olle E. Johansson" Cc: Paul Kyzivat , rum@ietf.org Content-Type: multipart/alternative; boundary="000000000000e4cd5705b073552f" Archived-At: Subject: Re: [Rum] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 12:58:19 -0000 --000000000000e4cd5705b073552f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While I personally think thats the way to go, most existing providers use the existing registration mechanisms. If they were supportive of using OAUTH2 instead, I would be VERY happy to make that change. But that wouldn=E2=80=99t solve the problem we are discussing, which is how= the RUE device maintains credentials from multiple providers. I suppose the providers could use another provider as a identity provider for the purposes of logging in their own customer, but that is even more remote from where they are now. Brian On Tue, Sep 29, 2020 at 2:08 AM Olle E. Johansson wrote: > > > > > > On 28 Sep 2020, at 21:33, Paul Kyzivat wrote: > > > > > > On 9/27/20 12:35 AM, Paul Kyzivat wrote: > > >> On 9/26/20 8:58 PM, Brian Rosen wrote: > > >>> I think we do want the spec to support multiple providers on one > device/user. I think that=E2=80=99s the point of having the file. If it= wasn=E2=80=99t > them the user could just use the password for the single provider directl= y > and not need any other mechanism. > > >>> > > >>> ISTM that if the user has a password (and possibly a second factor > like a USB security device), then it can securely unlock a local resource > that contains the credentials. They can be stored encrypted, where the > decrypt requires the passwords at least initially. > > >>> > > >>> The simplest model is perhaps too simple: a local encrypted file > containing sign-on credentials that is decrypted with the user entering a > password. That is one password per user regardless of how many providers > they use. > > >> Yes, I think it is too simple. The RUE needs access to those sign-on > credentials in situations where the user isn't present. For instance, > suppose it is restarted due to power failure. Then it must reregister ASA= P > in order to be available to receive incoming calls. There are lots of oth= er > cases as well. > > > > > > I definitely am not up to speed on the state of the art in this area. I > wonder if we can recruit an expert to help. Perhaps request a security > review. > > > > > I think RUM is a perfect use-case for the new Oauth2/OpenID Connect auth > mechanism in SIP. > > > > /O > > > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > --000000000000e4cd5705b073552f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I personally think thats the way to go, most existi= ng providers use the existing registration mechanisms. If they were support= ive of using OAUTH2 instead, I would be VERY happy to make that change.=C2= =A0

But that wouldn=E2= =80=99t solve the problem we are discussing, which is how the RUE device ma= intains credentials from multiple providers.=C2=A0 I suppose the providers = could use another provider as a identity provider for the purposes of loggi= ng in their own customer, but that is even more remote from where they are = now.=C2=A0

Brian=C2=A0

On Tue, Sep 29, 2020 at 2:08 AM Olle E. Johansson <oej@edvina.net> wrote:



> On 28 Sep 2020, at 21:33, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

>

> On 9/27/20 12:35 AM, Paul Kyzivat wrote:
>> On 9/26/20 8:58 PM, Brian Rosen wrote:

>>> I = think we do want the spec to support multiple providers on one device/user.= =C2=A0 I think that=E2=80=99s the point of having the file.=C2=A0 If it was= n=E2=80=99t them the user could just use the password for the single provid= er directly and not need any other mechanism.

>>>

&= gt;>> ISTM that if the user has a password (and possibly a second fac= tor like a USB security device), then it can securely unlock a local resour= ce that contains the credentials.=C2=A0 They can be stored encrypted, where= the decrypt requires the passwords at least initially.

>>>=

>>> The simplest model is perhaps too simple: a local enc= rypted file containing sign-on credentials that is decrypted with the user = entering a password.=C2=A0 That is one password per user regardless of how = many providers they use.

>> Yes, I think it is too simple. The= RUE needs access to those sign-on credentials in situations where the user= isn't present. For instance, suppose it is restarted due to power fail= ure. Then it must reregister ASAP in order to be available to receive incom= ing calls. There are lots of other cases as well.

>

> = I definitely am not up to speed on the state of the art in this area. I won= der if we can recruit an expert to help. Perhaps request a security review.=

>

I think RUM is a perfect use-case for the new Oauth2/O= penID Connect auth mechanism in SIP.



/O



--
Rum mailing list

Rum@ietf.org

https://www.ietf.org/mailman/l= istinfo/rum

--000000000000e4cd5705b073552f-- From nobody Tue Sep 29 09:17:18 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284EB3A144F for ; Tue, 29 Sep 2020 09:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 VfkjjN9Q3wY1 for ; Tue, 29 Sep 2020 09:17:07 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770055.outbound.protection.outlook.com [40.107.77.55]) (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 F1E903A0FA4 for ; Tue, 29 Sep 2020 09:16:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mkYjWzkqjk2tXP/ZZeZfSqdkqMxWibIMzbvD02b5GgXrowiawGALr84kcBzUtbWiYxXAkZ/y7yO+pMk02KI7C9ApUGsKAGQ33o2Gm34j1wVEAGZbmekofff12pyU1AiG7ug2+rMS7ObePcRnsKet6npieiVaazVqxmmogtocFIhM/Z8Gi9nIv0vvav+cAiT0hqof2E4o+XDLK52bZWke1ZqOX8cWGLWcg1Cm5mmykOLEogUdtm/sp7io7GBqOVaR10lGKcgpEilpEGAoJZJqGS9f1YcyhsC2j+5gIkhV6Ls82/beF+CcXm0018lFjC815/U+kRkO7aUm7xlVFRQe2w== 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=DOQcKV4uodlU/UbDVHWNU79x1dTPDOewDnHaADwpRg4=; b=SOugBl74U4kjoo02cE6vCwzJ3OL/mw/8BlqhD5uG/43stNkmRXQTv+2KOZ86JRIfVl984x8vJnkW5fREEhLK6hIJ7owIFwnMFapXsEnxcagGf8wtFp+bW5uvvPxe+/Ta4kft/v1SONvC1ZgegBvQLkHbM9CMkYxFLQ6t8ZIzkGm4rPJqO72hjNZFhpQZ2D6zK1h9M3EZ2IinKwQ6pDEnNcA93+yJB0Ai7762erwxKFe7xlb5HCyyZ5+Lk9U3k6ngjRpinW9Yc0C6lBdj2lW/Q+FsUr4AizfXiQIuUQUGOffk9/X61jyvDhg0K4YLmIG176cYxynn6fXpIqqPPZ9hww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none 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=DOQcKV4uodlU/UbDVHWNU79x1dTPDOewDnHaADwpRg4=; b=R6TQr/waluKoS3rkV/29tW9yOfOiY9FdBPxUXsL0GHOtt0px6ehdlZRbY0gxLx3CekcKg5ByQHaRRDMVBN5Wc+zAyGkkD4x0Etc7S9daKSuBRGkDhOAK7P8Hg4xu50zrDkbVVFzVSkY5paNQ7iXbdDPLHrD3TAz1EsBvEV9YiUg= Received: from MN2PR03CA0027.namprd03.prod.outlook.com (2603:10b6:208:23a::32) by MN2PR12MB2912.namprd12.prod.outlook.com (2603:10b6:208:ac::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22; Tue, 29 Sep 2020 16:16:13 +0000 Received: from BL2NAM02FT040.eop-nam02.prod.protection.outlook.com (2603:10b6:208:23a:cafe::73) by MN2PR03CA0027.outlook.office365.com (2603:10b6:208:23a::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20 via Frontend Transport; Tue, 29 Sep 2020 16:16:13 +0000 X-MS-Exchange-Authentication-Results: spf=temperror (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=none action=none header.from=alum.mit.edu; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of alum.mit.edu: DNS Timeout) Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT040.mail.protection.outlook.com (10.152.77.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Tue, 29 Sep 2020 16:16:12 +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 08TGGAWR009062 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 29 Sep 2020 12:16:11 -0400 To: rum@ietf.org References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <3757_1601140882_5F6F7891_3757_32_1_a4a62f53-1571-56ec-35b9-7faecd4fa480@alum.mit.edu> From: Paul Kyzivat Message-ID: <927a8854-51b9-c768-ee1e-5d0c4b76a45f@alum.mit.edu> Date: Tue, 29 Sep 2020 12:16:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8cec4564-7891-45e8-7a38-08d86492fb8b X-MS-TrafficTypeDiagnostic: MN2PR12MB2912: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: VoMBdQP5P4lrs2v9vdba4DRig65Ol9/YlHSg7X8PhzbPIKP1Zq/GjL1iKktizWdAuC17PBlIaUs+80sHKOk9gxIxcAk6BagkgHOOQ8NAPIh9nVyuDYZAUgfslWNRFluf0EDiJB4vYd4ufGuuTHCshpjbrAwRMhMiI1iXIn/bL+Hqw02Kbm3Y+zJ9lIcEppHf1PYWpGmzeoIHAN1w76j3510bmKpvUHPVEBUDrSI2XFd9DT/ZF6WYQEdkypkdHbQo65ISDvkgIGFZny5twjG+0Tbw/Lj+Ct5yeNTAOmH7gMfWvNYGcpwwDsIp1AW17Si4Ro/Cm4HRf5Dk4yaC8weP0m8+JGLEEk31g0S4GmKMsJG0y0bXqc1Zc7pSfbZij58CF51T5MaF+mXb9A0Lx+3KimG0XwV8V4KHGQ0Mfs50o6W+d7cT4+x1ZhHnB4c8rc42r3CAuSOCNgKmXS8GspBDXijZ8kPXlMcp5fhXb8tWIzA= X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(39860400002)(346002)(396003)(136003)(376002)(46966005)(70206006)(786003)(316002)(15650500001)(2906002)(8676002)(8936002)(86362001)(75432002)(31686004)(31696002)(36906005)(478600001)(53546011)(336012)(186003)(5660300002)(26005)(7596003)(356005)(83380400001)(2616005)(6916009)(82310400003)(47076004)(63350400001)(82740400003)(70586007)(956004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2020 16:16:12.0530 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8cec4564-7891-45e8-7a38-08d86492fb8b 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-AuthSource: BL2NAM02FT040.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB2912 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 16:17:16 -0000 Jim, On 9/29/20 7:48 AM, Jim Malloy wrote: > Paul - > > Quick clarification - when you said "Credentials held by the RUM device in support of (1) and (2) must be secured", were you referring to secured in transit or secured while stored on the RUM device? If the latter, does this fall within the scope of this document? ("This document describes the interface between a videophone and a provider".) > > I agree that device characteristics, including security, is an important topic, but not one we've been addressing. I meant secured on the device. IMO some aspects of this have to be in scope. It would be irresponsible to specify an interface that requires magic to be secured on the device. The mechanism(s) used to secure things on the device are likely to impact the interface with the provider even though the *precise* mechanisms used locally to accomplish this will be out of scope. In any case, the statements are my personal thoughts on what is needed to have a viable spec. Obviously these are subject to discussion and revision. Thanks, Paul > Thanks, > > Jim Malloy > Principal Information System Engineer > The MITRE Corp. > 703 983 2835 > > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: Saturday, September 26, 2020 1:21 PM > To: rum@ietf.org > Subject: [EXT] [Rum] RUM security model > > On 9/18/20 11:52 AM, Paul Kyzivat wrote: >> Brian, >> >> Thanks for reviving this and resolving some of the open issues. I hope >> we can soon identify and resolve remaining issues. >> >> I do think the password issue is going to be tricky to sort out. We >> should get a discussion going on it. I'm thinking that we may need a >> whole section discussing the security model. > > Some brainstorming on this - half baked thoughts: > > 1) In many cases a RUM device is an always-on device. It must possess credentials that allow it to remain authenticated to a registrar even when no user is present. (Not different from many sip devices, but worth calling out.) > > 2) It is the user (owner?) of the RUM device that must first authenticate to a provider. This authentication then needs to be delegated to the RUM device to satisfy the requirements of (1). > > 3) There will be a need for the *user* to periodically reauthenticate. > This may sometimes be time based, but may also be required when the device or server have been compromised, etc. This can be a problem if it occurs when the user isn't immediately available. In most cases the RUM device should still be allowed to remain registered for receipt of incoming calls until such time as a user is present to participate in reauthentication. > > 4) Credentials held by the RUM device in support of (1) and (2) must be secured. It should be impossible for an attacker to extract these credentials and reuse them in another device. (This is hard. We may not be able to fully achieve it in the spec. But we need to consider it.) > > 5) The security system for RUM devices must be compatible with RUM devices that support simultaneous registration to multiple VRS providers. However there is no requirement for a RUM device to support this feature. (It isn't clear to me if this requirement imposes any particular burden on the spec. I only bring it up to cover all the bases.) > > Note: > > In the above I keep using the term "RUM device". I did this because I > *think* RUE is a more generic term that encompasses both RUM compliant devices and non-compliant ones like existing proprietary VRS provider supplied user devices. > > I think it is too late to restrict the definition of RUE to being compliant to RUM, since it is used in the more generic sense in the provider profile. I'm content to keep using "RUM device" but I'm open to other suggestions. In any case, whatever we decide should go into the definitions. > From nobody Tue Sep 29 10:14:31 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC713A0F24 for ; Tue, 29 Sep 2020 10:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=mitre.org 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 GaVlr-KGTkjf for ; Tue, 29 Sep 2020 10:14:28 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (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 539513A0F25 for ; Tue, 29 Sep 2020 10:14:28 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2E419332002; Tue, 29 Sep 2020 13:14:27 -0400 (EDT) Received: from smtprhbv1.mitre.org (unknown [129.83.19.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id ECD9633201E; Tue, 29 Sep 2020 13:14:26 -0400 (EDT) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id DE59F964C8E; Tue, 29 Sep 2020 13:14:26 -0400 (EDT) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4C15bQ6NMTz3D5qQ; Tue, 29 Sep 2020 17:14:01 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2102.outbound.protection.outlook.com [104.47.64.102]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4C15Zt4phnz3D4Sb; Tue, 29 Sep 2020 17:13:57 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RA9ftMcRrHzXh5fFtR+enFbqKnoy03zo9zingm2B8fsF52us0xRmQ5r+3af1RqtANlyYwcekeFpJhhmp11iP0uHLufdN+ho1oZh9BTVywCAPYgvBJv3Ur9X9V5ai5FF/m/yrF8/F0y9FaT044Y/ZkLUDsMjlEeDeRcIRJbh7GwpoBOOLEFxe2chMjmEDtMpUu2Ibq5/+CzyMc9jGQGfg90MkhoV3fbCNtzH/q9sTHKnKqMpmwrtPEn8qQPQdGRgtL9Ta/NYwjyGqQO8lK3An7hfduqnUN0x3mYrLjAvQSGSDc+bvwKE+iWnzjqiwsy8pVIzPhj6PhVYaXdxTIQJBWQ== 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=lGZOqf2qvIq/2j7nSF5IxS5sRG8SSZIWwN4a2Fw2PjU=; b=j+Mk8lloG/eP2gquvijMBIzb+Tticyo4IrK5iGNBndIWANKxbFaMe0IDOxKyx3GSadH+m3sNcRucOwF+yATcTHiWVLWDQf53nvYdOjAMpIqB46mtEqvftEVbhz7sdUU3SVh8CWofITOeufpnlgNcnneW+9mpq+ekQyWm6Iz19uQb7oXotawrAbSNl5SGspGIfDgOPt7T5RKaySar6RKUq8LrdvVp8m9FKmNbFW5hTAVS4+wzyozLUf69lZAt/zLZbw6+QTiRSvWsQ8LNokJj+qMQvITFJQjfzzKWRqHHYpINcstpG3EyoUnFPpbx7nIcQVczmuTMjxJKEt4eiuVlJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from MN2PR09MB5948.namprd09.prod.outlook.com (2603:10b6:208:21f::14) by BLAPR09MB6306.namprd09.prod.outlook.com (2603:10b6:208:2a4::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.34; Tue, 29 Sep 2020 17:13:56 +0000 Received: from MN2PR09MB5948.namprd09.prod.outlook.com ([fe80::5194:f4fa:c7d:9ff3]) by MN2PR09MB5948.namprd09.prod.outlook.com ([fe80::5194:f4fa:c7d:9ff3%4]) with mapi id 15.20.3412.029; Tue, 29 Sep 2020 17:13:56 +0000 From: Jim Malloy To: "Kyzivat, Paul" , "rum@ietf.org" Thread-Topic: [Rum] [EXT] RUM security model Thread-Index: AQHWlnxSFqCHbktQJ06dPWUjfLD2gKl/2Wjw Date: Tue, 29 Sep 2020 17:13:56 +0000 Message-ID: References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <3757_1601140882_5F6F7891_3757_32_1_a4a62f53-1571-56ec-35b9-7faecd4fa480@alum.mit.edu> <927a8854-51b9-c768-ee1e-5d0c4b76a45f@alum.mit.edu> In-Reply-To: <927a8854-51b9-c768-ee1e-5d0c4b76a45f@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=mitre.org; x-originating-ip: [192.160.51.88] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1b27eb21-35f4-40a2-3631-08d8649b0c99 x-ms-traffictypediagnostic: BLAPR09MB6306: x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UB/biyqX6TcgyhsYiGz56QhtsMPsukm3sfLjjTEmPKbjw84IewQGtXHzVKaK7UWGvhiwzyg/Xv4pJbYmBMLon7YCLJyfepprgQDB6qyBTOLdSxD8dMx3sPGDXW/DBhE4dO8cV9BJuapglml65B0Hng9wy15LzXDfzy9MS0rzjrKBs1g7aj2A0a5xttEyWfbkpz01YYRgbxz2lLpxb2ibjEdaXN8GNvO+B+UWY+MpPY1W63QmCTLi+59iwyWznD22qP+6/8tWS29ftR0d6Hy1GB5G/FJSiRh3kgWP1BGv3yX1UNXA8kPUXoleH8k4CyMGJdQbareETcFCenRSYrh8JLbtxQb6i5ErgWfU+HL7hqLyBJZHXRoTlgAvWNyMkwaemzeDSpbY05cbaw3GJtZO/A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB5948.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(396003)(366004)(136003)(39860400002)(71200400001)(52536014)(5660300002)(86362001)(66946007)(76116006)(66476007)(64756008)(66556008)(66446008)(966005)(110136005)(478600001)(15650500001)(33656002)(316002)(83080400001)(7696005)(2906002)(8936002)(53546011)(6506007)(83380400001)(186003)(9686003)(55016002)(8676002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: U9Svp+foNKST4K/zQ0f+ATALjQJPee2aPfaMXYdROzRurguNOLXsEqK5dv2NfUUVGa7fMYfisp4t6HpJYuw27UN3l8HW4YFcYXDTie7ctFnblrocESJQoTznnahW6zv0Ht/viy5yXtoiD5iAXx/C7wAouNV5zgt1d4WgewM0zj4B69QFb8rtFoZoMWDgYWWlpyJcoJnzJoE7kld/duO9j1El7atlgqoqZGGqLtA2c2sSpVBKK3rEwd1WkvFxI4raG15RWrh8+1AL0WJEi5oGHpgbVpgOzTknHae8LcWYQp3EEvSQG6DiuVo3oCoh6NHw2rfh7fiei+FCmgUrKQ5qdSkC8kZ3BQKxtUcIjWYC7+jiBywInEaPFGKx3k3VzrVMTMma/eyZ+IE+XWci4Dh+UUN43o7Gez+AwIadHIlG4boLPMfm1vOZAF5MZhtsgqgH9vtQlAvGZQ4E4GBlbO8fnQxFC582Y/iMKRczRqRtVEHI9nt6mrmN9WW1Z2sWyjBlPORnUetiAOK+8EsA+reo534orrIIs/gNHPOc0ruirfEjTRS6krRJIWhge0ZVb+WsLZQT/1NMbQT5E08X4eyAdhXPCGtetEJQh0uFjzZ+K4092cQ6ZaVWkE0op+S1nD00yW/Ast4OUScmxIHCLVlQcA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB5948.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b27eb21-35f4-40a2-3631-08d8649b0c99 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2020 17:13:56.5238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bY1i70EW7i/zPxiuROcDa6APTaEzqntJuM60wV9ABD7Z7mcQowl7s8w7TXqLcSaFtTqk9PbUqm8ftKA+GyWCxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6306 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:subject:date:message-id:references:in-reply-to:content-type:content-transfer-encoding:mime-version; s=selector1; bh=lGZOqf2qvIq/2j7nSF5IxS5sRG8SSZIWwN4a2Fw2PjU=; b=DZbO6Vo7QgkJZaBOVewYjFabwfDwyj3p0fWFEQIJjEBBrn66ByZYMzybblDGZ0YGrWmIn6ZDJJ2mpGoKWn9QuwCumkPYSPD+ixkeOiIhT4WwkinordE5nIud06mDrdsuQaYIe7KBVdXnbG+fNheauBUY/x31kjsDOZOE6O6gq6E= Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 17:14:30 -0000 Got it. Every existing VRS provider, in some manner, manages to cache configuration= information and credentials on their devices (proprietary, Windows, Androi= d, iOS) today. Does this demonstrate that we're not in the "magic" domain?= Or, is the challenge that each provider uses a (potentially) proprietary m= echanism which impacts how and what data needs to be transmitted? Thanks, Jim Malloy Principal Information System Engineer The MITRE Corp. 703 983 2835 -----Original Message----- From: Rum On Behalf Of Paul Kyzivat Sent: Tuesday, September 29, 2020 12:16 PM To: rum@ietf.org Subject: Re: [Rum] [EXT] RUM security model Jim, On 9/29/20 7:48 AM, Jim Malloy wrote: > Paul - >=20 > Quick clarification - when you said "Credentials held by the RUM=20 > device in support of (1) and (2) must be secured", were you referring=20 > to secured in transit or secured while stored on the RUM device? If=20 > the latter, does this fall within the scope of this document? ("This=20 > document describes the interface between a videophone and a=20 > provider".) >=20 > I agree that device characteristics, including security, is an important = topic, but not one we've been addressing. I meant secured on the device. IMO some aspects of this have to be in scope. It would be irresponsible to = specify an interface that requires magic to be secured on the device.=20 The mechanism(s) used to secure things on the device are likely to impact t= he interface with the provider even though the *precise* mechanisms used lo= cally to accomplish this will be out of scope. In any case, the statements are my personal thoughts on what is needed to h= ave a viable spec. Obviously these are subject to discussion and revision. Thanks, Paul > Thanks, >=20 > Jim Malloy > Principal Information System Engineer > The MITRE Corp. > 703 983 2835 >=20 > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: Saturday, September 26, 2020 1:21 PM > To: rum@ietf.org > Subject: [EXT] [Rum] RUM security model >=20 > On 9/18/20 11:52 AM, Paul Kyzivat wrote: >> Brian, >> >> Thanks for reviving this and resolving some of the open issues. I=20 >> hope we can soon identify and resolve remaining issues. >> >> I do think the password issue is going to be tricky to sort out. We=20 >> should get a discussion going on it. I'm thinking that we may need a=20 >> whole section discussing the security model. >=20 > Some brainstorming on this - half baked thoughts: >=20 > 1) In many cases a RUM device is an always-on device. It must possess=20 > credentials that allow it to remain authenticated to a registrar even=20 > when no user is present. (Not different from many sip devices, but=20 > worth calling out.) >=20 > 2) It is the user (owner?) of the RUM device that must first authenticate= to a provider. This authentication then needs to be delegated to the RUM d= evice to satisfy the requirements of (1). >=20 > 3) There will be a need for the *user* to periodically reauthenticate. > This may sometimes be time based, but may also be required when the devic= e or server have been compromised, etc. This can be a problem if it occurs = when the user isn't immediately available. In most cases the RUM device sho= uld still be allowed to remain registered for receipt of incoming calls unt= il such time as a user is present to participate in reauthentication. >=20 > 4) Credentials held by the RUM device in support of (1) and (2) must=20 > be secured. It should be impossible for an attacker to extract these=20 > credentials and reuse them in another device. (This is hard. We may=20 > not be able to fully achieve it in the spec. But we need to consider=20 > it.) >=20 > 5) The security system for RUM devices must be compatible with RUM=20 > devices that support simultaneous registration to multiple VRS=20 > providers. However there is no requirement for a RUM device to support=20 > this feature. (It isn't clear to me if this requirement imposes any=20 > particular burden on the spec. I only bring it up to cover all the=20 > bases.) >=20 > Note: >=20 > In the above I keep using the term "RUM device". I did this because I > *think* RUE is a more generic term that encompasses both RUM compliant de= vices and non-compliant ones like existing proprietary VRS provider supplie= d user devices. >=20 > I think it is too late to restrict the definition of RUE to being complia= nt to RUM, since it is used in the more generic sense in the provider profi= le. I'm content to keep using "RUM device" but I'm open to other suggestion= s. In any case, whatever we decide should go into the definitions. >=20 -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Tue Sep 29 10:28:08 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEEE3A0F33 for ; Tue, 29 Sep 2020 10:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 jth8CSeI0-OV for ; Tue, 29 Sep 2020 10:28:05 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2067.outbound.protection.outlook.com [40.107.94.67]) (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 61ADF3A0F32 for ; Tue, 29 Sep 2020 10:28:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iLi8OjofA0wUT3K48UML5ad4fXE/yL4d1EA0fHGDShK6zPESo4POUoj7TK+G9252mGqyUlh9BNViliKymjQRzCzP9n2WvB20VyMH8qzYmZ6/KbstH5u9Z9R1N4RgEbp/3TC/ss5pCpdA2nGpbX461loWdQMeOUMcJjdmDth8KFbQCZeUlkHJXpX32YR1/Axq3yHTkto6q2/b0Yb9eG3ERw/pz1vM47UCfUQBd6ZF32iM2PngYWhalM9/TNLIG7zUfjm2ralj9LkH50Rj6+ogKlWTFjNIEtYS4ocq9uBMhLveeA/RnYbLwiG1mM+vMoniUCKQbz+4OlezfuEIwnXsrw== 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=YYkD6iWb+IzmNn36WNPTeKpqisf3Ga8+RUwOMxUNUHo=; b=KNd8sfqZJ3Rqi0YfvKLdFXgIAehejLlVWoqWfIgiM8xSLEBm8Ic2aTcmbQnuFPFNzdYW5e2C4DP1Ocj+It3E0BGqBVMNUrDKvyoAVKv0FaC7v1h+AIGbj4kN5ZqN7seZWFmkqHuKJJrsxZBrS7PWY3RLve2sKeoAOi8Ar+GZcql1ivEaOt1VD2xVqYB54J8Jw5hm1U8aZ4mJQwMzDvMGNdzjyfilhzCzD0zglXzFwDeDFVT9HoLYPZuwIvM5TN17Cm0iCykeVr5//IJwgM9ZXSlLw2+siTEKJBuE9qXx1Z+seJ5YcHG4Izd9OHjBOhOrpgg8U7inx72JTV+5isfizg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=mitre.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=YYkD6iWb+IzmNn36WNPTeKpqisf3Ga8+RUwOMxUNUHo=; b=fAPvPdHxiLFfBR+FjTVKqvwa97OcDKA9pEcc4StdYEx2gzjvZie3RCoJE9CPIai8qq3AvsLgscLlb9HYKbTGvVl4vSutS03PwJU0HKfE4vHPhU33UOLFl6Ic8qwsLGcglUPe+P4D+SD9Sqpk4+GZ9RcaOjuGk1Tg19m9AClOuig= Received: from DM5PR10CA0006.namprd10.prod.outlook.com (2603:10b6:4:2::16) by BYAPR12MB3559.namprd12.prod.outlook.com (2603:10b6:a03:d9::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Tue, 29 Sep 2020 17:28:03 +0000 Received: from CY1NAM02FT017.eop-nam02.prod.protection.outlook.com (2603:10b6:4:2:cafe::58) by DM5PR10CA0006.outlook.office365.com (2603:10b6:4:2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32 via Frontend Transport; Tue, 29 Sep 2020 17:28:03 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; mitre.org; dkim=none (message not signed) header.d=none;mitre.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 CY1NAM02FT017.mail.protection.outlook.com (10.152.75.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Tue, 29 Sep 2020 17:28:02 +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 08THRxug014379 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 29 Sep 2020 13:28:00 -0400 To: Jim Malloy , "rum@ietf.org" References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <3757_1601140882_5F6F7891_3757_32_1_a4a62f53-1571-56ec-35b9-7faecd4fa480@alum.mit.edu> <927a8854-51b9-c768-ee1e-5d0c4b76a45f@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Tue, 29 Sep 2020 13:27:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0f685192-bd0f-4ad6-8c42-08d8649d0545 X-MS-TrafficTypeDiagnostic: BYAPR12MB3559: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f0y0MqyQjBESixTLvsrGTwR0FvTLTrfXkpvlYTWhZPM753P1bfgnuUC8ibyJqyknvvJeliuP6xP6U0pkJg0wLa0OGlK1MfovXUyKM1ZbmDgy8kspXsIXVa+JHMa8evP3NDjtZHFYdZa7d2gkHpsMRgy6outrNsWAOEeGETCtMaudt3mvP+SefUOyJODzzBQg6GpKI4Qof0Mi1I4XcrVFtyk9pUklSlmASdqsuD1BDN0EmGx0UP7de9Z23gL3/Fwdk4Dk94Gf+9ycNnB458H6f8CoaHpTRv/1XpHFzZ974Q2uSCTgb8l/r+bFwinK46OzW6VGtaATRkwrwtT+zXdmkMT+eBTDdswecCgrua7YGVliKvOSd+/TsRSEkNXOy0j85sgTK8ABf9ZMajoOqAX5VfSTxXW/XPKftimMzAOg2Jik/swDs+m3ZJlGxlsnV7PH5Q17/CqVuBuZbWoaxaHJYQDLQs7H3M68YNwNBdP3Q5g06WJ7RaskhPw45b6/MJy1JlT1PnqFV85e5cnpC/6e8GmddjIaee7gN4OMTjcHxVKwmw0hhfX0ch/1cD9Js3GV X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(136003)(39860400002)(346002)(396003)(376002)(46966005)(8936002)(53546011)(31696002)(186003)(75432002)(956004)(26005)(110136005)(478600001)(15650500001)(83380400001)(356005)(82310400003)(966005)(2906002)(786003)(31686004)(36906005)(7596003)(47076004)(316002)(5660300002)(86362001)(8676002)(2616005)(82740400003)(336012)(70206006)(70586007)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2020 17:28:02.0959 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0f685192-bd0f-4ad6-8c42-08d8649d0545 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-AuthSource: CY1NAM02FT017.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB3559 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 17:28:07 -0000 On 9/29/20 1:13 PM, Jim Malloy wrote: > Got it. > > Every existing VRS provider, in some manner, manages to cache configuration information and credentials on their devices (proprietary, Windows, Android, iOS) today. Does this demonstrate that we're not in the "magic" domain? Or, is the challenge that each provider uses a (potentially) proprietary mechanism which impacts how and what data needs to be transmitted? Right now the entire mechanism is proprietary and may well depend on security by obscurity. Further, the intent here is to open things up to open source implementations. Those definitely can't rely on obscurity. (Though *nobody* should.) These are the discussions we should be having. Thanks, Paul > Thanks, > > Jim Malloy > Principal Information System Engineer > The MITRE Corp. > 703 983 2835 > > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: Tuesday, September 29, 2020 12:16 PM > To: rum@ietf.org > Subject: Re: [Rum] [EXT] RUM security model > > Jim, > > On 9/29/20 7:48 AM, Jim Malloy wrote: >> Paul - >> >> Quick clarification - when you said "Credentials held by the RUM >> device in support of (1) and (2) must be secured", were you referring >> to secured in transit or secured while stored on the RUM device? If >> the latter, does this fall within the scope of this document? ("This >> document describes the interface between a videophone and a >> provider".) >> >> I agree that device characteristics, including security, is an important topic, but not one we've been addressing. > > I meant secured on the device. > > IMO some aspects of this have to be in scope. It would be irresponsible to specify an interface that requires magic to be secured on the device. > The mechanism(s) used to secure things on the device are likely to impact the interface with the provider even though the *precise* mechanisms used locally to accomplish this will be out of scope. > > In any case, the statements are my personal thoughts on what is needed to have a viable spec. Obviously these are subject to discussion and revision. > > Thanks, > Paul > >> Thanks, >> >> Jim Malloy >> Principal Information System Engineer >> The MITRE Corp. >> 703 983 2835 >> >> -----Original Message----- >> From: Rum On Behalf Of Paul Kyzivat >> Sent: Saturday, September 26, 2020 1:21 PM >> To: rum@ietf.org >> Subject: [EXT] [Rum] RUM security model >> >> On 9/18/20 11:52 AM, Paul Kyzivat wrote: >>> Brian, >>> >>> Thanks for reviving this and resolving some of the open issues. I >>> hope we can soon identify and resolve remaining issues. >>> >>> I do think the password issue is going to be tricky to sort out. We >>> should get a discussion going on it. I'm thinking that we may need a >>> whole section discussing the security model. >> >> Some brainstorming on this - half baked thoughts: >> >> 1) In many cases a RUM device is an always-on device. It must possess >> credentials that allow it to remain authenticated to a registrar even >> when no user is present. (Not different from many sip devices, but >> worth calling out.) >> >> 2) It is the user (owner?) of the RUM device that must first authenticate to a provider. This authentication then needs to be delegated to the RUM device to satisfy the requirements of (1). >> >> 3) There will be a need for the *user* to periodically reauthenticate. >> This may sometimes be time based, but may also be required when the device or server have been compromised, etc. This can be a problem if it occurs when the user isn't immediately available. In most cases the RUM device should still be allowed to remain registered for receipt of incoming calls until such time as a user is present to participate in reauthentication. >> >> 4) Credentials held by the RUM device in support of (1) and (2) must >> be secured. It should be impossible for an attacker to extract these >> credentials and reuse them in another device. (This is hard. We may >> not be able to fully achieve it in the spec. But we need to consider >> it.) >> >> 5) The security system for RUM devices must be compatible with RUM >> devices that support simultaneous registration to multiple VRS >> providers. However there is no requirement for a RUM device to support >> this feature. (It isn't clear to me if this requirement imposes any >> particular burden on the spec. I only bring it up to cover all the >> bases.) >> >> Note: >> >> In the above I keep using the term "RUM device". I did this because I >> *think* RUE is a more generic term that encompasses both RUM compliant devices and non-compliant ones like existing proprietary VRS provider supplied user devices. >> >> I think it is too late to restrict the definition of RUE to being compliant to RUM, since it is used in the more generic sense in the provider profile. I'm content to keep using "RUM device" but I'm open to other suggestions. In any case, whatever we decide should go into the definitions. >> > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > From nobody Wed Sep 30 15:30:26 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE7B3A0D02 for ; Wed, 30 Sep 2020 15:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=sorenson.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 99nZnS5fOQjG for ; Wed, 30 Sep 2020 15:30:22 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690043.outbound.protection.outlook.com [40.107.69.43]) (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 B28FC3A0D03 for ; Wed, 30 Sep 2020 15:30:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kmX0FhBpajPWm6Tdt6xecQIAtOFaXtbYuR7/QSFwSyfjxNcbVN5SeWSpQ4WjarebCmOvva4s+xQLDMMHi55a4RJOfaUHzGb822xcynI95TbkzJyjAH+xaIuZLo914IlCKMcqCFe9phS99uyKKFMQP2AiyeK/RAlhQZPJmsjq+82S1KxsojIyxg+gRzpszcViUlnDoRFzKDnuW8faDQm23CMI8hX4Dc+RGwOkvPoZBmqKrj87VKkmOwaGaQYsXcHHVSlnK9sI6aWUnJCmEcA+LCeoZIGrfIFhGviWsxYZwVC+5I+xEcazNYf74UgnlDyjD0qsdcns+17RmZsF7qTf1w== 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=RqT2pYwXJJKK9lH20ZllLfTr9blXTdfXbWKBC43EmOo=; b=jILj3dYEG4rM7v/Rpd/ClB5KxrlUPQs6XF5Y8c5gJ+HYAZz0f8DEuC16RNaKY1qs9aGp0gc34rUXzNp4S6ypSeAUVNsYXg/dxMHDtxsH/HIDRE2esjlFNsymMHF10UmCGBQb3JebsoqUAPcn5FSjSyCQm4pCBy36jlXlv5skVv4Rf72QVzWcA0pHraEPltPS7FV563Ky5ZLcTYPKjTq02zjoZJENUMg47Gds5vVyy9WyHarRy8xNJ/aUKjAu1SQtWZLcG802d7tHQRo/WulK9ItzGvmOaUmWg8j5U38h4fqGOMBL0TKpvJHxHwEsEQmiPYb/XB94oMuKjYJEVIRgog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sorenson.com; dmarc=pass action=none header.from=sorenson.com; dkim=pass header.d=sorenson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sorenson.onmicrosoft.com; s=selector2-sorenson-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RqT2pYwXJJKK9lH20ZllLfTr9blXTdfXbWKBC43EmOo=; b=IFuaSLkB4Ki8yE6Lapx1/lLsQ1awLR4tfzHuIdEUmmTmT+YGIctwnfXAM0AIfWFglZmhhMiYw/V2kkxeshmnMdQFysaCatrJ0I7nqCBlaqsx18559NUJDQHfOHanQYoXCSrFjUWE1SSB0XWZtjI10mcn6EBTmjY8EgvvGdeCvbM= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BY5PR04MB6549.namprd04.prod.outlook.com (2603:10b6:a03:1d2::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Wed, 30 Sep 2020 22:30:20 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::65fc:6562:3ada:465c]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::65fc:6562:3ada:465c%7]) with mapi id 15.20.3412.029; Wed, 30 Sep 2020 22:30:20 +0000 From: Eugene Christensen To: "rum@ietf.org" Thread-Topic: [Rum] [EXT] RUM security model Thread-Index: AQHWlnxQD9PXpaMUFE6N0jV2IR9mp6mBxBhg Date: Wed, 30 Sep 2020 22:30:20 +0000 Message-ID: References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <3757_1601140882_5F6F7891_3757_32_1_a4a62f53-1571-56ec-35b9-7faecd4fa480@alum.mit.edu> <927a8854-51b9-c768-ee1e-5d0c4b76a45f@alum.mit.edu> In-Reply-To: <927a8854-51b9-c768-ee1e-5d0c4b76a45f@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=sorenson.com; x-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 45a76d36-6622-4711-c1ec-08d865906a57 x-ms-traffictypediagnostic: BY5PR04MB6549: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1uCQevCask6tMP1JmZS0FsTwrqKH+2Y2uNMPqtyXl5OuaWedWlIlWrXEe3E/XVOmwaFaXLGgiFvykPXqdeuyns0biMfXQXZyW+mvZjptVOBV5dA1XGkjaIANhhW1f3/Sxji/JMdaPvTnZe10J2QeESiJA8RMrVaSG/SgWPChXPU5vuC5lejYfb2V7+0LITxG7JBeT7KlibyeR5IDrKkVVeNmt5U249lYU+VY7Qwu+ZOEMyORi95khuWThjoBASPOxiNENkPqdM9Fi91Iornf0bv7asnMI1O/EuwHYS1Yrh86bEF64m3j2JtbjLGRDw7jO6kreH6w8sv37ZwH7UVqMZmXarouvX15Dc7bU2R47kOs92tDZ5r1QqLFIEPJrDrk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4983.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(136003)(346002)(39850400004)(366004)(66476007)(52536014)(76116006)(8936002)(64756008)(66556008)(66446008)(66946007)(5660300002)(33656002)(15650500001)(26005)(71200400001)(55016002)(186003)(7696005)(6506007)(6916009)(2906002)(478600001)(316002)(86362001)(9686003)(8676002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: rLjhKljmpg2a/9zzIRH9VqgZ2VVKqovAxO8Q5Hcd2QX8oPU7jF49KSNHteGdU2IknjoleK+R8U2vfX5RPzmnrBRQ1K9FudthRDax63Gjxtm6FZVrtHrBsKUF4IVlK+JbjniMQ4GgqAUPYK7SCXQ7X5QMo92l37ea/yCtKKkB8nRclPDDRtqDh6bzZVeUn3/fgVF7xCY6KJggLCMd/dRE8R7riUvdqkBjn9jdoB2FhFLhws8cm3s+vRv3A4g8p30+inbjDe2YTt5WEz3A9oz1DXff8OMBqZD7r0HKl9lR52KJ/gsAtiH39P/QEjFrTxc/o1xzRCkgy+mtap2YBn/a2Rhe9uWZgqJDWjLXtowHvEGEp+/gTV6mQHsioh1fqm4iTpTMSugqeXkWViXoDgLN7I4e3O2V1SUM5xEEeRVx5Tp38Y6opoQjS8AmjcJak0c1TXrsqMydNl0Qf8MyzkxISvejeQbRfeWK5ual310Jyn1h0q4/j7lN6pJ3G1SShZ6YyME6B1rgt+gfpOD9KulcRb7xBVVdhFHr7HMzpbV7LZpdwRXP0DexdL7MqyEq3/JqUPavEQgQr+/PKPllwPd+jWsp5ydLcX2OQcs6sn1ukIyK9X37iJ3O4jbp7H/r9Yp7nqkOMDw7cRkOgvEcPYUANA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR04MB4983.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45a76d36-6622-4711-c1ec-08d865906a57 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2020 22:30:20.5178 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b03ef08-a104-48c4-a951-f18d295428d5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: no+2bEzuAg848Awc/+mI8LbnxYfLgktlpBMP8XkXaLS5iM610LNpuU/9vThIgqweDpDCw80OAqZbafu7wOUfoUvlcb5x0oXQC4brCppG7g4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR04MB6549 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 22:30:25 -0000 Thanks for considering how we might implement this security mechanism. May= I add my voice that it is essential that we find an option for providing t= his desired security, whatever it is. It could be detrimental to the VRS p= roviders to have UAs out there, with the ability to register with VRS provi= ders without first being fully vetted. It is our practice anytime we make = updates to our UAs to test how they work with our UAS before we ever releas= e the new UA software into our production environment. We only want UAs re= gistering that have undergone this rigorous testing with our systems and th= en only with users which we have awareness of. Thanks,=20 Eugene Christensen CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain confidential and pr= oprietary information. If you are not the intended recipient, or a person r= esponsible for delivering it to the intended recipient, you are hereby noti= fied that any disclosure, copying, distribution or use of any of the inform= ation contained in or attached to this message is STRICTLY PROHIBITED. If y= ou have received this transmission in error, please immediately notify me b= y reply e-mail at echristensen@sorenson.com or by telephone at +1 (801) 287= -9419, and destroy the original transmission and its attachments without re= ading them or saving them to disk. From nobody Wed Sep 30 16:47:04 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6EE3A0D7A for ; Wed, 30 Sep 2020 16:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 OGDPwCf7fWJe for ; Wed, 30 Sep 2020 16:47:00 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 696923A0D3D for ; Wed, 30 Sep 2020 16:47:00 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id o5so3461401qke.12 for ; Wed, 30 Sep 2020 16:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fv10FekwL4epxS9orHKyH9qfNqxglJcUM/ly/8c3w+4=; b=qahYC3EdihPFNv/Ur5B/vtoQ9Ts8lxyQRvE4rvkVC36QGOvYJ+6FENK1DFsBn4MrcG AOu4tj5AXqpzvpLqn2VNDvJFg7wqGI0M97KS+EvZPl6RP6y/iAPjtunnmi1JGlhjeu59 WMBaij9w48zkBpeOx8CToR0G68SjAQcd/1n6VcdfK6dY2f4dQS0gDr2vS44qBkT8xdK/ cpWCm615v/k0MnMIPQcnlPQochqoW/zakRN95PysJqNhYdPYkiZJGTKEfH2BdYPg5C78 kL3VGeWcfte4ktn1a2grHyMgd6B+P1HNAe6Qlravfx+sUhutAuUHVS5ENDKDGYWPZKnC ILdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fv10FekwL4epxS9orHKyH9qfNqxglJcUM/ly/8c3w+4=; b=JtoXOeGuhTIu8jHsfsZ8MX7u/o9XKeT90nSADv24rQc8B7RzG62ANUatJ6VfD4jXkc jAIzUyvQtLUseAsGK4LwpYhO/0i90DspEyVWhuxnoebGFr7oy5g9F2S5XgRfDSaB9R9B wotH8gCpcgmyp0F+hJOycDSkuWo7/sk692YHfbmpdYzdnW8BTmKONNZsrgg1EKPW5b8f NYKvpBbn2Bihgm3BcGe6/qTXMBj+HzD7UzYeRE3YDGROiyzh+Lj/FXIWU03StZSqirQQ ZTunAZOpF8mlL8LoBePtujXHfky3g/antq8uB4gJPBSoa4IkcpKwyRWai3OyXbTxHdJY sQNQ== X-Gm-Message-State: AOAM53171TMTWqZhVQE26VXzCtWrDalvv1i2Lqp/hjW20GRE7UYOFJhw oYfdnAOBf8duRrObGLJQSVIm/5tzaACbqRlnGS5DURcDbXglnw== X-Google-Smtp-Source: ABdhPJyuHKj0PJ5khyErRiExHBjVQnVA2Xeru0cibHrwqUumgJn5PvGvhoRp4yeJW4jT/VGAtvtVRRtls/5cHtEKvVI= X-Received: by 2002:a37:6892:: with SMTP id d140mr4959620qkc.58.1601509619337; Wed, 30 Sep 2020 16:46:59 -0700 (PDT) MIME-Version: 1.0 References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <3757_1601140882_5F6F7891_3757_32_1_a4a62f53-1571-56ec-35b9-7faecd4fa480@alum.mit.edu> <927a8854-51b9-c768-ee1e-5d0c4b76a45f@alum.mit.edu> In-Reply-To: From: Brian Rosen Date: Wed, 30 Sep 2020 19:46:48 -0400 Message-ID: To: Eugene Christensen Cc: "rum@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f720c305b09083e9" Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 23:47:03 -0000 --000000000000f720c305b09083e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we understand why you want it. What we don=E2=80=99t understand is = what mechanism would provide it. I am generally aware of this class of problem and I=E2=80=99m not aware of a solution that will work. So what we need is= a suggested mechanism that provides the assurance you want that is technically sound. Brian On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen < echristensen@sorenson.com> wrote: > Thanks for considering how we might implement this security mechanism. > May I add my voice that it is essential that we find an option for > providing this desired security, whatever it is. It could be detrimental > to the VRS providers to have UAs out there, with the ability to register > with VRS providers without first being fully vetted. It is our practice > anytime we make updates to our UAs to test how they work with our UAS > before we ever release the new UA software into our production > environment. We only want UAs registering that have undergone this > rigorous testing with our systems and then only with users which we have > awareness of. > > > > Thanks, > > Eugene Christensen > > > > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, file= s > or previous e-mail messages attached to it, may contain confidential and > proprietary information. If you are not the intended recipient, or a pers= on > responsible for delivering it to the intended recipient, you are hereby > notified that any disclosure, copying, distribution or use of any of the > information contained in or attached to this message is STRICTLY > PROHIBITED. If you have received this transmission in error, please > immediately notify me by reply e-mail at echristensen@sorenson.com or by > telephone at +1 (801) 287-9419, and destroy the original transmission and > its attachments without reading them or saving them to disk. > > > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > --000000000000f720c305b09083e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we understand why you want it. What we don=E2=80= =99t understand is what mechanism would provide it. I am generally aware of= this class of problem and I=E2=80=99m not aware of a solution that will wo= rk.=C2=A0 So what we need is a suggested mechanism that provides the assura= nce you want that is technically sound.=C2=A0

Brian

On Wed, Sep 30, 2020 at 6:30 PM Eugene Chri= stensen <echristensen@soren= son.com> wrote:
Thanks for c= onsidering how we might implement this security mechanism.=C2=A0 May I add = my voice that it is essential that we find an option for providing this des= ired security, whatever it is.=C2=A0 It could be detrimental to the VRS pro= viders to have UAs out there, with the ability to register with VRS provide= rs without first being fully vetted.=C2=A0 It is our practice anytime we ma= ke updates to our UAs to test how they work with our UAS before we ever rel= ease the new UA software into our production environment.=C2=A0 We only wan= t UAs registering that have undergone this rigorous testing with our system= s and then only with users which we have awareness of.



Thank= s,

Eugene Christensen



CONFIDENTIALITY NOTICE. This e= -mail transmission, and any documents, files or previous e-mail messages at= tached to it, may contain confidential and proprietary information. If you = are not the intended recipient, or a person responsible for delivering it t= o the intended recipient, you are hereby notified that any disclosure, copy= ing, distribution or use of any of the information contained in or attached= to this message is STRICTLY PROHIBITED. If you have received this transmis= sion in error, please immediately notify me by reply e-mail at echristensen@sorenson.co= m or by telephone at +1 (801) 287-9419, and destroy the original transm= ission and its attachments without reading them or saving them to disk.
=


--

Rum mailing list

Rum@ietf.org

https://www.i= etf.org/mailman/listinfo/rum

--000000000000f720c305b09083e9--