From nobody Tue Nov 3 12:25:50 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 729963A1136 for ; Tue, 3 Nov 2020 12:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 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.247, 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 idjU_i-4Pd9B for ; Tue, 3 Nov 2020 12:25:46 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2077.outbound.protection.outlook.com [40.107.243.77]) (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 9BD4C3A1135 for ; Tue, 3 Nov 2020 12:25:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZGacNrklOGlrnE7IzoVmL4Wxl44yg3imh1VqHQKZO2uNCxICkA1XAwtSIEKZCax0ZzfyKD677MQut4YUv7N84GYK/zLVVHwKHlWztDXi9TZEeorQt8/FDFyDpKq838yeaK3xnc4mV9XR9m0HfWGsCMN0nMU7myRF3KOYsOyU+Gc9n0dqd4QiCdBVVJ0tuxGeY0smzvfPtlMVw1xGKEbnyP+kWRpmvRZ4WQhBtYc+Y+QDsT5gG5FNf5wQ+wRcv64VKo1b+nVqJ1Z8KTGmXaIBEYpgaZRJqoSeVP2D/uqo/YpfIjU7HMLi/kldvSpcAx3kpRPK4SHzpkL0zLDhH5KmTw== 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=4fi9TRNbagRr+7q/JONa+paMuC3gqE23esYq12QeuJM=; b=lGtbuMOPEoPrSEiGV5ArGpq/rGd6EspdskOzPS4NLmr+S5zUWYrTma9XkL0bndSGUJrrDSxvsE4g3kOtmOnfGnj9ag7L5HnB7Co+3ks4TyRRgC7oUcNMgmnU/CV4zj1A/IhuKcU2PaW5NtjiakgI2jAaa4ssjla3dfcmLyTWvioK0C7Dq37xVDl5MW4KY6X/jBiC61njs8iU82h+4lLFlId5Kiw9GN5Vnuhqv3dp4+wfOOmalKyAbpmOLXU7cMkNQxYyDaMFlQBfWzLb1v0AeN5KWC5J3fxDmv8tuuOcpCTckuzgWLFqLdfIrmcenVyy25mOOU9Qx7LVGk7MBbXNQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=sorenson.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4fi9TRNbagRr+7q/JONa+paMuC3gqE23esYq12QeuJM=; b=F5HfW3IwI1M76G6FW2erELd6o+6fuIBQNFX1o3QuHKmnzftkPpklj4HrRS4ZajOFUv59kw1yfqlw5B2JjxJKeZZSx2O60Dq47w0dnL43fuC7fesacOTafC8+l6NO65PsuyDTsf1OTBcKvrW1Eo8DEQ6Tx50cC8gSm0WWq8YInsE= Received: from MN2PR10CA0006.namprd10.prod.outlook.com (2603:10b6:208:120::19) by BN8PR12MB3586.namprd12.prod.outlook.com (2603:10b6:408:47::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.27; Tue, 3 Nov 2020 20:25:44 +0000 Received: from BL2NAM02FT023.eop-nam02.prod.protection.outlook.com (2603:10b6:208:120::4) by MN2PR10CA0006.outlook.office365.com (2603:10b6:208:120::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Tue, 3 Nov 2020 20:25:44 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; sorenson.com; dkim=none (message not signed) header.d=none;sorenson.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT023.mail.protection.outlook.com (10.152.77.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3520.15 via Frontend Transport; Tue, 3 Nov 2020 20:25:43 +0000 Received: from PaulKyzivatsMBP.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 0A3KPeCG021470 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 3 Nov 2020 15:25:41 -0500 To: Eugene Christensen , "Olle E. Johansson" , Brian Rosen Cc: "rum@ietf.org" References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> <38090A50-6572-4A8E-97D4-C260323365AE@brianrosen.net> From: Paul Kyzivat Message-ID: <90279636-259e-8ff6-7e28-406a84ddeccc@alum.mit.edu> Date: Tue, 3 Nov 2020 15:25:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 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: b8843d5f-0e02-4cd7-f7c3-08d88036a3cf X-MS-TrafficTypeDiagnostic: BN8PR12MB3586: 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: 2QflQXNiG/wt4sA0coN4HZi/rMR4V8B6FFk5ozB/RkHRF5p0SqoHLvs6V2fXKDp1TSDGSb6vXpQFex2FJnTqA9lXPO0vzwaXgBrE2JlD8q+u1qC++1lzAHIDOWx9SMrPRmAc3OOq5gT0IbkTYWL7rMjMhmd8oM1ec2V7EQ6sAIo23ajl8jWygEhe8W4QUlURFRwMdbjjkY5kCWua2lI5lGSPfhfLgeLI0OBgenIQeqRAINJQBoBD6MDGpPV2V7Kkqz9LJ8U6syYJ6W/z4ByfGh8Nz6/YeuKxfM+wpQlScRF1vaPpqqlqiLWCpxx8Yl9+zMX9fsUJBjlMCMoaoWxarYMibeeeLrEymZ883SaAoNBKU/6R4AB+AESSV/OtmBpdDwWomsU6j6BBAPHEU43oaz978gKhYNlXwL6sj2vST11bsL3V9Vf9JA1zSvpgUm+D 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)(396003)(346002)(376002)(46966005)(356005)(2616005)(956004)(31686004)(83380400001)(31696002)(47076004)(2906002)(66574015)(82740400003)(86362001)(786003)(110136005)(478600001)(186003)(26005)(336012)(316002)(15650500001)(70586007)(8936002)(36906005)(75432002)(4326008)(53546011)(5660300002)(70206006)(7596003)(82310400003)(8676002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2020 20:25:43.7230 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b8843d5f-0e02-4cd7-f7c3-08d88036a3cf 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: BL2NAM02FT023.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3586 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, 03 Nov 2020 20:25:48 -0000 Eugene, On 10/30/20 5:40 PM, Eugene Christensen wrote: > There has to be some amount of trust between the providers so I think we should consider the use of an API key for access to the provider's configuration service. If an API key is given and another provider abuses that, it obviously could result in something bad but it could quickly be revoked by the provider; right? And the company that has abused it will likely not be trusted in the future (motivation for maintaining trust). It depends on how key management works. Does each device/app need to test with each provider and receive a separate key from each provider? Or does the testing happen with some testing organization who then provides a key that all providers accept? The logistics of testing and revocation differ in these cases. > Would it also be wise to use a client certificate for SIP communications once the RUE has the necessary info from the configuration service? The client certificate could be embedded into the application. From a practical perspective I think we need to authenticate using a password at some point. (Just due to logistics of bootstrapping and identifying the human user. Perhaps only for the config service.) Or perhaps could use OAuth to authenticate using Facebook/Google/... From there it might make sense to provide certs for subsequent use. > Is there any reason we cannot use language that makes the use of the API key and client certificate optional, at the discretion of the provider? (e.g. The providers MAY require an API key for their configuration service and/or a client certificate for SIP communications). Possibly. The devil is in the details here. Thanks, Paul > Thanks, > > Eugene. > > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person 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. > > -----Original Message----- > From: Paul Kyzivat > Sent: Thursday, October 22, 2020 9:34 AM > To: Olle E. Johansson ; Brian Rosen > Cc: Eugene Christensen ; rum@ietf.org > Subject: Re: [Rum] [EXT] RUM security model > > [EXTERNAL] > > On 10/22/20 2:29 AM, Olle E. Johansson wrote: > > [snip] > >>> Brute force and DDoS attacks can’t be addressed by this document except in the Security Consideration section. They are implementation issues. >> If there are specific attack vectors to RUM that doesn’t apply to SIP implementations in general, yes. > > AFAIK there should be nothing special about VRS that makes it any more vulnerable to attack than any other sip service accessed over the public internet. > > I'd like to hear from the providers if I am wrong about this. > > Thanks, > Paul > From nobody Tue Nov 3 12:34:17 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 D46E73A1139 for ; Tue, 3 Nov 2020 12:34:15 -0800 (PST) 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 PFXazeRFDl5y for ; Tue, 3 Nov 2020 12:34:14 -0800 (PST) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 F35093A1138 for ; Tue, 3 Nov 2020 12:34:13 -0800 (PST) Received: by mail-qv1-xf32.google.com with SMTP id g13so8580484qvu.1 for ; Tue, 03 Nov 2020 12:34:13 -0800 (PST) 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=8j7JqFFa0+hhNT1Vgudtxuxo6RS69N5rvBUT1Ox9OzM=; b=zl5RAEA1UKrw7Delnmifflg+P58nIQ0zYPmBivCwiblpPSuWpq0e63vq1VVzn2wfMD X2XKKchjWVMh8Kt+SneG+VeBCxuMnkG03FWUOQvFM9S7+IChUFaU9uFGl2XiDOW+hn3z kCtjXQ66vGiuCJQ1k+fraGoqC8ntEWkoLC9JGp90wD5dG92IO534S/dnWLjaH68h6rbW gvLoXFqR1JWjIC75kuHtu+wa9xgX4vp9JXLRgnm4L1E4yY1sP3Oq/2D8Skf8IVHAKEBr aGRSGEXA/bHNgoteyr5xWEZxZNSozkbUgktRrLeA3ahlMQo9BKXjv+229b36yjogpzlj bNnA== 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=8j7JqFFa0+hhNT1Vgudtxuxo6RS69N5rvBUT1Ox9OzM=; b=XTiu10Y+vFxVgU82zSbqeuB7p7mRFeAoBYulT6qh/xZ5z+s3GoLazN/Tm75Leg4J7u u6J4nMGWvWIe41bzqNvqPYMJVEUfmCsgWFNqzy1SJ02j9K2Gbux1Jg8z1dCD7E7FLG+/ YO/A1KkvL4WFIRD9JxSP+9dDORld+lY+4PUfiZ5rMIQfd+qWmuAANbipXD9mS64tuVd2 85uf3bGRqw9PbSEBRgabSN1JJrbJSkxHJI6fwsgsVhDNXawYzTQWfPycUi0RpDyvCroO b3OWtLM++9yH0bGmZ2ZQPur33HOjCnXWu7qq1S8D08j31Sz+5ljNucfyc5NQ6aJji2+c JGvg== X-Gm-Message-State: AOAM531ZZwUa2fJxjvywxV0qE4FZyKTbs7LC1kylbTKzC/gxM+Pe7DBE 8Vv1IgZW1qwzA/PalkHG2bnt0w== X-Google-Smtp-Source: ABdhPJyzeCNH03jacm5HLiCNkl6UruVceJYWW7iCji89U/AK4fEwmAxzb9SmUHUaFIZ/wwWk+CPpYg== X-Received: by 2002:a0c:a2a6:: with SMTP id g35mr28470277qva.4.1604435652848; Tue, 03 Nov 2020 12:34:12 -0800 (PST) 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 m26sm11565118qka.118.2020.11.03.12.34.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2020 12:34:12 -0800 (PST) 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: <90279636-259e-8ff6-7e28-406a84ddeccc@alum.mit.edu> Date: Tue, 3 Nov 2020 15:34:09 -0500 Cc: Eugene Christensen , "Olle E. Johansson" , "rum@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1EE964DF-3F07-4F36-83C2-7B27068B434F@brianrosen.net> References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> <38090A50-6572-4A8E-97D4-C260323365AE@brianrosen.net> <90279636-259e-8ff6-7e28-406a84ddeccc@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.1) 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, 03 Nov 2020 20:34:16 -0000 Classic API Keys don=E2=80=99t depend on user sign in: it=E2=80=99s = built into the code. In terms of our spec, all we would need is the = mechanism to send the code, and we wouldn=E2=80=99t deal with how the = code developer got the key. Classically, it=E2=80=99s sent in some = initial transaction after TLS is established, so the key can=E2=80=99t = be observed. If API Key=E2=80=99s are a satisfactory (to providers) way of = controlling what implementations are allowed access, we can discuss = mechanism and I=E2=80=99ll write text. I think the fundamental question is do we want a SIP mechanism (which = means TCP/TLS signaling) or an HTTP mechanism? We could tie it to the = retrieval of the config file if that is per-provider, which would be an = HTTP mechanism, or we could include it in, say, a Call-Info header on a = SIP REGISTER if that was TLS protected. Brian > On Nov 3, 2020, at 3:25 PM, Paul Kyzivat = wrote: >=20 > Eugene, >=20 > On 10/30/20 5:40 PM, Eugene Christensen wrote: >> There has to be some amount of trust between the providers so I think = we should consider the use of an API key for access to the provider's = configuration service. If an API key is given and another provider = abuses that, it obviously could result in something bad but it could = quickly be revoked by the provider; right? And the company that has = abused it will likely not be trusted in the future (motivation for = maintaining trust). >=20 > It depends on how key management works. Does each device/app need to = test with each provider and receive a separate key from each provider? > Or does the testing happen with some testing organization who then = provides a key that all providers accept? >=20 > The logistics of testing and revocation differ in these cases. >=20 >> Would it also be wise to use a client certificate for SIP = communications once the RUE has the necessary info from the = configuration service? The client certificate could be embedded into = the application. >=20 > =46rom a practical perspective I think we need to authenticate using a = password at some point. (Just due to logistics of bootstrapping and = identifying the human user. Perhaps only for the config service.) Or = perhaps could use OAuth to authenticate using Facebook/Google/... >=20 > =46rom there it might make sense to provide certs for subsequent use. >=20 >> Is there any reason we cannot use language that makes the use of the = API key and client certificate optional, at the discretion of the = provider? (e.g. The providers MAY require an API key for their = configuration service and/or a client certificate for SIP = communications). >=20 > Possibly. The devil is in the details here. >=20 > Thanks, > Paul >=20 >> Thanks, >> Eugene. >> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person 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. >> -----Original Message----- >> From: Paul Kyzivat >> Sent: Thursday, October 22, 2020 9:34 AM >> To: Olle E. Johansson ; Brian Rosen = >> Cc: Eugene Christensen ; rum@ietf.org >> Subject: Re: [Rum] [EXT] RUM security model >> [EXTERNAL] >> On 10/22/20 2:29 AM, Olle E. Johansson wrote: >> [snip] >>>> Brute force and DDoS attacks can=E2=80=99t be addressed by this = document except in the Security Consideration section. They are = implementation issues. >>> If there are specific attack vectors to RUM that doesn=E2=80=99t = apply to SIP implementations in general, yes. >> AFAIK there should be nothing special about VRS that makes it any = more vulnerable to attack than any other sip service accessed over the = public internet. >> I'd like to hear from the providers if I am wrong about this. >> Thanks, >> Paul >=20 From nobody Mon Nov 9 07:34: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 EB1DB3A113A for ; Mon, 9 Nov 2020 07:34:38 -0800 (PST) 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 IrXuGKI9CXMS for ; Mon, 9 Nov 2020 07:34:37 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2059.outbound.protection.outlook.com [40.107.92.59]) (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 3C61B3A113C for ; Mon, 9 Nov 2020 07:34:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jUf9dKZ6tnOx42HLujwJXgX37YiUWGWtayw+qg5hJrfYHq0ZvBK4bYbpuYUFgDDvC+ivVGwrof8m95tODp+68IMpZebINTocau7zc3D1jetGP0umRebPEb9NECGKLjCpDBS4Klm3GMy5HgJ8Mvy7IB7h3BBfhDllMhL0CWZZMSDwC38xZpb3icUQanMwr0bEis8Gdd9H8wVevuzhoHJh3jbpUmaOSCG/h+pxJQe1g5pciB3nIrOBn5kV49GkmyR9bh4y4fO4U4/DumvaQkkjo+gMFIM4MP3M9g5CJ2r0sjsUuXTMyZQWQ0KfUzJA97NVjI3sbFVqyYIzNBXA+29n5Q== 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=7V4e+m/jviEARc4Q8iIRLVc41zd+y8ygjiJMedlxlIA=; b=k+0j6J5qZzzGKDhCJYOCyXy6bv03z5xQ4vS8D8oJV/HmqPKZPHEC/7VcwwEnv6Q5J9usprJfxs43wKT1K6U0iLDIK/NgNnC/2E+5QvwIdJeipJfjENGW+M43ipJNipMTNybrH2f1NGm2Sdj6wC9gqxCihabdf2oJpwXDQlfMb+P6LCEeMmh3HvbNTUnEfn9L0P4nBRYxYiktcvvxA3ijRTLslSSCbB++92N3YVNIU91Hi9CyIwHyADIj60byNzIVDi/DVoISZXaeo7UdGfJHrkjYBEVcyytzuuX2Y1+QKtPxnrSLdycFQhNNmFmS+nVzhNqshCF09nxspT5MkNHHvg== 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=7V4e+m/jviEARc4Q8iIRLVc41zd+y8ygjiJMedlxlIA=; b=ARN4Ktt7xW21Lx/c930jsCMJIkAUVAdNYtNpWxJ8mAYu4n4S9nyjTFOu18IWBtEuSHlKe3tmqOKw0Yrbv5lVxqQ+WMWdTiWXSK8E8ySUV6dQXyxDXvEyTtmrjHyhxqFCDmvfCAzVrExjLufo/UhaTNKe60iEXiNFOSfQkHeufXA= Received: from CY4PR21CA0036.namprd21.prod.outlook.com (2603:10b6:903:12b::22) by SN1PR12MB2368.namprd12.prod.outlook.com (2603:10b6:802:32::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Mon, 9 Nov 2020 15:34:35 +0000 Received: from CY1NAM02FT018.eop-nam02.prod.protection.outlook.com (2603:10b6:903:12b:cafe::2b) by CY4PR21CA0036.outlook.office365.com (2603:10b6:903:12b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.6 via Frontend Transport; Mon, 9 Nov 2020 15:34:35 +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 CY1NAM02FT018.mail.protection.outlook.com (10.152.75.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.17 via Frontend Transport; Mon, 9 Nov 2020 15:34:34 +0000 Received: from PaulKyzivatsMBP.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 0A9FYWe4021669 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 9 Nov 2020 10:34:33 -0500 To: "rum@ietf.org" From: Paul Kyzivat Message-ID: Date: Mon, 9 Nov 2020 10:34:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 MIME-Version: 1.0 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: cb92e632-ef92-40b8-d2f2-08d884c4f60c X-MS-TrafficTypeDiagnostic: SN1PR12MB2368: 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: i+kgZcb6zeVGZdDDGF0amrxR9iTaU4qWk5F2GNu9UDG+TP3MokM8w/bbeFeXsSpV2xd2X7obI6WhgRFbuJwoLEj6oEsabRgBNqJrHXtMMW4feM5Uzojc6hz57XXeInJ2lZo6S/HH/awCKkMsZd093ZapBWlzudwktK6DZcJ4ZN6CX7c+YJRo5k9gVpw1Skk4mBLJKaokHHuqkYaeMUFZn3L9Njd9Gsx/Afu03B4pzhY5itZZvEXxTi2zfCoM9TMchxBCFO2mz962uX/WzpLybp062Ex3Ilj2rd3tSS5uTaJYMHJPFGbnl7Udwdi2sgUwFPBiGVNLqxE10gLh0Y9o6OOqgCJvvXRyP9YzawfWkyywvcZfblw1JTptphKLxWZjUFTOUmPPrNPAJK4Si3ah0tvVwSsFgEs5MsbRv04t1hy0ofuoFZebqoxjkaruFY+r 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)(346002)(39860400002)(376002)(46966005)(7596003)(86362001)(70586007)(47076004)(478600001)(956004)(2906002)(75432002)(6916009)(356005)(8676002)(70206006)(336012)(2616005)(8936002)(82310400003)(82740400003)(31696002)(186003)(36906005)(26005)(316002)(786003)(5660300002)(31686004)(4744005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2020 15:34:34.7518 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cb92e632-ef92-40b8-d2f2-08d884c4f60c 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: CY1NAM02FT018.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR12MB2368 Archived-At: Subject: [Rum] POLL: RUM session at IETF 109 virtual meeting 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, 09 Nov 2020 15:34:39 -0000 To those interested in RUM: We currently have a RUM session scheduled during the IETF 109 virtual meeting. The time slot is Wednesday Nov 18 at 2:30 AM EST. (Yes, *AM*. The meeting is rooted in Singapore time.) *** Please reply if you intend to attend/participate in this session. (Note that you need to register for IETF 109 to attend, either for the week or for a day.) If you do NOT intend to attend, but would attend a session under different circumstances, please respond and indicate under what circumstances you would attend. Thanks, Paul From nobody Mon Nov 9 08:13:49 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 B78D93A11E2 for ; Mon, 9 Nov 2020 08:13:41 -0800 (PST) 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 xZ5iAX2Kelju for ; Mon, 9 Nov 2020 08:13:39 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2067.outbound.protection.outlook.com [40.107.223.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 8CF893A1235 for ; Mon, 9 Nov 2020 08:13:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cTBkYGqekvh8yZK1NWrLmH7GoiWlt9wMoEXMuYoKeroKeKOc8nerc2FUns2TTQ1D5c3XCJMWgtVNVrxPWIovxqaBY1YxxdxwfsLzmVEBjerKzb2OiDx1RuRie0ZW654XjhbreZEOHt/olGmEgqgx2GEaJRLZBs05EOqMuOAGiHGozG/H3I8dLGx98Ub9YoUo48lmfUWdjKJA9TpCInl+xMYtQFWwpkhvCG1QyQGsYsuRUelvwpWl33WcGzal2w2ywsK95T7utk1dMVfl4tYqD0XI3qnLRiXIjFX5SBwbggz5eQ0MHkm2oXKffxTbzKMBh+1CtV+v4nXH/8v8vhnp6Q== 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=XxmuEP+x6gcd6ngYPNsCpVktAVdgX+A/kFdijwk04AU=; b=F47lC9L0k8G4l9rwv5cHAisLnvpVZWU8qqxwuvqztg3Vog9etaOfcuz5yd/pwBKdPKiwXw6J8mJ737WC2jlgxkdfXLFMjr6zqHwfB8MmyiP/jwC4+Mcl2j3FBnYEd+78ywsOwDCYU/ODrn0gU/IDjmb6csa6w3dPvulodRISRRKRGKdWSt+Gagc/IDtuY7is3Spi/pzoMTA2a1OqAmI7ReDKwElPMjjCRSNvJ6V53Wa2OdY/Pz0P+5Hq64Ueqc5Vxg+aSf49wSGKJtLQXTKi7T7CnJVOtPRMMgZd/+dUkjQq2lXxaIhQd6tWPaLI43K84lK+/rGirgFIxOey5jJEjA== 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=XxmuEP+x6gcd6ngYPNsCpVktAVdgX+A/kFdijwk04AU=; b=Vj+fwDaSMhjQGtB9FumZS7WlX0f0KRaGprledtX2BJtxwuRTRjZYbP14RaqLQLi2kO8WZab7fVgBdlWPfa9QFWM4ANjL9lUzTm/rfv6mnfSEkKVU0DtDZAVswcEFYkbZUeLDhyqcdbw/NgupBFGFW52O8VLsNYpB3SV8j+qoHw0= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BY5PR04MB6642.namprd04.prod.outlook.com (2603:10b6:a03:21b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Mon, 9 Nov 2020 16:13:35 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1%7]) with mapi id 15.20.3541.022; Mon, 9 Nov 2020 16:13:35 +0000 From: Eugene Christensen To: Paul Kyzivat , "rum@ietf.org" Thread-Topic: [Rum] POLL: RUM session at IETF 109 virtual meeting Thread-Index: AQHWtq3dWiiIl5CT1UiQa3U52bNPOKm/+PEQ Date: Mon, 9 Nov 2020 16:13:34 +0000 Message-ID: References: In-Reply-To: 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=sorenson.com; x-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f536b83a-c014-431c-395b-08d884ca68e1 x-ms-traffictypediagnostic: BY5PR04MB6642: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6cD13/uaRBQjwxh9uXpL5hcdyBe+kpe+dehmSPmRCqA1GfJtcki27q/B+FTAZjvfjrArRPYBkl15EbczdaqSORDIV2aDbuU7XCjlzqINhMgqnLE4JFqjL+RC9r+fA/qqM5YfIh+czdA7BZgG4UPHFxg1SShTnqMgE3OlMl+/qES3FE6jLxOOw61q2lPbr1SyFXX/Bg88YSZvc3TLOTFMHBKKO3GxLi0aLhT7S8RBXDxMbI13zQs7ITzU1zzspJdkZeKg+tI+DSUVNfdEL2bxeClimPgm0YEROFpT3YYiXIayFbjTigNj9ft3IjahSdP5/ZbRpw6LRFCUzsUhdwBvTs/YoSL1Ig3wLK8xtPxT2WwX2i7oamht0hKx37VAWMCoCXzFKd9GFAfx4vOt009wFQ== 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:(346002)(136003)(39850400004)(376002)(396003)(366004)(66476007)(66556008)(64756008)(66446008)(33656002)(76116006)(66946007)(53546011)(7696005)(110136005)(316002)(86362001)(5660300002)(8676002)(52536014)(8936002)(186003)(26005)(6506007)(478600001)(9686003)(83380400001)(55016002)(2906002)(966005)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: yu0SaJcmotwQTNObTaDxMypfcjA7ejG0IS9KB3rndlwDvYkc5Eq7iGdhR4ETxjx9tsDr2c7fnPTVtH/+KdlFd5fhVLqf4AWjXj9srnZq8GjK+cy9Fn0oAQiJuYmp9tve1R1b9axLBMNFg7LWbci8X1I2VnT5Xtz3+sV4qck/V6fXqPeuTd/KIAu89xiLlkUIu7RArf9r7HcSJqozPEvtAfXOBhSD35u3X5hKc8mCW1EQvGapyJ2YPrHmqSCKQQdzqNi52Z84yb609VDtCxmnNj2op67wlCreqkDXop9vFBDdBOcd7qGSKQr2YrZ46j7V+r+P1MORUSjPHy1GtcLE5mVSLrfJBclJMphi5mO9rFdEr4LOV3SaUJ2mOzxM5vAcg4BmxJ2HDRu1SIxMCt/VssP1Db9N0L8YybRpWK6W+PwVkFfQSxGBJ5v/FWx/PxtmFHtVMiBFHy4FpWKDKyQzsqaJgF8/6Kd1dVj8B6BNSOhobifsaRDHy80Mp4vxNMR2qOUwiS6/gj6c//9L9hV57J4Fe1IHdLfq4dan7+jAhBtA9g4ysdbicoJhz7VyoQ+mtJ3qezXLEvfTZZxtSgnnTgcodBJSjK1ld/JjVwZ1wyFRNruYfF6Mf2WWnzg9UUhpoUz3ksTMaGNHhFcXzGMo6xUtQwiRTISPmqGhA8tVGmCcb8Fn7WAe/mTupJ7gKmYnZM+XqToxmdB+KKar0/vPudsdjRWqkx82eCdrr4X2VzXYy+VCW7peD+AWo/c7IUSusMVSqDjNNVxIs7yQom4MF0dGtINWNTgao4aLf8HSWVlorTwaNTfVH1mXWES6gjzB+tYjUseD8B2smPhpfSHWisDZaDp93wbX5GxJ1TshXTrqJQcIFZFBmx0je9ZTYhNRnpAgRFqVxP5uZ4nIBH6WAg== 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: f536b83a-c014-431c-395b-08d884ca68e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 16:13:34.9336 (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: 4QgS/T43onchm5SI6wda0HkeXERFdLas7WUno8gmXDLZhtXEBGlmT6PAOb8HrapiuzNrGrq9ogO3M7YaopaUowtCtsk0R327aSdy/U2KomI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR04MB6642 Archived-At: Subject: Re: [Rum] POLL: RUM session at IETF 109 virtual meeting 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, 09 Nov 2020 16:13:47 -0000 I plan to attend. Thanks, 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. -----Original Message----- From: Rum On Behalf Of Paul Kyzivat Sent: Monday, November 9, 2020 8:35 AM To: rum@ietf.org Subject: [Rum] POLL: RUM session at IETF 109 virtual meeting [EXTERNAL]=20 To those interested in RUM: We currently have a RUM session scheduled during the IETF 109 virtual meeti= ng. The time slot is Wednesday Nov 18 at 2:30 AM EST. (Yes, *AM*.=20 The meeting is rooted in Singapore time.) *** Please reply if you intend to attend/participate in this session. (Note that you need to register for IETF 109 to attend, either for the week= or for a day.) If you do NOT intend to attend, but would attend a session under different = circumstances, please respond and indicate under what circumstances you wou= ld attend. Thanks, Paul -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Mon Nov 9 09:01:33 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 B95F23A1235 for ; Mon, 9 Nov 2020 09:01:31 -0800 (PST) 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 P-P45dZId3nB for ; Mon, 9 Nov 2020 09:01:30 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) (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 57F443A123C for ; Mon, 9 Nov 2020 09:01:25 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C1CB86C0015; Mon, 9 Nov 2020 12:01:23 -0500 (EST) Received: from smtprhmv1.mitre.org (unknown [128.29.154.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvmsrv1.mitre.org (Postfix) with ESMTPS id 050EC13A157; Mon, 9 Nov 2020 12:01:23 -0500 (EST) Received: from mwfesmtp-mgt.mitre.org (mwfesmtp-in.mitre.org [192.52.194.235]) by smtprhmv1.mitre.org (Postfix) with ESMTP id DF7AC80EAF6; Mon, 9 Nov 2020 12:01:22 -0500 (EST) Received: by mwfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4CVHMQ1JwCz3DZH4; Mon, 9 Nov 2020 17:00:59 +0000 (UTC) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02lp2104.outbound.protection.outlook.com [104.47.65.104]) by mwfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4CVHLy3D2vz3DbLk; Mon, 9 Nov 2020 17:00:58 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KICBnQBFdP4KfUDjR7Y2JcjWgR4HvS8WMcMEOyyoJqKdWF8NJLklEHM3cxOAIF0ZeOa97TORlGOL4MfFNim7h1XfvfxLvzMldatZztk+fIjR0m4Nd0gJlPQTKgI209dB6fcqU52AYb9YXxrO7zdiGZL07yLjZ/sD/KYquGHM/f1b4myqFibPYKmtOejtFcrW/5sjRNLVTCTUYqrPG8MgaNhGlhUOV/cJzCBB6mvgSxU4cl61ThAjVPQmSROFHjcchm805Y30l5r5gSlOj9dGRvVScMHfBtsVtMFMIp3rTbglJ9bDZ4HsYx0IpvpWzZWZeCtvM2qiml31xPHQ6f9GtQ== 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=x43aSXu3xMPBA7WpQkVJYRNvxq8F2RrQuH86CrvcyE4=; b=Usgrx7iEJauSnvoXS0/DcPDa2s6ubqnbPwdTVtPk5Jc73NR8nW6Tz6Cj3HDp626BVOYV/LcnRItHT5zaw2VKm2/uonWjHLWkvqXQ5aqB18BMmNmhtrnBkqMNHH0SUKuaX5/jirtbEhx3Wj8is9MrILuS4c7dqLJ6pPb46jnr1zju3AzzCyO+T8NDaPwwgjRBB+QFZUhJz0CiHRX9GG+i6tsb93SddagC52bh67TU/gQk1Qwgaima/FkhS/2YU5mXU3G2eF35XPBuIDsILvK1uyD9gldGRRhJODz8UELtmShs9FYfJ/QiL4x7Yyx3wnRHk1qAGhxhPew+PaMBuYST5A== 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 BLAPR09MB6850.namprd09.prod.outlook.com (2603:10b6:208:28a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.19; Mon, 9 Nov 2020 17:00:57 +0000 Received: from MN2PR09MB5948.namprd09.prod.outlook.com ([fe80::a5ed:2d3d:94fa:3d99]) by MN2PR09MB5948.namprd09.prod.outlook.com ([fe80::a5ed:2d3d:94fa:3d99%7]) with mapi id 15.20.3541.025; Mon, 9 Nov 2020 17:00:57 +0000 From: Jim Malloy To: "Kyzivat, Paul" , "rum@ietf.org" Thread-Topic: [EXT] [Rum] POLL: RUM session at IETF 109 virtual meeting Thread-Index: AQHWtq3lQCzOjUanqEaKPZwWLUX0r6nABdKA Date: Mon, 9 Nov 2020 17:00:57 +0000 Message-ID: References: <17398_1604936088_5FA96193_17398_506_2_e988b397-49be-60fd-5c30-eabed2597b3d@alum.mit.edu> In-Reply-To: <17398_1604936088_5FA96193_17398_506_2_e988b397-49be-60fd-5c30-eabed2597b3d@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.80.55.88] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: eaf62d8b-cd26-4c72-71d3-08d884d1071e x-ms-traffictypediagnostic: BLAPR09MB6850: x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /vI9mfPox+sOhkMT2b/t6XMp/OyF2sRdGEH6OzZr9YZhPEXTvPA3YpwyQFO5eBMrTrrVDjVJexKCL5zKuGa7KovDjO5pwv6lWT7MRIgwFWfPO6Wsq6G1sv9aaJAafi2hFXLo8BJMwJlRu7VpLEEK5TblfSwgsfcNC6kjah3bSLZZlMHwpcQxY2DeWM5IXzqg/MhvkvpKgvjfeIdA0UEwSUeI1WkF4ggUIywgqBVr8rI0+PIjnmnO3+3LfqGtD8iosHzC2BsSx8ZzcRuaSZKIzM6IKhotJtWktY/EROpQHb9Tcao8yWD2JWhmPlWyFYbJmCB09H0TikJ0viyZOrmoS8NpjnZfQE5ecnL/hqPnbHn86HvNvV+VMrDXh3Y3+7IcgHtpPdMVZjcME7G150yTeg== 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:(39860400002)(376002)(366004)(396003)(136003)(346002)(53546011)(110136005)(316002)(66446008)(55016002)(64756008)(6506007)(9686003)(66946007)(76116006)(5660300002)(71200400001)(966005)(33656002)(66556008)(2906002)(86362001)(7696005)(52536014)(8936002)(8676002)(186003)(66476007)(478600001)(26005)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: a52icIe1ZEW+1RwAC2lCHmLsNeQPcXpopwGdivTQ1DOt2l0cOcWFUaDvj2J94IMn6eZ8Nnszp2SDmtbaLiVGxSQgR2DhveWUFVvtyOw+NXbG72WliGtWLd0HQ5t/H85JIcU5/qkHu1y75BokYIGVhK3vJiF4+vjiTEsfkPM4bzUhcGKLuZOaI395wkX9yXkz9wBz7zc2Svi+PpNV6l+uJoY23Fktl4btov+5fW5/+vVu2zVHeoEEiHcpQl04bue8m1MQ0cA8pYtgfCwBscDUomMw3bdIdvJrLU5edgp4a4BNAod0D0Db7ztZhRo2zUkAofMRgN5VyMSJ4gjGz6BKAe/SWEZyR60zx139lYCDutOuN8Fprw78YurhmC4bJPwPqDKhLYCIQr1E7k1V83Z2JcTVSKro7l70I2eDhb+WTLLUe18FXqXRplDb3pzVvNEcf8N84lSpND0p9OQvkeMMg8U2RfqGvQWd4F9SLC9/hCs21S22X51vpd31VjOii+ox/uWgb0KTGeDL+qGNF/ldnAlEa0aqq+ctGNGeAN1UmInrG+4zzSOotrllOXlrxvGZqIp7cZrKA8lPvrGH1J2kQqoApxg5OQIzxrC9BDxWw+rOB8WfvmmAnxCmXAhJMX97IzQ76GE0oOZnxvab331nywiQxFN7lNhT1hi5TSfqmxEyzKyS2ULFRj3GUsFSenG1QDj3RRxOQm7GnAVehQiOU+iVYwLMvUXe99Gp8D2Jm4uJplUou7/hPf4bmiLG2PoeunZ9rnD51ReUMjIm9FcgjH5U/kiifa3TyBZjf4vPkNFuQ4OJ1R7XJz7Lr5LLGRTZSDZdpLaNFjpyNRG7PVPGuXQcx69LO0yup3wT05dll5UZ0/umUsONsClGee8ONbsQUXT5Zk1hnh9QhRONFmziDA== 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: eaf62d8b-cd26-4c72-71d3-08d884d1071e X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 17:00:57.3878 (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: ChlUZn3h2ZRXal4cRu3xeX2PyNit85Df6G0bbITUWgVNyWKxG87HjeKR4/15U6jXhoD/+ouKCKB8I+wGDlDINA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6850 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=x43aSXu3xMPBA7WpQkVJYRNvxq8F2RrQuH86CrvcyE4=; b=fNRhytC1vW8+iDGw5xCk8oJ6jR2pHxcNYxJT9m8+Ji60sJMK5Dk7SojCix0L/dmzAHEvI/tmA62nwWtD6Y235YiP+C5L0WYbxRJymE8WIJ/GD1Uh6ov21o/97wCQFq/ZPK60ZnkFuSezlZMBUwhh2TY9byQks1Xp5sAIYGWo0II= Archived-At: Subject: Re: [Rum] [EXT] POLL: RUM session at IETF 109 virtual meeting 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, 09 Nov 2020 17:01:32 -0000 I plan to attend, but would prefer to meet at a time closer to daylight hou= rs for the majority of VRS providers and other stakeholders (primarily cont= inental United States and Western Europe). Thanks, Jim Malloy Principal Information System Engineer The MITRE Corp. 703 983 2835 -----Original Message----- From: Rum On Behalf Of Paul Kyzivat Sent: Monday, November 9, 2020 10:35 AM To: rum@ietf.org Subject: [EXT] [Rum] POLL: RUM session at IETF 109 virtual meeting To those interested in RUM: We currently have a RUM session scheduled during the IETF 109 virtual meeti= ng. The time slot is Wednesday Nov 18 at 2:30 AM EST. (Yes, *AM*.=20 The meeting is rooted in Singapore time.) *** Please reply if you intend to attend/participate in this session. (Note that you need to register for IETF 109 to attend, either for the week= or for a day.) If you do NOT intend to attend, but would attend a session under different = circumstances, please respond and indicate under what circumstances you wou= ld attend. Thanks, Paul -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Mon Nov 9 12:22:56 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 3DDC73A134D for ; Mon, 9 Nov 2020 12:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 eMzSpCTWTtcR for ; Mon, 9 Nov 2020 12:22:51 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2043.outbound.protection.outlook.com [40.107.237.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 3F6913A134C for ; Mon, 9 Nov 2020 12:22:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iU13uoVvm1lXt000bODldakuDOthi6pMkdd3SUV1d1LD8383UM94qEOdky4mNM9J1jbL6F53jCJL1viFrWa80f6ndUGHeQ9p81w6XeV6YcNkLJEhrhw1f83YhQuK0gmFZ/XW+6VOkSOuQ95jhaVv11CZBMmtK2FfqfpLC+W5ve+7agzsKFHp4bWd5JjJc+8C3QrsxMjUGQMdlIDiOMPhX4uu8kKTGEnAW5pB+hV1U3F8D1u2yZN0Eo8yHPdNDAPEECySXRbPWVo2PMDvoZGEcHSX4IGvCvUxwlgFRhC6jJ5j1doNAiV+atoyqilgDRoAa5Zohd4bFnJvBr0IhTYwAA== 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=flvsNR6yieEQd/DzNKjS6gaiP6R12RYgonqT4UvJjh4=; b=nFeRyywTT4dfFehIA2pFSZhKMnCYeUetLDX1cdAPt7qBxroMr3XF1z3R91xIjWVO/Zo9pUDjlVIplAsCI26u0o+9IwHZ5Sb+NWb/HtS30lp3/AW7CcLhx+/vQ11r6FX/yJMbLkaC+bhj0qRz2THXTktVeVkDqfdBE+KynRURQHcpiyskFrxCcHFlJgZDcEOLevSKMDi+NSg8+/+SRoNN+hLwxFNOGgCVsNmIg2V4z+zw/j87+uqyhap/f6EKDxIdwStmHxogU6gdYZKX5/JgabkDLdsDzFYyRHyzMAxWWAVDs7g5rzfZVFS/xg3UgRBZoOmoUEhhfdAte/JLmaCvSg== 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=flvsNR6yieEQd/DzNKjS6gaiP6R12RYgonqT4UvJjh4=; b=ruokhYK+1svXSS3t+qPwWhYZAdAWP+WMyKjfIlx7mPmFMOPqRzCdZyt3PhZ2d62qy5FmqmW4IFDFVdbvDcW6WM4P61Ps8leTXMRA8ertVKdUHvg7XPOFEAv1BKNZT3kbXScC5uYRKOkGEJRZwAVDYfWNCWAuZXJVYLbpt6HztT0= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BYAPR04MB4518.namprd04.prod.outlook.com (2603:10b6:a03:5b::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.25; Mon, 9 Nov 2020 20:22:45 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1%7]) with mapi id 15.20.3541.022; Mon, 9 Nov 2020 20:22:45 +0000 From: Eugene Christensen To: Brian Rosen , Paul Kyzivat CC: "Olle E. Johansson" , "rum@ietf.org" Thread-Topic: [Rum] [EXT] RUM security model Thread-Index: AQHWlnxQD9PXpaMUFE6N0jV2IR9mp6mBxBhggAAW2wCAF0rLoIAAMpaAgAAXOoCAAAeJgIAAAV6AgAD5eYCABjafAIAAF2wAgAFtX5CAABXWAIABCTiAgACYEgCADPFHMIAGPEYAgAACX4CACWqy4A== Date: Mon, 9 Nov 2020 20:22:45 +0000 Message-ID: References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> <38090A50-6572-4A8E-97D4-C260323365AE@brianrosen.net> <90279636-259e-8ff6-7e28-406a84ddeccc@alum.mit.edu> <1EE964DF-3F07-4F36-83C2-7B27068B434F@brianrosen.net> In-Reply-To: <1EE964DF-3F07-4F36-83C2-7B27068B434F@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; 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: 3b509848-591c-4f8e-f97a-08d884ed37d7 x-ms-traffictypediagnostic: BYAPR04MB4518: 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: gHCxLabqyiguDN/Z5CE7fC26H7n681jdqytwyqaX/KXSjRDtb7ZZG+fG1X33mi5Eyqs+zzzMM2QXDTmtcXiTzwO6LT25s9liXRjGr3gy9w6iYibSWHSbe75D9k2J2tSaoW350LDqG7sdEVYClJPBcTbkmz6uaAkpIPA3yfhxiNUqRmgMhtqvNm+9+65hYwOl1pyRDUeHgbHCoGOPkjB8QHDv60ZuuABKVssTmRLdwxfMD5vj3hvp+dL/morX5OJ3IIRladPclw10qvdX+dxZ60gI2mQ//edzw8Vf64yF0o41zY5zhROBKeba0CGMvqNAFisIOU7fPlG8u77lKE/smQ== 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)(346002)(136003)(39850400004)(376002)(366004)(33656002)(18074004)(66946007)(76116006)(9686003)(64756008)(66556008)(66476007)(66446008)(83380400001)(8936002)(55016002)(71200400001)(2906002)(26005)(15650500001)(66574015)(53546011)(6506007)(478600001)(52536014)(186003)(7696005)(316002)(110136005)(5660300002)(86362001)(54906003)(8676002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: KqeNQYsIKEYPotfPfBdUu5QrDz0F0XnEAisVXtq2StbFpiVZKyUAOoFGnUdhKkYmEPdIkfQzSmJLh3Bo/q4K2b1G3Ff6YiSoDbCI9ViO0KwVENfLhuvqk0u22MuzDf6CibXBp/FT6DjMqAzk0MoeJB3gY+FAHK7IGyRw0wAsfCjeNdS9/LxtU/41cuO4j63gBHsauh+lfbf8bfpANknrDLp3sPw4OQ204g8xWOo5zRSDPEpKFA0mz+jhlFvVsVjTCJeYp5uygAz0nrLrsdZgy4udBvigVynbTgEmuQue9xRo+Gh+cZdPTkyWdN413fZVPFn4MWF/9A19rLx8Ma3hXWQSqJ1gOjTzbeQKRIkmkft1BQRSHRFT/kG/UZjWEoDyglke2CKzFTaslGxKAxZEzqtnrl7O6gCBw0jbz5c7jobUNU7Bb80BkmKw99/KphXjB91YQ3/yd8AMV8fSf91tFbjPm9APh9xD5DPST0c/EXKyncS0B3V6ahI4N1COo5IcMqnx5pTi2o9SxNscCz43L5bU2tUnir1V7vw5HOLaup3jnf11jJbiYXz0rdQpQ5xQNnHjNFPrSjD8MhGD2AnDgtQqn9CjKgHKmATCmFKvYOiqZXSaF1lxAfPlGt5MvQqN8xBiGEQhUMOB5VY1sv3IhKFThL3METYfDH1RlELj/ETuakmIQm0AHLaLoDz72tzE9CU2chtv2kpzpyQy22uNnj0JI9WTSlr8fK/MCOKqKz2ihDDyW5pIzKbmVBUVRQNOhmDuWmiK16W7Iek4d8f/6i79A2Tbpie3F+tnGpSXB5cRMH3luKippoQZSlPK66zEOL3/FM4vDwvDHRekRmQlXT1Q66U9PiDdZhQEN04+7Ss8Hry/xR6/loPK2erBsc4kt/7YGLbUL62N3i5qVYyqtg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: 3b509848-591c-4f8e-f97a-08d884ed37d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 20:22:45.1112 (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: yDjACf9mWsbFJzzuu0Gj0ZxAFkX7Qcf4TT/+J70zW3HTPBAnt70kFxMtx8Jnxi44EKuAJJ2LgEZd25C23SxU7pFC/CCptV/AI3n/cLwS+/E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB4518 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: Mon, 09 Nov 2020 20:22:54 -0000 QnJpYW4sDQoNCkkgdGhpbmsgd2UgYXJlIHdvcmtpbmcgdG93YXJkcyBhIHNvbHV0aW9uIHRoYXQg SSBhZ3JlZSB3aXRoLiAgSnVzdCB0byBtYWtlIHN1cmUgd2UgYXJlIGNsZWFyLCBsZXQgbWUgc3Rh dGUgYSBjb3VwbGUgb2YgdGhpbmdzLg0KDQpJbiBzZWN0aW9uIDkgb2YgdGhlIGRyYWZ0IGRvY3Vt ZW50LCBpdCBpZGVudGlmaWVzIHR3byBmaWxlcy4gIFRoZSBmaXJzdCAoSeKAmWxsIGNhbGwgZmls ZTEpIGlzIGEgZmlsZSB0aGF0IOKAnHByb3ZpZGVzIGEgZGlyZWN0b3J5IG9mIHByb3ZpZGVyc+KA nSBhbmQgdGhlIHNlY29uZCAoSeKAmWxsIGNhbGwgZmlsZTIpIOKAnHByb3ZpZGVzIGNvbmZpZ3Vy YXRpb24gZGF0YSBmb3IgdGhlIGRldmljZeKAnS4gIFRoZSBkb2N1bWVudCBhbHNvIHNheXMg4oCc VGhlIFZSUyB1c2VyIGludGVyYWN0cyB3aXRoIHRoZSBSVUUgdG8gc2VsZWN0IGZyb20gdGhlIFBy b3ZpZGVyIGxpc3Qgb25lIG9yIG1vcmUgUHJvdmlkZXJzIHdpdGggd2hvbSB0aGUgdXNlciBoYXMg YWxyZWFkeSBlc3RhYmxpc2hlZCBhbiBhY2NvdW504oCdLg0KDQpXaXRoIHRoZSBhYm92ZSB1bmRl cnN0YW5kaW5nLCBJIGJlbGlldmUgYWNjZXNzIHRvIHRoZSBzZWNvbmQgZmlsZSByZXF1aXJlcyB0 d28gbGV2ZWxzIG9mIHNlY3VyaXR5IHdpdGggdGhlIGhvc3Qgb2YgZmlsZTIgKHByZXN1bWFibHkg dGhlIFByb3ZpZGVyIHdpdGggd2hvbSB0aGUgdXNlciB3aXNoZXMgdG8gcmVnaXN0ZXIgYW5kIHVz ZSB0aGUgUlVFKS4gIFRoZSBmaXJzdCBsZXZlbCBvZiBzZWN1cml0eSBpcyB0aGUgQVBJIGtleSB0 aGF0IEkgYmVsaWV2ZSB3ZSBoYXZlIGJlZW4gdGFsa2luZyBhYm91dC4gIFRoZSBzZWNvbmQgbGV2 ZWwgb2Ygc2VjdXJpdHkgbXVzdCBpbmNsdWRlIHVzZXIgYXV0aGVudGljYXRpb24gYmFzZWQgb24g dGhlIGVzdGFibGlzaGVkIGFjY291bnQgd2l0aCB0aGUgUHJvdmlkZXIuDQoNCkkgd291bGQgcHJl ZmVyIHRvIHNlZSB0aGUgQVBJIGtleSBkb25lIG92ZXIgSFRUUFMsIG5vdCBTSVAuIA0KDQpJdCBt YXkgYmUgZGVzaXJhYmxlIHRvIGhhdmUgYW4gQVBJIGtleSB0byBhY2Nlc3MgZmlsZTEgYXMgd2Vs bCBidXQgd2hhdGV2ZXIgZW50aXR5IGlzIGhvc3RpbmcgZmlsZTEgc2hvdWxkIHdlaWdoIGluIG9u IHRoaXMuDQoNCldoZW4gdGhlIFJVRSBoYXMgb2J0YWluZWQgZmlsZTIgYW5kIGlzIHRoZW4gcmVh ZHkgdG8gcmVnaXN0ZXIgd2l0aCBzYWlkIFByb3ZpZGVyLCBJIGJlbGlldmUgd2Ugc2hvdWxkIHN0 aWxsIGhhdmUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGFzIHBhcnQgb2YgdGhlIHNlc3Npb24gZXN0 YWJsaXNobWVudC4gIFRoZSBjZXJ0aWZpY2F0ZSBhbmQgQVBJIGtleXMgY291bGQgYmUgZW1iZWRk ZWQgaW50byB0aGUgUlVFIGFwcGxpY2F0aW9uLiAgVGhlIGNlcnRpZmljYXRlIGNvdWxkIGFsc28g cG90ZW50aWFsbHkgYmUgcmVjZWl2ZWQgYXMgcGFydCBvZiB0aGUgZXhjaGFuZ2UgZm9yIGZpbGUy Lg0KDQpJbiBib3RoIGNhc2VzLCBJIGJlbGlldmUgd2Ugc2hvdWxkIG1ha2UgdGhlIHVzZSBvZiBB UEkga2V5IGFuZCB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIG9wdGlvbmFsIGF0IHRoZSBQcm92 aWRlcuKAmXMgZGlzY3JldGlvbi4NCg0KVGhhbmsgeW91Lg0KDQpFdWdlbmUgQ2hyaXN0ZW5zZW4u DQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0UuIFRoaXMgZS1tYWlsIHRyYW5zbWlzc2lvbiwgYW5k IGFueSBkb2N1bWVudHMsIGZpbGVzIG9yIHByZXZpb3VzIGUtbWFpbCBtZXNzYWdlcyBhdHRhY2hl ZCB0byBpdCwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcm9wcmlldGFyeSBpbmZvcm1h dGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgYSBwZXJzb24g cmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgaXQgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlz dHJpYnV0aW9uIG9yIHVzZSBvZiBhbnkgb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBv ciBhdHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMgU1RSSUNUTFkgUFJPSElCSVRFRC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlh dGVseSBub3RpZnkgbWUgYnkgcmVwbHkgZS1tYWlsIGF0IGVjaHJpc3RlbnNlbkBzb3JlbnNvbi5j b20gb3IgYnkgdGVsZXBob25lIGF0ICsxICg4MDEpIDI4Ny05NDE5LCBhbmQgZGVzdHJveSB0aGUg b3JpZ2luYWwgdHJhbnNtaXNzaW9uIGFuZCBpdHMgYXR0YWNobWVudHMgd2l0aG91dCByZWFkaW5n IHRoZW0gb3Igc2F2aW5nIHRoZW0gdG8gZGlzay4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4gDQpTZW50OiBUdWVzZGF5 LCBOb3ZlbWJlciAzLCAyMDIwIDE6MzQgUE0NClRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFs dW0ubWl0LmVkdT4NCkNjOiBFdWdlbmUgQ2hyaXN0ZW5zZW4gPGVjaHJpc3RlbnNlbkBzb3JlbnNv bi5jb20+OyBPbGxlIEUuIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+OyBydW1AaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbUnVtXSBbRVhUXSBSVU0gc2VjdXJpdHkgbW9kZWwNCg0KW0VYVEVSTkFM XSANCg0KQ2xhc3NpYyBBUEkgS2V5cyBkb27igJl0IGRlcGVuZCBvbiB1c2VyIHNpZ24gaW46IGl0 4oCZcyBidWlsdCBpbnRvIHRoZSBjb2RlLiAgSW4gdGVybXMgb2Ygb3VyIHNwZWMsIGFsbCB3ZSB3 b3VsZCBuZWVkIGlzIHRoZSBtZWNoYW5pc20gdG8gc2VuZCB0aGUgY29kZSwgYW5kIHdlIHdvdWxk buKAmXQgZGVhbCB3aXRoIGhvdyB0aGUgY29kZSBkZXZlbG9wZXIgZ290IHRoZSBrZXkuICBDbGFz c2ljYWxseSwgaXTigJlzIHNlbnQgaW4gc29tZSBpbml0aWFsIHRyYW5zYWN0aW9uIGFmdGVyIFRM UyBpcyBlc3RhYmxpc2hlZCwgc28gdGhlIGtleSBjYW7igJl0IGJlIG9ic2VydmVkLg0KDQpJZiBB UEkgS2V54oCZcyBhcmUgYSBzYXRpc2ZhY3RvcnkgKHRvIHByb3ZpZGVycykgd2F5IG9mIGNvbnRy b2xsaW5nIHdoYXQgaW1wbGVtZW50YXRpb25zIGFyZSBhbGxvd2VkIGFjY2Vzcywgd2UgY2FuIGRp c2N1c3MgbWVjaGFuaXNtIGFuZCBJ4oCZbGwgd3JpdGUgdGV4dC4NCg0KSSB0aGluayB0aGUgZnVu ZGFtZW50YWwgcXVlc3Rpb24gaXMgZG8gd2Ugd2FudCBhIFNJUCBtZWNoYW5pc20gKHdoaWNoIG1l YW5zIFRDUC9UTFMgc2lnbmFsaW5nKSBvciBhbiBIVFRQIG1lY2hhbmlzbT8gIFdlIGNvdWxkIHRp ZSBpdCB0byB0aGUgcmV0cmlldmFsIG9mIHRoZSBjb25maWcgZmlsZSBpZiB0aGF0IGlzIHBlci1w cm92aWRlciwgd2hpY2ggd291bGQgYmUgYW4gSFRUUCBtZWNoYW5pc20sIG9yIHdlIGNvdWxkIGlu Y2x1ZGUgaXQgaW4sIHNheSwgYSBDYWxsLUluZm8gaGVhZGVyIG9uIGEgU0lQIFJFR0lTVEVSIGlm IHRoYXQgd2FzIFRMUyBwcm90ZWN0ZWQuDQoNCkJyaWFuDQoNCg0KPiBPbiBOb3YgMywgMjAyMCwg YXQgMzoyNSBQTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0K PiANCj4gRXVnZW5lLA0KPiANCj4gT24gMTAvMzAvMjAgNTo0MCBQTSwgRXVnZW5lIENocmlzdGVu c2VuIHdyb3RlOg0KPj4gVGhlcmUgaGFzIHRvIGJlIHNvbWUgYW1vdW50IG9mIHRydXN0IGJldHdl ZW4gdGhlIHByb3ZpZGVycyBzbyBJIHRoaW5rIHdlIHNob3VsZCBjb25zaWRlciB0aGUgdXNlIG9m IGFuIEFQSSBrZXkgZm9yIGFjY2VzcyB0byB0aGUgcHJvdmlkZXIncyBjb25maWd1cmF0aW9uIHNl cnZpY2UuICBJZiBhbiBBUEkga2V5IGlzIGdpdmVuIGFuZCBhbm90aGVyIHByb3ZpZGVyIGFidXNl cyB0aGF0LCBpdCBvYnZpb3VzbHkgY291bGQgcmVzdWx0IGluIHNvbWV0aGluZyBiYWQgYnV0IGl0 IGNvdWxkIHF1aWNrbHkgYmUgcmV2b2tlZCBieSB0aGUgcHJvdmlkZXI7IHJpZ2h0PyAgQW5kIHRo ZSBjb21wYW55IHRoYXQgaGFzIGFidXNlZCBpdCB3aWxsIGxpa2VseSBub3QgYmUgdHJ1c3RlZCBp biB0aGUgZnV0dXJlIChtb3RpdmF0aW9uIGZvciBtYWludGFpbmluZyB0cnVzdCkuDQo+IA0KPiBJ dCBkZXBlbmRzIG9uIGhvdyBrZXkgbWFuYWdlbWVudCB3b3Jrcy4gRG9lcyBlYWNoIGRldmljZS9h cHAgbmVlZCB0byB0ZXN0IHdpdGggZWFjaCBwcm92aWRlciBhbmQgcmVjZWl2ZSBhIHNlcGFyYXRl IGtleSBmcm9tIGVhY2ggcHJvdmlkZXI/DQo+IE9yIGRvZXMgdGhlIHRlc3RpbmcgaGFwcGVuIHdp dGggc29tZSB0ZXN0aW5nIG9yZ2FuaXphdGlvbiB3aG8gdGhlbiBwcm92aWRlcyBhIGtleSB0aGF0 IGFsbCBwcm92aWRlcnMgYWNjZXB0Pw0KPiANCj4gVGhlIGxvZ2lzdGljcyBvZiB0ZXN0aW5nIGFu ZCByZXZvY2F0aW9uIGRpZmZlciBpbiB0aGVzZSBjYXNlcy4NCj4gDQo+PiBXb3VsZCBpdCBhbHNv IGJlIHdpc2UgdG8gdXNlIGEgY2xpZW50IGNlcnRpZmljYXRlIGZvciBTSVAgY29tbXVuaWNhdGlv bnMgb25jZSB0aGUgUlVFIGhhcyB0aGUgbmVjZXNzYXJ5IGluZm8gZnJvbSB0aGUgY29uZmlndXJh dGlvbiBzZXJ2aWNlPyAgVGhlIGNsaWVudCBjZXJ0aWZpY2F0ZSBjb3VsZCBiZSBlbWJlZGRlZCBp bnRvIHRoZSBhcHBsaWNhdGlvbi4NCj4gDQo+IEZyb20gYSBwcmFjdGljYWwgcGVyc3BlY3RpdmUg SSB0aGluayB3ZSBuZWVkIHRvIGF1dGhlbnRpY2F0ZSB1c2luZyBhIHBhc3N3b3JkIGF0IHNvbWUg cG9pbnQuIChKdXN0IGR1ZSB0byBsb2dpc3RpY3Mgb2YgYm9vdHN0cmFwcGluZyBhbmQgaWRlbnRp ZnlpbmcgdGhlIGh1bWFuIHVzZXIuIFBlcmhhcHMgb25seSBmb3IgdGhlIGNvbmZpZyBzZXJ2aWNl LikgT3IgcGVyaGFwcyBjb3VsZCB1c2UgT0F1dGggdG8gYXV0aGVudGljYXRlIHVzaW5nIEZhY2Vi b29rL0dvb2dsZS8uLi4NCj4gDQo+IEZyb20gdGhlcmUgaXQgbWlnaHQgbWFrZSBzZW5zZSB0byBw cm92aWRlIGNlcnRzIGZvciBzdWJzZXF1ZW50IHVzZS4NCj4gDQo+PiBJcyB0aGVyZSBhbnkgcmVh c29uIHdlIGNhbm5vdCB1c2UgbGFuZ3VhZ2UgdGhhdCBtYWtlcyB0aGUgdXNlIG9mIHRoZSBBUEkg a2V5IGFuZCBjbGllbnQgY2VydGlmaWNhdGUgb3B0aW9uYWwsIGF0IHRoZSBkaXNjcmV0aW9uIG9m IHRoZSBwcm92aWRlcj8gIChlLmcuIFRoZSBwcm92aWRlcnMgTUFZIHJlcXVpcmUgYW4gQVBJIGtl eSBmb3IgdGhlaXIgY29uZmlndXJhdGlvbiBzZXJ2aWNlIGFuZC9vciBhIGNsaWVudCBjZXJ0aWZp Y2F0ZSBmb3IgU0lQIGNvbW11bmljYXRpb25zKS4NCj4gDQo+IFBvc3NpYmx5LiBUaGUgZGV2aWwg aXMgaW4gdGhlIGRldGFpbHMgaGVyZS4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPj4g VGhhbmtzLA0KPj4gRXVnZW5lLg0KPj4gQ09ORklERU5USUFMSVRZIE5PVElDRS4gVGhpcyBlLW1h aWwgdHJhbnNtaXNzaW9uLCBhbmQgYW55IGRvY3VtZW50cywgZmlsZXMgb3IgcHJldmlvdXMgZS1t YWlsIG1lc3NhZ2VzIGF0dGFjaGVkIHRvIGl0LCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5k IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBvciBhIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0byB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNj bG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIGFueSBvZiB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIG9yIGF0dGFjaGVkIHRvIHRoaXMgbWVzc2FnZSBpcyBTVFJJQ1RM WSBQUk9ISUJJVEVELiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBl cnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSBtZSBieSByZXBseSBlLW1haWwgYXQgZWNo cmlzdGVuc2VuQHNvcmVuc29uLmNvbSBvciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0 MTksIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24gYW5kIGl0cyBhdHRhY2ht ZW50cyB3aXRob3V0IHJlYWRpbmcgdGhlbSBvciBzYXZpbmcgdGhlbSB0byBkaXNrLg0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRA YWx1bS5taXQuZWR1Pg0KPj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjIsIDIwMjAgOTozNCBB TQ0KPj4gVG86IE9sbGUgRS4gSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD47IEJyaWFuIFJvc2Vu IA0KPj4gPGJyQGJyaWFucm9zZW4ubmV0Pg0KPj4gQ2M6IEV1Z2VuZSBDaHJpc3RlbnNlbiA8ZWNo cmlzdGVuc2VuQHNvcmVuc29uLmNvbT47IHJ1bUBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtS dW1dIFtFWFRdIFJVTSBzZWN1cml0eSBtb2RlbCBbRVhURVJOQUxdIE9uIDEwLzIyLzIwIA0KPj4g MjoyOSBBTSwgT2xsZSBFLiBKb2hhbnNzb24gd3JvdGU6DQo+PiBbc25pcF0NCj4+Pj4gQnJ1dGUg Zm9yY2UgYW5kIEREb1MgYXR0YWNrcyBjYW7igJl0IGJlIGFkZHJlc3NlZCBieSB0aGlzIGRvY3Vt ZW50IGV4Y2VwdCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBzZWN0aW9uLiAgVGhleSBh cmUgaW1wbGVtZW50YXRpb24gaXNzdWVzLg0KPj4+IElmIHRoZXJlIGFyZSBzcGVjaWZpYyBhdHRh Y2sgdmVjdG9ycyB0byBSVU0gdGhhdCBkb2VzbuKAmXQgYXBwbHkgdG8gU0lQIGltcGxlbWVudGF0 aW9ucyBpbiBnZW5lcmFsLCB5ZXMuDQo+PiBBRkFJSyB0aGVyZSBzaG91bGQgYmUgbm90aGluZyBz cGVjaWFsIGFib3V0IFZSUyB0aGF0IG1ha2VzIGl0IGFueSBtb3JlIHZ1bG5lcmFibGUgdG8gYXR0 YWNrIHRoYW4gYW55IG90aGVyIHNpcCBzZXJ2aWNlIGFjY2Vzc2VkIG92ZXIgdGhlIHB1YmxpYyBp bnRlcm5ldC4NCj4+IEknZCBsaWtlIHRvIGhlYXIgZnJvbSB0aGUgcHJvdmlkZXJzIGlmIEkgYW0g d3JvbmcgYWJvdXQgdGhpcy4NCj4+IAlUaGFua3MsDQo+PiAJUGF1bA0KPiANCg0K From nobody Mon Nov 9 15:01:28 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 708823A14C3 for ; Mon, 9 Nov 2020 15:01:27 -0800 (PST) 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 4HS43Plq2Ibp for ; Mon, 9 Nov 2020 15:01:25 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 2595F3A14C8 for ; Mon, 9 Nov 2020 15:01:25 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id m65so7278191qte.11 for ; Mon, 09 Nov 2020 15:01:25 -0800 (PST) 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=nJ7CuPwtQd6mzHeUnWDdjag64hkJDa70xuSi70ryugw=; b=YrRf/w7zQfuWRNVaZ5Zm9KJRxn604GMO4IpGRwBtbBnXFtjzVPvTYaDZPzupZsK0nK eb5wwFpwLDY0WYpnO7xNhJMRfD8n0PQ6ezg1VOBryAYD7h7UoCKKA4Ow1dt7mzYRoQCm BsH2WlXQeW38xvfD3DezUF/M0yhBnqLdr4pEpQ2i5kExkni9ddxiLBG59qsj7UNmxCqQ cStPEuizt1Aon8Ha4mh0Zebfw2rTamkf6RpMa2DzBhnN2SVTL7Br3bDSS/Vfbhl5X9E9 TChdaHgTpaWT8QwwZru7FdKlfPb1Tsj0nYE/G1kJcWbIDZxUJUAGko6gITxkLWg2kiei OQYg== 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=nJ7CuPwtQd6mzHeUnWDdjag64hkJDa70xuSi70ryugw=; b=VywNzPkchK2+TYb7lfHx59GSJsxv69r5k13liP12oZxgg/znpqqIT0bu5SyQ55l/zO mr3pGwoKxrlKe2f6H5jcGQN66EzywOcAKjnsADGxdry4ujNk3Khqi0rkvho08AyX0zoI WkRMNo2EfttZabgmpZ8iutnqbaMo3QcFwh4itx2AGDeifrgoApV/eAlRV56Q0uTODNI1 P6FJcFxrpICY302FCuWN5j2T1b3zRftHHq52wee95cC4ITz5Uy0b+BwN5vsu8z9zZRaf J+fyxQlpMScEjB3w36jqTzTN+omjX+ZUaRBbPUInC4iJJiw0pwFiX3NAtqo0YSh2DUwV Bf7g== X-Gm-Message-State: AOAM530VBa1JNxp2QIeqgvhGckceZRX2A76YtUqLcj8wBqD7x7GnLdSf kaDt0rAuYF2jgxtyunmrimqiIA== X-Google-Smtp-Source: ABdhPJxC34AbPSi08iJmNOXFcsrBeN1bN4xGXv94Xmj7o+5RFMwr19aHxFpW8uxelLFFM8xZfvrW/w== X-Received: by 2002:ac8:675a:: with SMTP id n26mr6013382qtp.139.1604962884120; Mon, 09 Nov 2020 15:01:24 -0800 (PST) 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 l28sm7230441qkl.7.2020.11.09.15.01.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2020 15:01:23 -0800 (PST) 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: Mon, 9 Nov 2020 18:01:21 -0500 Cc: Paul Kyzivat , "Olle E. Johansson" , "rum@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <50CC121B-6CC0-4EFE-A35C-97FE2B5A3717@brianrosen.net> References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> <38090A50-6572-4A8E-97D4-C260323365AE@brianrosen.net> <90279636-259e-8ff6-7e28-406a84ddeccc@alum.mit.edu> <1EE964DF-3F07-4F36-83C2-7B27068B434F@brianrosen.net> To: Eugene Christensen X-Mailer: Apple Mail (2.3608.120.23.2.1) 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: Mon, 09 Nov 2020 23:01:27 -0000 Usually, an API key is used for all transactions. In our case, there = would be the file download that has credentials (the 2nd file), and = there is the SIP REGISTER and INVITE transactions. Either or both could = be annotated with the API Key. File 1 is a public file and there is only one per country (not per = user). The reason file 2 had credentials in it was to avoid having users that = maintained accounts at multiple providers have to remember password per = provider. The idea is that the file is protected, using some way to = have users authenticate to get access to it, and then that had the = per-provider authentication information in it. As currently described, = there is one file and it has multiple provider credentials in it. There is discussion now of file (2) per provider, which is okay, but = would need some common authentication and not the per-provider = credentials to get at. I remind you that essentially all VoIP phones store provider credentials = locally, with zero local authentication. The notion is that you need = physical access to get to those credentials. The soft phone guys copy = that idea, with varying degrees of security on the file that holds the = VoIP provider credentials. Users don=E2=80=99t type credentials per use = and most current VoIP phones maintain multiple =E2=80=9Clines=E2=80=9D = with per =E2=80=9Cline=E2=80=9D credentials, i.e. exactly what I=E2=80=99m= trying to maintain here. > On Nov 9, 2020, at 3:22 PM, Eugene Christensen = wrote: >=20 > Brian, >=20 > I think we are working towards a solution that I agree with. Just to = make sure we are clear, let me state a couple of things. >=20 > In section 9 of the draft document, it identifies two files. The = first (I=E2=80=99ll call file1) is a file that =E2=80=9Cprovides a = directory of providers=E2=80=9D and the second (I=E2=80=99ll call file2) = =E2=80=9Cprovides configuration data for the device=E2=80=9D. The = document also says =E2=80=9CThe VRS user interacts with the RUE to = select from the Provider list one or more Providers with whom the user = has already established an account=E2=80=9D. >=20 > With the above understanding, I believe access to the second file = requires two levels of security with the host of file2 (presumably the = Provider with whom the user wishes to register and use the RUE). The = first level of security is the API key that I believe we have been = talking about. The second level of security must include user = authentication based on the established account with the Provider. >=20 > I would prefer to see the API key done over HTTPS, not SIP.=20 >=20 > It may be desirable to have an API key to access file1 as well but = whatever entity is hosting file1 should weigh in on this. >=20 > When the RUE has obtained file2 and is then ready to register with = said Provider, I believe we should still have mutual authentication as = part of the session establishment. The certificate and API keys could = be embedded into the RUE application. The certificate could also = potentially be received as part of the exchange for file2. >=20 > In both cases, I believe we should make the use of API key and the = mutual authentication optional at the Provider=E2=80=99s discretion. >=20 > Thank you. >=20 > Eugene Christensen. >=20 > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person 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. >=20 > -----Original Message----- > From: Brian Rosen =20 > Sent: Tuesday, November 3, 2020 1:34 PM > To: Paul Kyzivat > Cc: Eugene Christensen ; Olle E. Johansson = ; rum@ietf.org > Subject: Re: [Rum] [EXT] RUM security model >=20 > [EXTERNAL]=20 >=20 > Classic API Keys don=E2=80=99t depend on user sign in: it=E2=80=99s = built into the code. In terms of our spec, all we would need is the = mechanism to send the code, and we wouldn=E2=80=99t deal with how the = code developer got the key. Classically, it=E2=80=99s sent in some = initial transaction after TLS is established, so the key can=E2=80=99t = be observed. >=20 > If API Key=E2=80=99s are a satisfactory (to providers) way of = controlling what implementations are allowed access, we can discuss = mechanism and I=E2=80=99ll write text. >=20 > I think the fundamental question is do we want a SIP mechanism (which = means TCP/TLS signaling) or an HTTP mechanism? We could tie it to the = retrieval of the config file if that is per-provider, which would be an = HTTP mechanism, or we could include it in, say, a Call-Info header on a = SIP REGISTER if that was TLS protected. >=20 > Brian >=20 >=20 >> On Nov 3, 2020, at 3:25 PM, Paul Kyzivat = wrote: >>=20 >> Eugene, >>=20 >> On 10/30/20 5:40 PM, Eugene Christensen wrote: >>> There has to be some amount of trust between the providers so I = think we should consider the use of an API key for access to the = provider's configuration service. If an API key is given and another = provider abuses that, it obviously could result in something bad but it = could quickly be revoked by the provider; right? And the company that = has abused it will likely not be trusted in the future (motivation for = maintaining trust). >>=20 >> It depends on how key management works. Does each device/app need to = test with each provider and receive a separate key from each provider? >> Or does the testing happen with some testing organization who then = provides a key that all providers accept? >>=20 >> The logistics of testing and revocation differ in these cases. >>=20 >>> Would it also be wise to use a client certificate for SIP = communications once the RUE has the necessary info from the = configuration service? The client certificate could be embedded into = the application. >>=20 >> =46rom a practical perspective I think we need to authenticate using = a password at some point. (Just due to logistics of bootstrapping and = identifying the human user. Perhaps only for the config service.) Or = perhaps could use OAuth to authenticate using Facebook/Google/... >>=20 >> =46rom there it might make sense to provide certs for subsequent use. >>=20 >>> Is there any reason we cannot use language that makes the use of the = API key and client certificate optional, at the discretion of the = provider? (e.g. The providers MAY require an API key for their = configuration service and/or a client certificate for SIP = communications). >>=20 >> Possibly. The devil is in the details here. >>=20 >> Thanks, >> Paul >>=20 >>> Thanks, >>> Eugene. >>> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person 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. >>> -----Original Message----- >>> From: Paul Kyzivat >>> Sent: Thursday, October 22, 2020 9:34 AM >>> To: Olle E. Johansson ; Brian Rosen=20 >>> >>> Cc: Eugene Christensen ; rum@ietf.org >>> Subject: Re: [Rum] [EXT] RUM security model [EXTERNAL] On 10/22/20=20= >>> 2:29 AM, Olle E. Johansson wrote: >>> [snip] >>>>> Brute force and DDoS attacks can=E2=80=99t be addressed by this = document except in the Security Consideration section. They are = implementation issues. >>>> If there are specific attack vectors to RUM that doesn=E2=80=99t = apply to SIP implementations in general, yes. >>> AFAIK there should be nothing special about VRS that makes it any = more vulnerable to attack than any other sip service accessed over the = public internet. >>> I'd like to hear from the providers if I am wrong about this. >>> Thanks, >>> Paul >>=20 >=20 From nobody Tue Nov 10 08:47:34 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 635B63A00D9 for ; Tue, 10 Nov 2020 08:47:33 -0800 (PST) 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 bIhrdrL_MG6A for ; Tue, 10 Nov 2020 08:47:31 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2053.outbound.protection.outlook.com [40.107.237.53]) (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 3BBDA3A0A2B for ; Tue, 10 Nov 2020 08:47:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Baf2COf5+LABu6tu8AOd7X2hOKLA5CA07Gqh2BZtex4rxFRVL+0VXqvLXvZ/Qgp1dnkv12faHokevFo9eJLm8euvqWbKL3moAmuYNQISq3M925xmu6/hsS+91iYkJQDbzycKY8bUhLrN0jSJ+fMkP0GMoE7rYJIfqElm9h8+Sn6Dc90Fd6Vrl/ji1LqLZOY8MpmnCC+DeZXKqHcKKX2ldFVbQdQYyKOT/yK8PPfxlPAKBM9kpt547EnCEW6ko11TmVPzptW1jfIG1uxtGEBNQSZBUkAkGXoR9DX6SwbNIacSKrNYtKRLBH/nL2WxG6ZPEOZrWx3SIBD+DNEdyT4kIQ== 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=d/B1JhjSw0lwVpgnOX9swIZGMAulEOTQ4QqNKDsekWo=; b=ngLqUt6cnUJm0dWN+65ve6o/5OS+2BO3wBRPwpPL5s+IbvocxVVXsCe+X5hnL9KHtXotsVSJiiz/HpjH4q14fj+pLBAbYxzVm6jrHt6r8BtleaixvAjHhdHupvvWHSHdu1fp9XGDvaHgpjfVb5JuMvI/n/FXXgyeacYJiYoWpjCk18YpC9Ecyk9bAhMklQMQpBvzN516YvlJTK9+lHCmkYpjMR7yfYByLYI5ty5QqlSGUgn8HeGJ9vu9Piu/i+D/aY/Q9eYBkz2c7294z0S6Ee+AWGG8545h1X5MDR7pnZNEpbmJTBJaUkXC+m4Vv//NmnByglUqbXpCuqBFrVwJyw== 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=d/B1JhjSw0lwVpgnOX9swIZGMAulEOTQ4QqNKDsekWo=; b=D2Pv1f0GmV0rmhO95q/PUW0y0HqTwxa3grFh4Fg4dyLbXEv1j0uvopdJqYVxEDbfGqBHLKY+UoY297d4cye28ubThpy46FpfEBXTph25uOcJTsMn7fF8CfqQE4edIt7W1MBYL1yPkAB8lxQrrkw9fimcFcmYsZx4OX079Sgi1R0= Received: from MN2PR15CA0011.namprd15.prod.outlook.com (2603:10b6:208:1b4::24) by BY5PR12MB4178.namprd12.prod.outlook.com (2603:10b6:a03:20e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Tue, 10 Nov 2020 16:47:29 +0000 Received: from BL2NAM02FT033.eop-nam02.prod.protection.outlook.com (2603:10b6:208:1b4:cafe::35) by MN2PR15CA0011.outlook.office365.com (2603:10b6:208:1b4::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Tue, 10 Nov 2020 16:47:29 +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 BL2NAM02FT033.mail.protection.outlook.com (10.152.77.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.17 via Frontend Transport; Tue, 10 Nov 2020 16:47:29 +0000 Received: from PaulKyzivatsMBP.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 0AAGlREu029486 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 10 Nov 2020 11:47:28 -0500 To: rum@ietf.org References: <17398_1604936088_5FA96193_17398_506_2_e988b397-49be-60fd-5c30-eabed2597b3d@alum.mit.edu> From: Paul Kyzivat Message-ID: <4e156e30-5d28-0f47-855e-7b53aae25424@alum.mit.edu> Date: Tue, 10 Nov 2020 11:47:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 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: a35c10e5-9227-4b8e-bf77-08d885984fae X-MS-TrafficTypeDiagnostic: BY5PR12MB4178: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JkWMNKWtfWnRHlmVu4bCf1mwCQCyCUZv1sdkTPiUD42awjm4K3X4ek7N7p3d0fKd7QGBMoL8e1qpUTE7I6UA//ftceYhMX1bkVMp0QWdgiDk5Q6cuyftX6QUXysPfFPuX0N6+1+DpKgq20tIljYCQVaVP4bGkrmdLhhDEetQ9OWTD6kUFLCIDCXlVnkSzGZZbLP4ZP3AAiRn8R+/tLkgU1Xcsscrkq2A0TzENz+IFLA4Sz833SLL3IMr9yxBQN/kaHZUHUtYU5Q8T3wOOUg4dTPRSws17dsOJxdDm9OzG/0VnBE3jRZYxNQsAL7I/rsowes+hMdbpOXSezKCqMK6uwVejktmGcAbK3PiPEBeOW11LEwsjI/0NGbb3fubtU2YFkIBtJ9RflqB67Kn1ZNr2cbRQaV4/NIXrQFMFY27wW4mKFLfboDiG4AKOqAqDMcXgOifuS2j0CFyiOsF/3KG16P7odF9JYvAMoDoGuw12c3SuaXDGT62kDVCD5TJQtEE 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)(376002)(39860400002)(136003)(346002)(46966005)(2906002)(36906005)(336012)(83380400001)(26005)(186003)(82310400003)(70206006)(70586007)(356005)(31686004)(53546011)(8936002)(5660300002)(8676002)(966005)(82740400003)(478600001)(956004)(31696002)(75432002)(47076004)(7596003)(6916009)(2616005)(786003)(316002)(86362001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2020 16:47:29.0421 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a35c10e5-9227-4b8e-bf77-08d885984fae 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: BL2NAM02FT033.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4178 Archived-At: Subject: Re: [Rum] [EXT] POLL: RUM session at IETF 109 virtual meeting 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, 10 Nov 2020 16:47:33 -0000 Jim, On 11/9/20 12:00 PM, Jim Malloy wrote: > I plan to attend, but would prefer to meet at a time closer to daylight hours for the majority of VRS providers and other stakeholders (primarily continental United States and Western Europe). I hear you. I would too. The situation is that the IETF is trying to keep to standard meeting procedures as much as possible during the covid emergency. There is a policy of rotating meetings among continents between the Americas, Europe, and Asia. This is, among other things, to give everybody a chance to have a share of the meetings in something close to their native time zone. So this time it is Asia time. With *live* meetings people travel to the locale of the meeting and suffer the jetlag once for the meeting. Not so much when attending remotely. (Some people who are attending a lot of sessions do just try to live the week on the time zone of the meeting.) 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: Monday, November 9, 2020 10:35 AM > To: rum@ietf.org > Subject: [EXT] [Rum] POLL: RUM session at IETF 109 virtual meeting > > To those interested in RUM: > > We currently have a RUM session scheduled during the IETF 109 virtual meeting. The time slot is Wednesday Nov 18 at 2:30 AM EST. (Yes, *AM*. > The meeting is rooted in Singapore time.) > > *** Please reply if you intend to attend/participate in this session. > > (Note that you need to register for IETF 109 to attend, either for the week or for a day.) > > If you do NOT intend to attend, but would attend a session under different circumstances, please respond and indicate under what circumstances you would attend. > > Thanks, > Paul > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > From nobody Wed Nov 11 10:17:42 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 10A1A3A0639 for ; Wed, 11 Nov 2020 10:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 kk7MslI1DdDN for ; Wed, 11 Nov 2020 10:17:39 -0800 (PST) Received: from outbound-ip25a.ess.barracuda.com (outbound-ip25a.ess.barracuda.com [209.222.82.207]) (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 810863A07DE for ; Wed, 11 Nov 2020 10:17:39 -0800 (PST) Received: from smtp.purple.us (smtp02.purple.us.91.17.208.in-addr.arpa [208.17.91.144]) by mx10.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 11 Nov 2020 18:17:36 +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, 11 Nov 2020 10:17:35 -0800 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, 11 Nov 2020 10:17:35 -0800 From: James Hamlin To: "rum@ietf.org" Thread-Topic: [Rum] POLL: RUM session at IETF 109 virtual meeting Thread-Index: AQHWuFaOWiiIl5CT1UiQa3U52bNPOA== Date: Wed, 11 Nov 2020 18:17:34 +0000 Message-ID: <1605118653961.89602@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_160511865396189602purpleus_" MIME-Version: 1.0 X-BESS-ID: 1605118656-893018-7531-21983-1 X-BESS-VER: 2019.1_20201110.2306 X-BESS-Apparent-Source-IP: 208.17.91.144 X-BESS-Outbound-Spam-Score: 0.20 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.228123 [from cloudscan12-199.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.20 BSF_SC0_SA953 META: Custom Rule BSF_SC0_SA953 0.00 BSF_BESS_OUTBOUND META: BESS Outbound 0.00 HTML_IMAGE_ONLY_24 BODY: HTML: images with 2000-2400 bytes of words X-BESS-Outbound-Spam-Status: SCORE=0.20 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_SC0_SA953, BSF_BESS_OUTBOUND, HTML_IMAGE_ONLY_24 X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] POLL: RUM session at IETF 109 virtual meeting 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, 11 Nov 2020 18:17:41 -0000 --_000_160511865396189602purpleus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul I'm planning to attend. Thanks 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. >> To: "rum@ietf.org" From: Paul Kyzivat Subject: [Rum] POLL: RUM session at IETF 109 virtual meeting Sender: "Rum" To those interested in RUM: We currently have a RUM session scheduled during the IETF 109 virtual meeting. The time slot is Wednesday Nov 18 at 2:30 AM EST. (Yes, *AM*. The meeting is rooted in Singapore time.) *** Please reply if you intend to attend/participate in this session. (Note that you need to register for IETF 109 to attend, either for the week or for a day.) If you do NOT intend to attend, but would attend a session under different circumstances, please respond and indicate under what circumstances you would attend. Thanks, Paul -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum --_000_160511865396189602purpleus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Paul


I'm planning to attend.


Thanks


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.


>>

To: "rum@ietf.org" <rum@ietf.org>=0A=
From: Paul Kyzivat <pkyzivat@alum.mit.edu>=0A=
Subject: [Rum] POLL: RUM session at IETF 109 virtual meeting=0A=
Sender: "Rum" <rum-bounces@ietf.org>=0A=
=0A=
To those interested in RUM:=0A=
=0A=
We currently have a RUM session scheduled during the IETF 109 virtual =0A=
meeting. The time slot is Wednesday Nov 18 at 2:30 AM EST. (Yes, *AM*. =0A=
The meeting is rooted in Singapore time.)=0A=
=0A=
*** Please reply if you intend to attend/participate in this session.=0A=
=0A=
(Note that you need to register for IETF 109 to attend, either for the =0A=
week or for a day.)=0A=
=0A=
If you do NOT intend to attend, but would attend a session under =0A=
different circumstances, please respond and indicate under what =0A=
circumstances you would attend.=0A=
=0A=
	Thanks,=0A=
	Paul=0A=
=0A=
-- =0A=
Rum mailing list=0A=
Rum@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/rum=0A=


--_000_160511865396189602purpleus_-- From nobody Thu Nov 19 19:50:30 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F120C3A1782; Thu, 19 Nov 2020 19:50:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584422497.3908.10522756103561119455@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:50:24 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:50:25 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4434/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 19:51:16 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD313A1787; Thu, 19 Nov 2020 19:51:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584427463.627.7394159666641924707@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:51:14 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:51:15 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4435/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 19:51:59 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 304A33A1787; Thu, 19 Nov 2020 19:51:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584431418.627.14922896404095213736@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:51:54 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:51:54 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4440/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 19:54:03 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AE73A1788; Thu, 19 Nov 2020 19:53:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584443726.4432.12853854955629104361@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:53:57 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:53:57 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4437/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 19:54:28 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C480B3A1789; Thu, 19 Nov 2020 19:54:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584446279.4432.11743047103579841564@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:54:22 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:54:23 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4442/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 19:54:50 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD443A1787; Thu, 19 Nov 2020 19:54:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584448596.30243.17373228497972146478@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:54:45 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:54:46 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4441/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 19:55:11 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E285F3A1789; Thu, 19 Nov 2020 19:55:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584450892.28552.5233649686142296532@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:55:08 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:55:09 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4443/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 19:55:33 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A603A1787; Thu, 19 Nov 2020 19:55:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584452929.2213.16064743945638036922@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:55:29 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:55:29 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4444/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 19:56:01 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 673863A1789; Thu, 19 Nov 2020 19:55:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584455940.24816.18058125322813234664@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:55:59 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:55:59 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4445/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 19:56:24 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EC03A1789; Thu, 19 Nov 2020 19:56:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584457902.3908.8094441383481504851@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:56:19 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:56:19 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4446/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 19:59:58 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CEA3A179E; Thu, 19 Nov 2020 19:59:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584479280.25795.9899110519879427498@ietfa.amsl.com> Date: Thu, 19 Nov 2020 19:59:52 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:59:53 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4447/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:00:48 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B4E3A17EF; Thu, 19 Nov 2020 20:00:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584484284.20856.6410814681162768312@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:00:42 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:00:44 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4449/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:01:06 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D60663A17AF; Thu, 19 Nov 2020 20:01:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584486487.3908.5742370514843606216@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:01:04 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:01:05 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4448/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:01:56 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 339503A17BB; Thu, 19 Nov 2020 20:01:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584491120.3908.14593632880555420053@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:01:51 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:01:51 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4450/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:02:23 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0113A17C3; Thu, 19 Nov 2020 20:02:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584494223.1190.16801752950450703567@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:02:22 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:02:22 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4452/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:02:49 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 669B73A17C3; Thu, 19 Nov 2020 20:02:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584496741.1175.7034514350354899700@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:02:47 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:02:47 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4451/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:03:22 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DDF3A185D; Thu, 19 Nov 2020 20:03:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584499472.30904.11053016808051051643@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:03:14 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:03:17 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4453/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:03:44 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 573693A17C1; Thu, 19 Nov 2020 20:03:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584502235.3908.7476212549865889706@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:03:42 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:03:42 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4454/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:05:08 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E393A193A; Thu, 19 Nov 2020 20:04:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584509866.30243.12888274308905008505@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:04:58 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:05:03 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4456/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:05:29 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EE23A1902; Thu, 19 Nov 2020 20:05:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584511713.14949.2377942707022143556@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:05:17 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:05:22 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4455/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:05:51 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BC43A17CE; Thu, 19 Nov 2020 20:05:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584514733.25795.11338519883912253687@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:05:47 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:05:47 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4457/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:06:11 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 611663A17DB; Thu, 19 Nov 2020 20:06:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584516839.30243.14901887233428628654@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:06:08 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:06:08 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4458/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:06:32 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D47A23A17EA; Thu, 19 Nov 2020 20:06:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584518786.30054.3226992196262494917@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:06:27 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:06:28 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4459/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:07:45 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5C93A17DA; Thu, 19 Nov 2020 20:07:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584526055.13601.13315591276803319033@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:07:40 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:07:41 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4460/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:08:07 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 658573A17DB; Thu, 19 Nov 2020 20:08:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584528240.627.7741044411183510411@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:08:02 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:08:03 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4462/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Thu Nov 19 20:08:20 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DF43A17DB; Thu, 19 Nov 2020 20:08:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rum@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160584529768.13601.17304264435812719778@ietfa.amsl.com> Date: Thu, 19 Nov 2020 20:08:17 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:08:18 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4461/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Fri Nov 20 07:10:48 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 73F6D3A0B6B for ; Fri, 20 Nov 2020 07:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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] 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 QjVn7dQFy9Xj for ; Fri, 20 Nov 2020 07:10:44 -0800 (PST) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 AAD013A00C9 for ; Fri, 20 Nov 2020 07:10:44 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id 9so599151qvk.9 for ; Fri, 20 Nov 2020 07:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=9o+jmA/G4acWtfzXCijduZxyVJTlbKncxJPW5EYjHVY=; b=xGL9e7fxk29hMj//GsK3miDDlNd5qVXZvgnODxYIMxDQy2yEs9whSlWGScYGLhkDNj hIxdFSYfHK8eUlMHNfOgQ6vJfkFdgX8lnQUL849j+Bf38Q14Si192XSQubz1iyCTIG3h RKAtj9HHTklYeBxwY6N686HtmSa0cHBH01U1bjjxZuL1iJTmOXBLsNzBdET1/rVNYvlb jISuwo3uhdQtNkdPEMRkkTL9w7hNpUpYaMcHEaRGsMl5mlb/OCZceMRV4mSlJUHE5G2j j58xgP5OU6w/bOEZO1qjm8u5BSe7Fyuf99YkinVvcuDOiCbL6JBOOWy3WWAtoeR4sS/A 3gYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=9o+jmA/G4acWtfzXCijduZxyVJTlbKncxJPW5EYjHVY=; b=sL6TNKHN8Rcl4THTTjSdLBeitPcUf93baFQIHeSywCCY34E5kMDihip9f1AS3tk6s2 fdYab/fkTfLN+jbfRzyPUYtDAI4OQnD8X3zOBVKRPpIRQrEDAGDFhMmbJtzc4eA+M0BA lVTvTO9Uf4HyQBSjWNJJvRoGnAW//Xp8qd1Eu2uuiDCLpglKH7cFRzyArP6T9G3ufhzd LPMGTP0Iezn1DHZTMj+ViDsMvZp3kSSy678EYmWDLmHQFw/GvEkuqQLzQ/+xC5pLRd+1 p9n3jEf01tYXIia4GPCocRoeWldRAbS084QIpDsOcQ5DVf89jNh57NAciq5VyjxdNB6q AK8A== X-Gm-Message-State: AOAM530EKH6UdVjDIGd92HpupozrPvAeUzBWWb6bZNbxWAXCyn8Y09Dk expOBNmQ26gPPgiTr9R17szfaeEaa81r0aNK X-Google-Smtp-Source: ABdhPJyMPSByf8R2kqyRXhK+268GjBCHOJo6fx8/NG4ImspZgUKKMrxMUSRU4cWzQ7pvlK3JQ4aJYQ== X-Received: by 2002:a0c:f254:: with SMTP id z20mr16771618qvl.36.1605885043637; Fri, 20 Nov 2020 07:10:43 -0800 (PST) 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 b12sm2098888qtj.12.2020.11.20.07.10.42 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2020 07:10:43 -0800 (PST) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <2F50A802-BC28-4A13-A9E1-A5271B642C1E@brianrosen.net> Date: Fri, 20 Nov 2020 10:10:40 -0500 To: rum@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [Rum] Username/password vs cert/OAUTH token 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, 20 Nov 2020 15:10:46 -0000 In the RUM meeting, Olle suggested we leave username/password as = authentication mechanism for SIP (and, he proposes, for the code = authentication issue) behind, and use OAUTH tokens or certs. In thinking about this, it occurs to me that the way you authenticate to = the OAUTH IDP is, wait for it, username and password, and the way you = access a private key if it=E2=80=99s human based access, is a pass = phrase. So, we might be improving the crypto a bit, but not the = authentication strength. So, why do it? Most IDPs these days offer, and sometimes require MFA. That=E2=80=99s = an improvement. Although it could be considered a SIP extension, = something simple like appending a code to the password or hashing the = password with a code would get us that if we wanted it. I=E2=80=99d = actually prefer OAUTH, but I could see doing that for REGISTER, or for = that matter HTTPS. I also note that the transaction to present the API = Key doesn=E2=80=99t need user credentials, but if we didn=E2=80=99t use = them, then we would need a token returned from the HTTPS API Key = transaction to be included in the REGISTER to make sure that it came = from the approved app. =20 The RUE could reasonably construct a CRL, pass it to a provider, get a = cert back and use ACME to refresh it, all without any human interaction. = So I can see how to do certs. OAUTH is also obvious. =20 Brian From nobody Mon Nov 23 10:00:57 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 9E4943A0BE7 for ; Mon, 23 Nov 2020 10:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[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 IXm7MZPI6fCd for ; Mon, 23 Nov 2020 10:00:53 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2083.outbound.protection.outlook.com [40.107.93.83]) (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 CCF753A0BE3 for ; Mon, 23 Nov 2020 10:00:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NeRL8ckWEwlrv61KT5K7RhEseMjRjyYAUi5/AtbmKeBiBzEKjKwfv74zbtqrWafeGZZRw1Fpx/E+F+TrU7sYV1F6ZiHT1/yrkFPpXIUN5HDwk7yfqSUzn0X5msPjVpuuhfKczKLmCpyQBxDrW2AxGNMV7ZzlPOqAgPWme9Cgj9fJLGwSFAflQkHFbQcogA4+vU9YdZ26XnK+MrJZyqIkdeR9rbFHhe9khZO5Nol4VNzJuHk7ToRPZ864TkSDQvmN+9Iv6d0JgXpxaLoBcHLXZMG7GTwivm7AqJdNNFrVA2KA7sZAhdy4OlG2vt1k6zBSN3IPMMgHVceFxtPveruHUw== 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=aDnixUUqX6PdGKp0LOW8KOStFn63g0jglzlCKqC1kwM=; b=Zs5p+4WqWPWwMaIbEb2i6upKwWEJNHKcmvl8ViSbkhQu9Ar2TKnwb5lGaEXeXUtnYXl9StYO34BzxlV0vVtjYleWmBUssnMniUnfBDCb7MbrEdzx0OrwhYGab7Jac8eYocEfwyHo0wsVZcpXXSd6k7zz7fRuJwBONouwgkpNewnYoX/GrACIua22vzE1KRMaPLj2xFXsH6QRM+8ojq7Z9kkeFSVqMppmJZBlx6OUrkncjzeaMjolE7dAPY74JlVZnFF1wAQztpJWA3/cghvLGdDG/mTaDB+lic/8HGtka3OUy0COi16VcFLK+fdLBdbm/RO6B/+ZXdsKOOGTnqyegw== 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=aDnixUUqX6PdGKp0LOW8KOStFn63g0jglzlCKqC1kwM=; b=daYMEzGKig5WHCLPLRMR1jbgHbpvKRzxtgpUNeVAZbdnkYdDV1BPszQNgMQd+8+ajhtI6SggQSupT7eRDkTnmJBONtdFb+XgOsetJRieGUVk8lHJM5m05DvaoB53NjIG3ZYyKrSFWiaCMelQejZaO2XSJrgNYpvzi3mI2y1q3xw= Received: from CY4PR22CA0055.namprd22.prod.outlook.com (2603:10b6:903:ae::17) by DM5PR1201MB0057.namprd12.prod.outlook.com (2603:10b6:4:5b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.29; Mon, 23 Nov 2020 18:00:52 +0000 Received: from CY1NAM02FT039.eop-nam02.prod.protection.outlook.com (2603:10b6:903:ae:cafe::ec) by CY4PR22CA0055.outlook.office365.com (2603:10b6:903:ae::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Mon, 23 Nov 2020 18:00:52 +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 CY1NAM02FT039.mail.protection.outlook.com (10.152.75.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Mon, 23 Nov 2020 18:00:52 +0000 Received: from PaulKyzivatsMBP.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 0ANI0nwI020559 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 23 Nov 2020 13:00:50 -0500 To: rum@ietf.org References: <2F50A802-BC28-4A13-A9E1-A5271B642C1E@brianrosen.net> From: Paul Kyzivat Message-ID: <672cab99-8611-7a34-b962-284b90438fdb@alum.mit.edu> Date: Mon, 23 Nov 2020 13:00:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <2F50A802-BC28-4A13-A9E1-A5271B642C1E@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: bee8bc27-d324-4773-0176-08d88fd9b795 X-MS-TrafficTypeDiagnostic: DM5PR1201MB0057: 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: tJYdqXJauCSFlwrHZd+D3fKTfry6psMKVm3hePUDPWR+l6n8sUFDjiuf0GmdYHT0eeg1NWOdbCWDdtK4lWCjlfWlfsgwzDDM7XofNuGMEV8jMDfHHSCMuZpeJDVeXLomfQkPKMoNI06i6Dp/W9ZlkAAa1vmOWyJD41xJQaBnjUHwGL/v7fkg86M7nQb21EsFebHg4b9o4QKP29LwSRsmRTQW70UpIX9XvkLx5u6sl4L/aGIOxOpynkEw4gRI5eNg5DkzaFnRe9uZluhI+tC1P93wFydfLS/d5polBBwRiZFvZtRuXwt/R/qsSv+7+vwfuYVAIumuJdE08KOrk9guOZHHH1sZtmV/heg1VKW1U3t7kBnRS8FH+g5voSSN0Mus518ktVIVMkqWqkB3cjotCHX4NTAcQzY63WHVMuwcReqmd4oAsLtLcxFDukL7G+/G 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)(8936002)(83380400001)(8676002)(86362001)(6916009)(5660300002)(82310400003)(70586007)(70206006)(786003)(36906005)(7596003)(316002)(356005)(26005)(31696002)(31686004)(75432002)(47076004)(82740400003)(2616005)(478600001)(53546011)(956004)(186003)(336012)(2906002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2020 18:00:52.1277 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bee8bc27-d324-4773-0176-08d88fd9b795 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: CY1NAM02FT039.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1201MB0057 Archived-At: Subject: Re: [Rum] Username/password vs cert/OAUTH token 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, 23 Nov 2020 18:00:56 -0000 On 11/20/20 10:10 AM, Brian Rosen wrote: > In the RUM meeting, Olle suggested we leave username/password as authentication mechanism for SIP (and, he proposes, for the code authentication issue) behind, and use OAUTH tokens or certs. > > In thinking about this, it occurs to me that the way you authenticate to the OAUTH IDP is, wait for it, username and password, and the way you access a private key if it’s human based access, is a pass phrase. So, we might be improving the crypto a bit, but not the authentication strength. So, why do it? > > Most IDPs these days offer, and sometimes require MFA. That’s an improvement. Although it could be considered a SIP extension, something simple like appending a code to the password or hashing the password with a code would get us that if we wanted it. I’d actually prefer OAUTH, but I could see doing that for REGISTER, or for that matter HTTPS. I also note that the transaction to present the API Key doesn’t need user credentials, but if we didn’t use them, then we would need a token returned from the HTTPS API Key transaction to be included in the REGISTER to make sure that it came from the approved app. > > The RUE could reasonably construct a CRL, pass it to a provider, get a cert back and use ACME to refresh it, all without any human interaction. So I can see how to do certs. OAUTH is also obvious. ISTM that the way we are arranging things there is a non-sip step in authentication that always involves a human in real-time. Using OAUTH there seems good because it can push the logic off to some other entity whose choice is between the provider and the user. That is presumably to get to the configuration server. Then the configuration server hands back credentials for use in SIP. Currently we are handing back userid/pw there. But it could just as well be a token. Or we could allow that to be a choice made by the provider. There is also the issue of refreshing the configuration if something in it has changed. (E.g. a credential revocation.) That should be able to happen without the human. I guess that may be a reason to use OAUTH so that there can be a refresh token. Thanks, Paul From nobody Tue Nov 24 06:35:17 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 7E8F23A0E92 for ; Tue, 24 Nov 2020 06:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=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 p5WUPSfsq3Km for ; Tue, 24 Nov 2020 06:35:14 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2062.outbound.protection.outlook.com [40.107.223.62]) (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 B628C3A0E8E for ; Tue, 24 Nov 2020 06:35:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fR5afGTxT1/SaEQxObKFDkIHlfqhfsPjN2gkx5TiqYugsNw2rufAxEd6ZyPxITwoaUiK+9mIXsoF8p0kLsIwZvkDdJjKnVxdax9Ms41pP+IxjQlGs5+zZJbhbNmCj1IGQeRitCCak92OkPRlmgV5O0AEvzUql86uUugeZOMPwCRF6/GxCqJoKgDBb7wCX8F2Pwg39mDV05n1KMj7cUMvzqflHDsmhy0+EwY27uKN2yN6RDhFSqArKvkxuVnHD3yTgQRhdAY2nGr3i/yQU6JVUAXz4qcw8Wm2lNIZg7VydzKojxOA16pgIkmq5L44DMP4R7jpEm3KxW53H+DHrOzkmA== 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=PB2fjc25qQccD3jq33YuZBYPztnreuh2hW7fGhhj0a0=; b=L1LolTS7VwTSC+IfzhEiAUwxu90ElYsfs5dcgGwx2W4yEoQd++MR/igH4+Zy2RwqRnAbN+pGDzr0p4UOepxeZRVYJOkgv78Zurj/G45nJ3uFTFm+BNAxrMuOeiS13q/gnLX3jI76mAvpWI1zg5VUIVQfpi8R5XlfXxUj6al/8AsKLRRxnYSYrUWMhyMRA8rv4MvYHfDigoe+3TIeOUWzbx4VkuoIcAbOIc8W0q3SVnUliXmYhyP61O9UN9dx53yWAcLJQ1/UcekI+1EhLMh8vZPwiZ7Ea5g1AG5nQcP+IlAY/MjeKO1oS+FLFJKPSBo0gNxS3bPnrGIkR/MXKfxDLQ== 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=PB2fjc25qQccD3jq33YuZBYPztnreuh2hW7fGhhj0a0=; b=Zjw+0ReP42is4pQF6giIVfprdyNE6hC46uAB+QH4ddhTW1YS+zwFKbvIEMr/ABI39V/G87HSdQ9oWkNKcNHk3z6YBtuHlFuoCOFbGgZ7JhGOc2L9fG5FloGd3GlGMxndU7zORZ3q/HG3dCRk96DcDQiT5oPLnDLUm96jzcc+nCk= Received: from MN2PR16CA0045.namprd16.prod.outlook.com (2603:10b6:208:234::14) by DM5PR12MB1242.namprd12.prod.outlook.com (2603:10b6:3:6d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Tue, 24 Nov 2020 14:35:13 +0000 Received: from BL2NAM02FT006.eop-nam02.prod.protection.outlook.com (2603:10b6:208:234:cafe::7c) by MN2PR16CA0045.outlook.office365.com (2603:10b6:208:234::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Tue, 24 Nov 2020 14:35:13 +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 BL2NAM02FT006.mail.protection.outlook.com (10.152.76.239) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Tue, 24 Nov 2020 14:35:12 +0000 Received: from PaulKyzivatsMBP.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 0AOEZA2L007388 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 24 Nov 2020 09:35:12 -0500 To: "rum@ietf.org" From: Paul Kyzivat Message-ID: <06afeb72-ac39-285a-5cfe-3d9f75c7d186@alum.mit.edu> Date: Tue, 24 Nov 2020 09:35:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 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: 26734156-c4cf-4d1d-b8dd-08d890862726 X-MS-TrafficTypeDiagnostic: DM5PR12MB1242: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4714; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IZsvczWOS+uL2DrKAiT7fg4yBrsvUdmp9pOWxsRQt90G5EwhjBKTeoXMuPQiFkfPX4Imwoo/QkPugn462r6cswxsBWK5KpeoMM6w1SGeA1TExVACMBxDszjS/iYnB+1EMrLGxkRO34kzsdWTw8Xlog2+U8oQHOYVGXpQpg/10d1szrIgE4figamPwg6ltljYJfoBOGLBGrWwdwhthHYjvQSQNKakOvFkZuOxlOkDuPv8yksrZ3HzVq6NcyYoFdeq+YcIT/aju1+vECyiVrt4XDSfqq+0boQPW3UZUCc6UrUqCfGsKznM+7jjf5JUKhiob8aFKo2gIAwde2q5WuCcvoJvrRn4QykR/rzxPDXyXJTxdtWZz5tmOHEDZKSSKM6Oz2aTBaZBAN2ysI9PH4cROVVddVPOvPTVJ6/quSnzxxnRcMGU4Ym+Iu5kX+ReQ3xtNGzafBTsb3TdGXERd47qgPkxAJ/L0QHlkIOo9/5Vhp49XCOG1KTWeIyaLD02WCcZ 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)(136003)(39860400002)(396003)(46966005)(356005)(2616005)(956004)(7596003)(75432002)(82310400003)(5660300002)(2906002)(336012)(82740400003)(86362001)(47076004)(8676002)(7116003)(26005)(31696002)(3480700007)(36906005)(786003)(316002)(6916009)(8936002)(478600001)(70586007)(70206006)(31686004)(966005)(186003)(4744005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2020 14:35:12.9191 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 26734156-c4cf-4d1d-b8dd-08d890862726 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: BL2NAM02FT006.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1242 Archived-At: Subject: [Rum] Meeting minutes posted 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, 24 Nov 2020 14:35:17 -0000 I've posted minutes from our IETF 109 WG session. You can find them at: https://datatracker.ietf.org/meeting/109/materials/minutes-109-rum-01.pdf Many thanks to Jim Malloy for taking notes. These minutes are a lightly edited and reformatted version of his notes. Please let me know if there is anything you think should be revised or further elaborated. Thanks, Paul From nobody Tue Nov 24 08:10:49 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 929803A11D4 for ; Tue, 24 Nov 2020 08:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[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 QeCM5mpEw3vs for ; Tue, 24 Nov 2020 08:10:44 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 8D2163A11D0 for ; Tue, 24 Nov 2020 08:10:44 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id v143so20940854qkb.2 for ; Tue, 24 Nov 2020 08:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OsPV9uF7zOMQd/mTJQ6yVh6Exqcx5mFwSl8LLcSNEkE=; b=Vq+LncfvTi3C5PMrEXd7OfPpfSslzd4y2ghUHIx15d2wsai0HfpzImQdYwtsbudA6z Vf18y/R1F6uQfysb24CknlY87kN1M078bkFV+ZHYUwACUW6ImsI/l/z4PYJRO0dUE/6B ouXgN/PZ+10WwN8LZdaDw95za/nK9a6N5dQHQG06OMwJMdgpVdsWf05DZ5ggswCwvuEv MehqjmP+Tc7w5zwT6quotqHxy1ooVpLyfrQfu0ha4h8DHAdRrymSFRiel0uq95/m/xSX ZDN98NI9mMd/3JiVTZ8gEiZ8Jl6BcyQJJ4ffF6yAat5vXNWzIHdNdcZPtBX38MFSrBBG cZaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OsPV9uF7zOMQd/mTJQ6yVh6Exqcx5mFwSl8LLcSNEkE=; b=BBhKBLQdwt4i0VnoG9kiISTaBuQ7S4RiBVK8iEUiTViIJxAnXuCx8XVtZwwNoU/c2p xZnnpGgp8T8nDAkIJmH0ayPSNb5PMEylNWlfLvBnw5eh9mEfRttDObhdpWWtaNrbGQx9 dtezNAHUQKs14UuJ2VG9P6Dcu2mLuAJSXVpHp+yoQeSC5XeASLJi3eLR31QS/9xSUDJt DXEdwgXLd5hTlXFudi+NsZs4YKNPhHt/PK6RLrz3ICOX3zSTSqjHAVjEhmbFFJJQXWVI pvi6DhX7GGghyKqsOF0lGzbxefCM/pb7iaJnfQ6Ugg6f9xceKAWJsPiGIw6z847g6RCN YEpg== X-Gm-Message-State: AOAM5315+rToHYb1QHifPuay9jQi24vfT+HReqRDOgBJvRmmn2wrlfDr +xNQ30xrx3ZCt237s+AgAt0y/TZmNQVseZFx X-Google-Smtp-Source: ABdhPJyNKAFg1WfLkjZmtkDJyVgTbKuBBnKrxBh7B+2HgVvJLNarhGrVraApLv/fzqJZGX9KiteILw== X-Received: by 2002:a37:a58e:: with SMTP id o136mr5463876qke.290.1606234243633; Tue, 24 Nov 2020 08:10:43 -0800 (PST) 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 x21sm8377653qtb.14.2020.11.24.08.10.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Nov 2020 08:10:42 -0800 (PST) From: Brian Rosen Message-Id: <0D95D606-F858-4E86-BE4C-45C339DBD974@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_E200B6E3-676F-4423-A1F1-569A32D6679B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 24 Nov 2020 11:10:41 -0500 In-Reply-To: <672cab99-8611-7a34-b962-284b90438fdb@alum.mit.edu> Cc: rum@ietf.org To: Paul Kyzivat References: <2F50A802-BC28-4A13-A9E1-A5271B642C1E@brianrosen.net> <672cab99-8611-7a34-b962-284b90438fdb@alum.mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] Username/password vs cert/OAUTH token 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, 24 Nov 2020 16:10:48 -0000 --Apple-Mail=_E200B6E3-676F-4423-A1F1-569A32D6679B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think the problem is who runs the configuration server and who runs = the OAUTH IDP? The fundamental thing we are trying to do here is support multiple = accounts at different providers. We=E2=80=99re all agreeing that needs = to be secure, and in one way or another, the human user has to = authenticate, Maybe we should start at requirements: 1. Configuration is per provider 2. Multiple accounts at different providers must be supported 3. All information needed to connect to a provider must be in the = configuration 4. Some form of (human) user authentication is required (but the = question is when, see 5) 5. The mechanisms has to work over a power failure: after power is = restored, incoming calls have to be received 6. The mechanism must be secure (for example, stored password must be = encrypted in storage and transit) 7. As much as possible, the user should not have to enter configuration = data such as proxy server URIs, TURN server URIs, etc. ?More? Brian > On Nov 23, 2020, at 1:00 PM, Paul Kyzivat = wrote: >=20 > On 11/20/20 10:10 AM, Brian Rosen wrote: >> In the RUM meeting, Olle suggested we leave username/password as = authentication mechanism for SIP (and, he proposes, for the code = authentication issue) behind, and use OAUTH tokens or certs. >> In thinking about this, it occurs to me that the way you authenticate = to the OAUTH IDP is, wait for it, username and password, and the way you = access a private key if it=E2=80=99s human based access, is a pass = phrase. So, we might be improving the crypto a bit, but not the = authentication strength. So, why do it? >> Most IDPs these days offer, and sometimes require MFA. That=E2=80=99s = an improvement. Although it could be considered a SIP extension, = something simple like appending a code to the password or hashing the = password with a code would get us that if we wanted it. I=E2=80=99d = actually prefer OAUTH, but I could see doing that for REGISTER, or for = that matter HTTPS. I also note that the transaction to present the API = Key doesn=E2=80=99t need user credentials, but if we didn=E2=80=99t use = them, then we would need a token returned from the HTTPS API Key = transaction to be included in the REGISTER to make sure that it came = from the approved app. >> The RUE could reasonably construct a CRL, pass it to a provider, get = a cert back and use ACME to refresh it, all without any human = interaction. So I can see how to do certs. OAUTH is also obvious. >=20 > ISTM that the way we are arranging things there is a non-sip step in = authentication that always involves a human in real-time. Using OAUTH = there seems good because it can push the logic off to some other entity = whose choice is between the provider and the user. >=20 > That is presumably to get to the configuration server. Then the = configuration server hands back credentials for use in SIP. Currently we = are handing back userid/pw there. But it could just as well be a token. = Or we could allow that to be a choice made by the provider. >=20 > There is also the issue of refreshing the configuration if something = in it has changed. (E.g. a credential revocation.) That should be able = to happen without the human. I guess that may be a reason to use OAUTH = so that there can be a refresh token. >=20 > Thanks, > Paul >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_E200B6E3-676F-4423-A1F1-569A32D6679B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think the problem is who runs the configuration server and who runs the = OAUTH IDP?

The = fundamental thing we are trying to do here is support multiple accounts = at different providers.  We=E2=80=99re all agreeing that needs to = be secure, and in one way or another, the human user has to = authenticate,

Maybe we should start at requirements:
1. = Configuration is per provider
2. Multiple accounts = at different providers must be supported
3. All = information needed to connect to a provider must be in the = configuration
4. Some form of (human) user = authentication is required (but the question is when, see 5)
5. The mechanisms has to work over a power failure: after = power is restored, incoming calls have to be received
6. The mechanism must be secure (for example, stored password = must be encrypted in storage and transit)
7. As = much as possible, the user should not have to enter configuration data = such as proxy server URIs, TURN server URIs, etc.
?More?
Brian

On Nov 23, 2020, at 1:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 11/20/20 10:10 AM, Brian = Rosen wrote:
In = the RUM meeting, Olle suggested we leave username/password as = authentication mechanism for SIP (and, he proposes, for the code = authentication issue) behind, and use OAUTH tokens or certs.
In thinking about this, it occurs to me that the way you = authenticate to the OAUTH IDP is, wait for it, username and password, = and the way you access a private key if it=E2=80=99s human based access, = is a pass phrase.  So, we might be improving the crypto a bit, but = not the authentication strength.  So, why do it?
Most = IDPs these days offer, and sometimes require MFA.  That=E2=80=99s = an improvement. Although it could be considered a SIP extension, = something simple like appending a code to the password or hashing the = password with a code would get us that if we wanted it.  I=E2=80=99d = actually prefer OAUTH, but I could see doing that for REGISTER, or for = that matter HTTPS.  I also note that the transaction to present the = API Key doesn=E2=80=99t need user credentials, but if we didn=E2=80=99t = use them, then we would need a token returned from the HTTPS API Key = transaction to be included in the REGISTER to make sure that it came = from the approved app.
The RUE could reasonably construct = a CRL, pass it to a provider, get a cert back and use ACME to refresh = it, all without any human interaction.  So I can see how to do = certs. OAUTH is also obvious.

ISTM that the way we are = arranging things there is a non-sip step in authentication that always = involves a human in real-time. Using OAUTH there seems good because it = can push the logic off to some other entity whose choice is between the = provider and the user.

That is presumably to get to the configuration server. Then = the configuration server hands back credentials for use in SIP. = Currently we are handing back userid/pw there. But it could just as well = be a token. Or we could allow that to be a choice made by the = provider.

There is also = the issue of refreshing the configuration if something in it has = changed. (E.g. a credential revocation.) That should be able to happen = without the human. I guess that may be a reason to use OAUTH so that = there can be a refresh token.

= Thanks,
= Paul

-- 
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_E200B6E3-676F-4423-A1F1-569A32D6679B-- From nobody Tue Nov 24 08:43:11 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 007463A0C97 for ; Tue, 24 Nov 2020 08:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[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 cxI2M-ZNOBWc for ; Tue, 24 Nov 2020 08:43:07 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680067.outbound.protection.outlook.com [40.107.68.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 E84263A0934 for ; Tue, 24 Nov 2020 08:43:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jj/rju/7fX4OWJu/FEmjnVePzTOOKgIIzPEu9H0fyUMtoiIF2EZD4xYcj4omqf8s0tHmV3f/1mmiqJQdc4uZJKCGS49rgyGOfVD7uS2wJ4PXW1Fa8Qj17wqyVciilaXgS5xd09vsUYrtrpR6mfB6g9S1b7nkv3m+A++Gho5doBaRo5jNC0De41swNhZa+1vIr2jzaHBEQQu1n1jy5if5GGEdjDNejjQmbCtfMVAgYW9NZfsexUl1tSDOV2mRAqqGqHti4qBw90hyzCkGA/ruKulAfa8LKu/aRVxtd6dsabuHMIxmq3lz2/E3Xj/v+io4pTNN30WDrH02pU930u9UYQ== 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=x9uLkrsgNV7k2NuzXxcIQtYudVmH7hWqFzOFcQUwVe0=; b=KWNHtiuyfO2ouR8tZU00jAzB30YaqUYvUWXRv/AIEbW94zaVSzwDLSJbKyj/MZDXrauOd+Ktt68fXxnYspvlytcZIrINzc5AT40y+znvuafrEsJOCgGzaLWi5YqElzzNfyKAiLjimAX6gwzhN1pYUcZ5aR+aGVoiM0S9kuul3tQZ/Bh8/pom9OXv7hha8nnLEXvu6U9bLVzpWgEooRff5VkUzSHOa+JM14TAY0kzrEZp0T/NUQymereucJc4hf8oEXjWwnrnHKBOGvr81R+KkFO6Vt6n2R3t0UrQEeAlOSGCpUKTvG5DkTCG8TIQQdJh1xW9p1JPG8h74I1umJ7jBg== 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=x9uLkrsgNV7k2NuzXxcIQtYudVmH7hWqFzOFcQUwVe0=; b=fZMCKcGn0sB1NR5UVEdW1S+AYvHyShnNIR2PufCd0TChp17wQbsWOIp4XWLnGpjqdu2cb69/037f3hU2/YReZX3Hsp/e57F36gTjo60+Zqd4G32h7AXz3s7RKZdc2xu+Ce5HLEnsZij3yELqvsj2oq0YVmpeQ/PbjU+zgEK9BHY= Received: from DM6PR14CA0050.namprd14.prod.outlook.com (2603:10b6:5:18f::27) by DM5PR12MB1242.namprd12.prod.outlook.com (2603:10b6:3:6d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Tue, 24 Nov 2020 16:43:04 +0000 Received: from CY1NAM02FT039.eop-nam02.prod.protection.outlook.com (2603:10b6:5:18f:cafe::ed) by DM6PR14CA0050.outlook.office365.com (2603:10b6:5:18f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Tue, 24 Nov 2020 16:43:04 +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 CY1NAM02FT039.mail.protection.outlook.com (10.152.75.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Tue, 24 Nov 2020 16:43:04 +0000 Received: from PaulKyzivatsMBP.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 0AOGgw0X016283 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 24 Nov 2020 11:42:59 -0500 To: rum@ietf.org References: <2F50A802-BC28-4A13-A9E1-A5271B642C1E@brianrosen.net> <672cab99-8611-7a34-b962-284b90438fdb@alum.mit.edu> <0D95D606-F858-4E86-BE4C-45C339DBD974@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Tue, 24 Nov 2020 11:42:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <0D95D606-F858-4E86-BE4C-45C339DBD974@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: 9db64051-3dd3-4d74-d6c7-08d890980396 X-MS-TrafficTypeDiagnostic: DM5PR12MB1242: 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: QCDXF0PyTRaZVdWV87sCvXUFXRofs0gFpDXQEEzwah50VN9aNZ57fqqH7S1ihilQHRGF8ZcjbykYTP0kK2vs4CiW8EhVHd5k3vwfkXAWMNmQHdB1dUiHyMU0CanlNSyVMlpGJwxCfacfpAZzoN6JU8SV+/Cw6xVkVax5Es3NEiKt+F3UzKJV28uanpnKmXRakPENG/97jwVRRMmnY2B7nAca2X7O2G6hZdjKXrtmpXWco9skD+bcKESe/9rSaOhRTVeO9/Q8aujtxAhfTA31Q8988Ffmb7hSS89bj6vOI/NS4g3VivaMy+C20wuM2dMbQS38mR0lAsgmn9CymY0WRLyTDgD0XDVE13hgOtniH1uAGh58F63CL7Zwd5pnx7JVIIZTo8EnMFfuHR3Ms4zJam2/o4l91uGDuH4qvcpI0KA3/fxgWKI/ueJ7wlKi8T7WiDQ4mRkDKrBtQNUFuvkzUctjURLmGt+ZHl40zsTvIu17JK/9Ub/hD03/uW256w9D 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)(396003)(39860400002)(346002)(376002)(46966005)(316002)(786003)(31696002)(26005)(36906005)(70586007)(70206006)(31686004)(478600001)(53546011)(966005)(186003)(6916009)(8936002)(75432002)(956004)(7596003)(82310400003)(2616005)(336012)(82740400003)(86362001)(83380400001)(47076004)(8676002)(5660300002)(356005)(2906002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2020 16:43:04.0272 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9db64051-3dd3-4d74-d6c7-08d890980396 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: CY1NAM02FT039.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1242 Archived-At: Subject: Re: [Rum] Username/password vs cert/OAUTH token 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, 24 Nov 2020 16:43:09 -0000 Brian, On 11/24/20 11:10 AM, Brian Rosen wrote: > I think the problem is who runs the configuration server and who runs > the OAUTH IDP? > > The fundamental thing we are trying to do here is support multiple > accounts at different providers.  We’re all agreeing that needs to be > secure, and in one way or another, the human user has to authenticate, > > Maybe we should start at requirements: > 1. Configuration is per provider > 2. Multiple accounts at different providers must be supported > 3. All information needed to connect to a provider must be in the > configuration > 4. Some form of (human) user authentication is required (but the > question is when, see 5) > 5. The mechanisms has to work over a power failure: after power is > restored, incoming calls have to be received > 6. The mechanism must be secure (for example, stored password must be > encrypted in storage and transit) > 7. As much as possible, the user should not have to enter configuration > data such as proxy server URIs, TURN server URIs, etc. Good start. In addition to 7, I think there is an issue around credential revocation/reissue. If there is a need to issue new credentials (e.g., due to compromise of a cert or pw vault or just timeout of the credential), if user input is required then it needs to be arranged to be done when a human is available. (This needs more consideration.) Thanks, Paul > ?More? > Brian > >> On Nov 23, 2020, at 1:00 PM, Paul Kyzivat > > wrote: >> >> On 11/20/20 10:10 AM, Brian Rosen wrote: >>> In the RUM meeting, Olle suggested we leave username/password as >>> authentication mechanism for SIP (and, he proposes, for the code >>> authentication issue) behind, and use OAUTH tokens or certs. >>> In thinking about this, it occurs to me that the way you authenticate >>> to the OAUTH IDP is, wait for it, username and password, and the way >>> you access a private key if it’s human based access, is a pass >>> phrase.  So, we might be improving the crypto a bit, but not the >>> authentication strength.  So, why do it? >>> Most IDPs these days offer, and sometimes require MFA.  That’s an >>> improvement. Although it could be considered a SIP extension, >>> something simple like appending a code to the password or hashing the >>> password with a code would get us that if we wanted it.  I’d actually >>> prefer OAUTH, but I could see doing that for REGISTER, or for that >>> matter HTTPS.  I also note that the transaction to present the API >>> Key doesn’t need user credentials, but if we didn’t use them, then we >>> would need a token returned from the HTTPS API Key transaction to be >>> included in the REGISTER to make sure that it came from the approved app. >>> The RUE could reasonably construct a CRL, pass it to a provider, get >>> a cert back and use ACME to refresh it, all without any human >>> interaction.  So I can see how to do certs. OAUTH is also obvious. >> >> ISTM that the way we are arranging things there is a non-sip step in >> authentication that always involves a human in real-time. Using OAUTH >> there seems good because it can push the logic off to some other >> entity whose choice is between the provider and the user. >> >> That is presumably to get to the configuration server. Then the >> configuration server hands back credentials for use in SIP. Currently >> we are handing back userid/pw there. But it could just as well be a >> token. Or we could allow that to be a choice made by the provider. >> >> There is also the issue of refreshing the configuration if something >> in it has changed. (E.g. a credential revocation.) That should be able >> to happen without the human. I guess that may be a reason to use OAUTH >> so that there can be a refresh token. >> >> Thanks, >> Paul >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> > > From nobody Tue Nov 24 09:23:43 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 6524F3A0A9C for ; Tue, 24 Nov 2020 09:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=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 KePM3LtEDBgl for ; Tue, 24 Nov 2020 09:23:39 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) (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 0C81B3A0A2C for ; Tue, 24 Nov 2020 09:23:38 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6DCB76C0055; Tue, 24 Nov 2020 12:23:37 -0500 (EST) Received: from smtprhmv1.mitre.org (unknown [128.29.154.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvmsrv1.mitre.org (Postfix) with ESMTPS id CA3A86C0050; Tue, 24 Nov 2020 12:23:36 -0500 (EST) Received: from mwfesmtp-mgt.mitre.org (mwfesmtp-in.mitre.org [192.52.194.235]) by smtprhmv1.mitre.org (Postfix) with ESMTP id AFA4A941202; Tue, 24 Nov 2020 12:23:36 -0500 (EST) Received: by mwfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4CgW884q9bz3DZDB; Tue, 24 Nov 2020 17:22:39 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2109.outbound.protection.outlook.com [104.47.64.109]) by mwfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4CgW705GTTz29q4c; Tue, 24 Nov 2020 17:22:35 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jHKx6Q9uGfMIRNbRkpVbWwhiffMGah5+Q6fvw7wR+7Ca0+XXOTc4wpKg8mE2iS04QIRKUCA/2LpzoSZ5pefcPLaR19S/8la5ntF/CsmATk/ej/hNr1vvqBar+IpLx0EEpCfChLbEy78TYpl3sB7sFByZWa/3yWUXm7odCqhpPnlmOE2u8v/h3eGLsgodciKbGyfPHbIr1PdA8yS/fMqukep/ADoFMs6sb/r65G2s+PLcbJZPRpsdYpNyotfGzttjoLilWzI2WmHp/+6ewW3RIiRtHjWYcAcuDtkH9JxphS2aARAV/qHnIUH0UmnYgE0M7FM19047PO8Neefqw/iCkg== 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=+m+NTjNrDsvCpzHawOYUVehoFEp8RGdwSESESEGMXiM=; b=QpmduuQV4jlMGAx8MrjMpBhd7jXGbGMfTAL/xS6xvKP9rLyYjr6auz2mB5Nn/Ci5/l/YFcf5ZdqXnr2T1wZHy1f+ewWZxtfWSkOh/17e2Q/8qKkWCggH0yGMygEbjJlZKeDxb0k+VZgTVHMkOw9EfsmmTXaMjndxPpRhZPKDIpRPdNeA3qw7OU8iuhmT34g0NQmLsM7oTdwPxKPporSD7r+3lvl74LBRJvrrmaV2Mq7haHkSDrufsakwFGtwpHALDXMjxgfk2FA8qnnxo7Ecatqu2WCD+OFgpavmMfVYWbgBmAX9Zrgmz3oOlAuNskQAL5BrQXpw/Nifu8fHH3FmCw== 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 BLAPR09MB6644.namprd09.prod.outlook.com (2603:10b6:208:2a7::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Tue, 24 Nov 2020 17:22:35 +0000 Received: from MN2PR09MB5948.namprd09.prod.outlook.com ([fe80::a5ed:2d3d:94fa:3d99]) by MN2PR09MB5948.namprd09.prod.outlook.com ([fe80::a5ed:2d3d:94fa:3d99%7]) with mapi id 15.20.3589.030; Tue, 24 Nov 2020 17:22:35 +0000 From: Jim Malloy To: Brian Rosen , "Kyzivat, Paul" CC: "rum@ietf.org" Thread-Topic: [EXT] Re: [Rum] Username/password vs cert/OAUTH token Thread-Index: AQHWwnxaBrZSxdMP00SOa1FZIOUyLKnXgTcg Date: Tue, 24 Nov 2020 17:22:34 +0000 Message-ID: References: <2F50A802-BC28-4A13-A9E1-A5271B642C1E@brianrosen.net> <672cab99-8611-7a34-b962-284b90438fdb@alum.mit.edu> <1691_1606234251_5FBD308B_1691_100_1_0D95D606-F858-4E86-BE4C-45C339DBD974@brianrosen.net> In-Reply-To: <1691_1606234251_5FBD308B_1691_100_1_0D95D606-F858-4E86-BE4C-45C339DBD974@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=mitre.org; x-originating-ip: [192.80.55.88] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4efaa3bf-3ae7-418e-cf81-08d8909d88b6 x-ms-traffictypediagnostic: BLAPR09MB6644: x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr 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: 6UM1mTfAG/z2f+8Bzxhx1/lLMiBFIyqDbNNE6pSNV06s3b/rDDWrW56xAtpzP8avVzb772SavuW7GmW7LOaXgEQxYrhgctyC36FaMheuSQ5PvyyE62JuMQs5O2f8uNz726lXN5zXmOOIsqdlEDPh5hukvaY0aWSGQueh9YULwq1nxp9DOYzWLADslrasqzNwtbQjpnjwQrjQCUO8ywPAHijJVK7YB5yYW39YmYbsZfVkQGD7Yk9vqHG8irHcXmRF5pW9VBP0MQv+Xp/TNAZE+NCPXqH3TcLjdXnxZ43Kd2XiFFuUMR4Me4eEe6UA5E3o2HdmrqRnc5rMr94/PB3K34TS+Zt8kT9xTYD6FH2iHDCbMxbisYTDEbTSqwVSPs6yXTF/vyxa5bdGmcfCgIbirQ== 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:(376002)(346002)(39860400002)(396003)(366004)(136003)(55016002)(8676002)(186003)(66574015)(966005)(2906002)(316002)(76116006)(26005)(83380400001)(71200400001)(9686003)(66946007)(5660300002)(7696005)(53546011)(4326008)(6506007)(66476007)(166002)(86362001)(478600001)(33656002)(110136005)(8936002)(52536014)(66556008)(66446008)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?cHpkWmpNaTdUNmdlYTB5NjI0QkNqeGx0OUE5ZzBYVFIvZ0luL0ZsaUF5V0Zs?= =?utf-8?B?c0U3OUZJVk16eVVhaHUzRW5aQzEzVUV5SXE5SVBKbFlJaWcvK0NtM1F5UmhJ?= =?utf-8?B?NVVPK1lKVVRvL2NVT3poeHg3TnQzNGxTOG1LVkloMG9wVmc5bnJYblhXRGlI?= =?utf-8?B?dnB4aTVFMVJpNlp3K0hPUklqZmlmU0J4WkhZVUJ2UG5GWWt0ajhFUEJVbW9O?= =?utf-8?B?MHRNSENyZGI2VUwra3o5djd0em1HYUx0eUY0ODN2K0JKdGo4bVF2QVlIcUhS?= =?utf-8?B?dmdYUVpnUWx2TDlJMWhLTUlNWWhHTDFyMjNUTVdPb0FsTS9wQk9QY0FIYm5y?= =?utf-8?B?U2huUFVpa28vcDBxcDZjTzltVExRNzJTZkxLOHEwekJXTHJleWVXQllSeFBx?= =?utf-8?B?SFNQbmREbERlRWRZaXllWGZqMUJCNEtOUi93ZjU0Q3hScExKUElpMWRTbFRz?= =?utf-8?B?WGw3Si80c0xpVS9qRnB1TzZlNHdpaGdBdHRmWDRaQm9ld05ER1pJVERLam1p?= =?utf-8?B?M2x0TFA1ejFQRVduS0N6UHFUTzZvb3RaTEI1TmEzVG53UmZSYWJ3ZHdOSnBR?= =?utf-8?B?aVdoamdtay9iMi8rZWZrTTl0enJVSUtLeTkvdzZVNmhEbkZnQUhyampRL1RI?= =?utf-8?B?b0wzbzlWYWtJK1g5TFdiaWlKWUM0b3pOUjk2VFBqdmFBeHluRm1mVEVxRzRs?= =?utf-8?B?SHB4SjlLZzMyK1FVbE9jQXMra0JXeTYyWVVCYjM4MUI3cXVHZUZwOEhTb3JT?= =?utf-8?B?NEE0K08yakFDWCtLS0dKZWYzZDRhMU1mR21EdGJWZjFNdFdQZE1Da2VuZVZS?= =?utf-8?B?aW14MmFYQkJBWlliakUxeHI3UVhhcVI1M1ZuRHc4V3JIMEFSWk9kTktGay9n?= =?utf-8?B?VzdyWEJPVUVtQU8vYXUzV05aeWRia0xnWmpNM0gzNUgyYVZmVHdEQXgzL1N1?= =?utf-8?B?M0VUeVZrSnNHN2NXQXdjT3ZHdllUelFrY3huVWhIbGt2VHo1VEZCZFlQLy9k?= =?utf-8?B?T1p2M0YrU0VZMHlYSXcwa0o1T1ljVlhnbC8wMDMwWVRkRGdsV3pXNjFmOWJZ?= =?utf-8?B?RzBqODMxNnRBRWZEUnhnVU84TFM1VVhXM0tMTkc3Vjc0ZUNOTEhEekFtM0kx?= =?utf-8?B?R1h5bndMUmZESENNdlRjaVFNckZIcFhFdkd4NHVMSXVhZDc1TTI3OFF5V1FY?= =?utf-8?B?ZTFNRHcrbWZ2RDdTZldMeU5Tb1I4Vjlaa0E1V1VSRGdQNEhzT1EwZXp2OXky?= =?utf-8?B?eEhKWWg1OFBTOVVsOURWL0luMGo1WlRGbHF5QjlkQTZBa21CRUg5L1h3WGdk?= =?utf-8?Q?DE/4eXXhTAOC0=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR09MB5948215AEF1814D683FAA8FDB9FB0MN2PR09MB5948namp_" 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: 4efaa3bf-3ae7-418e-cf81-08d8909d88b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 17:22:35.0125 (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: QbNaxvoKZxBlDWDgEpISFOeZPBhT2JdDeHHczshzoNnQ2nKz6hwpWB/QtegqyY7toH5xUkDqyVXJ3kfS7Wf5Lw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6644 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:mime-version; s=selector1; bh=+m+NTjNrDsvCpzHawOYUVehoFEp8RGdwSESESEGMXiM=; b=rpbNFa7N6/PNQsW7I0GkaArlSV0nzYf6aJv/BacFJHCaEbAnNIteyLB3O1mAL4WGXbFyDjCkKz7ouTuG/sGmSGcQ1QvYvLtBdbCNCnpTVlcnX5v3UCO5/tcum2zuXHjPIbqM6thUct3KS6WiPn6JJD3JhbxEAbKYnJr42UPVyZQ= Archived-At: Subject: Re: [Rum] [EXT] Re: Username/password vs cert/OAUTH token 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, 24 Nov 2020 17:23:41 -0000 --_000_MN2PR09MB5948215AEF1814D683FAA8FDB9FB0MN2PR09MB5948namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgYmVsb3cgaW4ge30NCg0KLS1KaW0NCg0KSSB0aGluayB0aGUgcHJvYmxlbSBpcyB3 aG8gcnVucyB0aGUgY29uZmlndXJhdGlvbiBzZXJ2ZXIgYW5kIHdobyBydW5zIHRoZSBPQVVUSCBJ RFA/DQoNClRoZSBmdW5kYW1lbnRhbCB0aGluZyB3ZSBhcmUgdHJ5aW5nIHRvIGRvIGhlcmUgaXMg c3VwcG9ydCBtdWx0aXBsZSBhY2NvdW50cyBhdCBkaWZmZXJlbnQgcHJvdmlkZXJzLiAgV2XigJly ZSBhbGwgYWdyZWVpbmcgdGhhdCBuZWVkcyB0byBiZSBzZWN1cmUsIGFuZCBpbiBvbmUgd2F5IG9y IGFub3RoZXIsIHRoZSBodW1hbiB1c2VyIGhhcyB0byBhdXRoZW50aWNhdGUsDQoNCk1heWJlIHdl IHNob3VsZCBzdGFydCBhdCByZXF1aXJlbWVudHM6DQoxLiBDb25maWd1cmF0aW9uIGlzIHBlciBw cm92aWRlcg0KMi4gTXVsdGlwbGUgYWNjb3VudHMgYXQgZGlmZmVyZW50IHByb3ZpZGVycyBtdXN0 IGJlIHN1cHBvcnRlZA0KDQp7DQpZZXMg4oCTIGFuZCBjb25maWd1cmF0aW9ucyBzaG91bGQgYmUg cHVsbGVkIGZyb20gZWFjaCBwcm92aWRlciBpbmRlcGVuZGVudGx5LiBUaGVyZSBpcyBubyByZWFz b24gZm9yIGFueSBwcm92aWRlciB0byBoYXZlIHZpc2liaWxpdHkgaW50byBhbm90aGVyIHByb3Zp ZGVy4oCZcyBpbmZvcm1hdGlvbg0KfQ0KMy4gQWxsIGluZm9ybWF0aW9uIG5lZWRlZCB0byBjb25u ZWN0IHRvIGEgcHJvdmlkZXIgbXVzdCBiZSBpbiB0aGUgY29uZmlndXJhdGlvbg0KNC4gU29tZSBm b3JtIG9mIChodW1hbikgdXNlciBhdXRoZW50aWNhdGlvbiBpcyByZXF1aXJlZCAoYnV0IHRoZSBx dWVzdGlvbiBpcyB3aGVuLCBzZWUgNSkNCg0Kew0KU2luY2UgdGhlIOKAnHB1bGzigJ0gaXMgb24g YSBwZXItcHJvdmlkZXIgYmFzaXMsIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBhbHNvIG9uIGEgcGVy LXByb3ZpZGVyIGJhc2lzLiAgSGV3IChhbmQgd2hlbikgZG8gcHJvdmlkZXJzIHJlcXVpcmUgYXV0 aGVudGljYXRpb24gb24gbW9iaWxlIGRldmljZXMgb3IgZGVkaWNhdGVkIGhhcmR3YXJlIHRvZGF5 PyBJIHN1c3BlY3QgdGhlIGFuc3dlcnMgZGlmZmVyIGJldHdlZW4gcHJvdmlkZXJzIGFuZCBhY3Jv c3MgZGV2aWNlIHR5cGVzLg0KDQpXaGlsZSBJIGFncmVlIHdpdGggT2xsZeKAmXMgc2VudGltZW50 IHRoYXQgdGhlIFJGQyBzaG91bGQgbm90IGxpbWl0IGF1dGhlbnRpY2F0aW9uIHRvIHRoZSDigJxh cy1pc+KAnSBtZWNoYW5pc21zIGluIHVzZSB0b2RheSwgaXQgaXMgaW1wb3J0YW50IHRvIHByb3Zp ZGUgYSBtaWdyYXRpb24gcGF0aCBmcm9tIGV4aXN0aW5nIG1lY2hhbmlzbXMgdG8gY3VycmVudGx5 IGFjY2VwdGFibGUgKGFuZCwgd2hlcmUgcG9zc2libGUsIGZ1dHVyZSkgbWVjaGFuaXNtcy4gIE1v c3QsIGlmIG5vdCBhbGwsIGN1cnJlbnQgVVMgVlJTIHByb3ZpZGVycyByZWx5IG9uIHVzZXJuYW1l L3Bhc3N3b3JkIHBhaXJzIGZvciB1c2VyIGF1dGhlbnRpY2F0aW9uLg0KfQ0KDQo1LiBUaGUgbWVj aGFuaXNtcyBoYXMgdG8gd29yayBvdmVyIGEgcG93ZXIgZmFpbHVyZTogYWZ0ZXIgcG93ZXIgaXMg cmVzdG9yZWQsIGluY29taW5nIGNhbGxzIGhhdmUgdG8gYmUgcmVjZWl2ZWQNCg0Kew0KSG93IGRv IHByb3ZpZGVycyBhY2NvbXBsaXNoIHRoaXMgdG9kYXk/ICBIb3cgZG8gb3RoZXIsIGNvbXBhcmFi bGUsIHNlcnZpY2VzIGhhbmRsZSB0aGlzIHRvZGF5PyAgU2VjdGlvbiA5IHN0YXRlcyDigJxBIFJV RSBkZXZpY2UgbWF5IHJldHJpZXZlIGEgY29uZmlndXJhdGlvbiBmcm9tIGEgcHJvdmlzaW9uZWQg VVJMIHVzaW5nIEhUVFBz4oCdLiBFdmVyeSBicm93c2VyIEkgdXNlIHNlZW1zIHRvIGJlIGFibGUg dG8gcmVtZW1iZXIgdGhhdCBJIGhhdmUgY3JlZGVudGlhbHMgZm9yIG11bHRpcGxlIHNpdGVzIChi dXQgbm90IG15IGJhbmsgb3IgaW5zdXJhbmNlIHByb3ZpZGVyKSB3aXRob3V0IGFueSBkaWZmaWN1 bHR5LiAgQ2FuIHdlIHNwZWNpZnkgd2hhdGV2ZXIgbWVjaGFuaXNtcyBhcmUgY29tbW9ubHkgaW4g dXNlIHRvZGF5Pw0KfQ0KDQo2LiBUaGUgbWVjaGFuaXNtIG11c3QgYmUgc2VjdXJlIChmb3IgZXhh bXBsZSwgc3RvcmVkIHBhc3N3b3JkIG11c3QgYmUgZW5jcnlwdGVkIGluIHN0b3JhZ2UgYW5kIHRy YW5zaXQpDQo3LiBBcyBtdWNoIGFzIHBvc3NpYmxlLCB0aGUgdXNlciBzaG91bGQgbm90IGhhdmUg dG8gZW50ZXIgY29uZmlndXJhdGlvbiBkYXRhIHN1Y2ggYXMgcHJveHkgc2VydmVyIFVSSXMsIFRV Uk4gc2VydmVyIFVSSXMsIGV0Yy4NCg0Kew0KVGhlIHR3by10aWVyZWQgY29uZmlndXJhdGlvbiBy ZXRyaWV2YWwgb3V0bGluZWQgaW4gdGhlIGRvY3VtZW50IHNob3VsZCBlbGltaW5hdGUgdGhlIG5l ZWQgZm9yIGFueSBvZiB0aGUgaW5mb3JtYXRpb24geW91IGxpc3RlZCB0byBiZSBtYW51YWxseSBl bnRlcmVkLg0KDQpTZWN0aW9uIDkuMSwgIFJVRSBQcm92aWRlciBTZWxlY3Rpb24sIG91dGxpbmVz IGEgUHJvdmlkZXIgbGlzdCB3aGljaCB3b3VsZCBiZSBtYWludGFpbmVkIGJ5IGEgc2luZ2xlIGF1 dGhvcml0YXRpdmUgc291cmNlIChwZXJoYXBzIHRoZSBGQ0Mgb3IgdGhlaXIgZGVzaWduZWUgZm9y IHRoZSBVbml0ZWQgU3RhdGVzKS4gIFRoaXMgbGlzdCBwcm92aWRlcyBhIG1pbmltYWwgc2V0IG9m IGluZm9ybWF0aW9uIHBlciBwcm92aWRlciB0byBzdXBwbHkgdGhlIFJVRSB3aXRoIGEgbGlzdCBv ZiBQcm92aWRlcnMgdGhhdCBjYW4gYmUgY29udGFjdGVkLg0KDQpTZWN0aW9uIDkuMiwgUlVFIENv bmZpZ3VyYXRpb24gU2VydmljZSwgX3Nob3VsZF8gY29udGFpbiBhbmQgcmVxdWlyZWQgY29uZmln dXJhdGlvbiBpbmZvcm1hdGlvbiBmb3IgdGhlIHVzZXIgdG8gYWNjZXNzIGEgc3BlY2lmaWMgcHJv dmlkZXLigJlzIHNlcnZpY2UuICBJZiB0aGVyZSBpcyBzb21ldGhpbmcgbWlzc2luZywgd2Ugc2hv dWxkIGFkZCBpdC4NCn0NCg0KDQoNCj9Nb3JlPw0KQnJpYW4NCg0KDQpPbiBOb3YgMjMsIDIwMjAs IGF0IDE6MDAgUE0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PG1haWx0bzpw a3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCg0KT24gMTEvMjAvMjAgMTA6MTAgQU0sIEJy aWFuIFJvc2VuIHdyb3RlOg0KDQpJbiB0aGUgUlVNIG1lZXRpbmcsIE9sbGUgc3VnZ2VzdGVkIHdl IGxlYXZlIHVzZXJuYW1lL3Bhc3N3b3JkIGFzIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBmb3Ig U0lQIChhbmQsIGhlIHByb3Bvc2VzLCBmb3IgdGhlIGNvZGUgYXV0aGVudGljYXRpb24gaXNzdWUp IGJlaGluZCwgYW5kIHVzZSBPQVVUSCB0b2tlbnMgb3IgY2VydHMuDQpJbiB0aGlua2luZyBhYm91 dCB0aGlzLCBpdCBvY2N1cnMgdG8gbWUgdGhhdCB0aGUgd2F5IHlvdSBhdXRoZW50aWNhdGUgdG8g dGhlIE9BVVRIIElEUCBpcywgd2FpdCBmb3IgaXQsIHVzZXJuYW1lIGFuZCBwYXNzd29yZCwgYW5k IHRoZSB3YXkgeW91IGFjY2VzcyBhIHByaXZhdGUga2V5IGlmIGl04oCZcyBodW1hbiBiYXNlZCBh Y2Nlc3MsIGlzIGEgcGFzcyBwaHJhc2UuICBTbywgd2UgbWlnaHQgYmUgaW1wcm92aW5nIHRoZSBj cnlwdG8gYSBiaXQsIGJ1dCBub3QgdGhlIGF1dGhlbnRpY2F0aW9uIHN0cmVuZ3RoLiAgU28sIHdo eSBkbyBpdD8NCk1vc3QgSURQcyB0aGVzZSBkYXlzIG9mZmVyLCBhbmQgc29tZXRpbWVzIHJlcXVp cmUgTUZBLiAgVGhhdOKAmXMgYW4gaW1wcm92ZW1lbnQuIEFsdGhvdWdoIGl0IGNvdWxkIGJlIGNv bnNpZGVyZWQgYSBTSVAgZXh0ZW5zaW9uLCBzb21ldGhpbmcgc2ltcGxlIGxpa2UgYXBwZW5kaW5n IGEgY29kZSB0byB0aGUgcGFzc3dvcmQgb3IgaGFzaGluZyB0aGUgcGFzc3dvcmQgd2l0aCBhIGNv ZGUgd291bGQgZ2V0IHVzIHRoYXQgaWYgd2Ugd2FudGVkIGl0LiAgSeKAmWQgYWN0dWFsbHkgcHJl ZmVyIE9BVVRILCBidXQgSSBjb3VsZCBzZWUgZG9pbmcgdGhhdCBmb3IgUkVHSVNURVIsIG9yIGZv ciB0aGF0IG1hdHRlciBIVFRQUy4gIEkgYWxzbyBub3RlIHRoYXQgdGhlIHRyYW5zYWN0aW9uIHRv IHByZXNlbnQgdGhlIEFQSSBLZXkgZG9lc27igJl0IG5lZWQgdXNlciBjcmVkZW50aWFscywgYnV0 IGlmIHdlIGRpZG7igJl0IHVzZSB0aGVtLCB0aGVuIHdlIHdvdWxkIG5lZWQgYSB0b2tlbiByZXR1 cm5lZCBmcm9tIHRoZSBIVFRQUyBBUEkgS2V5IHRyYW5zYWN0aW9uIHRvIGJlIGluY2x1ZGVkIGlu IHRoZSBSRUdJU1RFUiB0byBtYWtlIHN1cmUgdGhhdCBpdCBjYW1lIGZyb20gdGhlIGFwcHJvdmVk IGFwcC4NClRoZSBSVUUgY291bGQgcmVhc29uYWJseSBjb25zdHJ1Y3QgYSBDUkwsIHBhc3MgaXQg dG8gYSBwcm92aWRlciwgZ2V0IGEgY2VydCBiYWNrIGFuZCB1c2UgQUNNRSB0byByZWZyZXNoIGl0 LCBhbGwgd2l0aG91dCBhbnkgaHVtYW4gaW50ZXJhY3Rpb24uICBTbyBJIGNhbiBzZWUgaG93IHRv IGRvIGNlcnRzLiBPQVVUSCBpcyBhbHNvIG9idmlvdXMuDQoNCklTVE0gdGhhdCB0aGUgd2F5IHdl IGFyZSBhcnJhbmdpbmcgdGhpbmdzIHRoZXJlIGlzIGEgbm9uLXNpcCBzdGVwIGluIGF1dGhlbnRp Y2F0aW9uIHRoYXQgYWx3YXlzIGludm9sdmVzIGEgaHVtYW4gaW4gcmVhbC10aW1lLiBVc2luZyBP QVVUSCB0aGVyZSBzZWVtcyBnb29kIGJlY2F1c2UgaXQgY2FuIHB1c2ggdGhlIGxvZ2ljIG9mZiB0 byBzb21lIG90aGVyIGVudGl0eSB3aG9zZSBjaG9pY2UgaXMgYmV0d2VlbiB0aGUgcHJvdmlkZXIg YW5kIHRoZSB1c2VyLg0KDQpUaGF0IGlzIHByZXN1bWFibHkgdG8gZ2V0IHRvIHRoZSBjb25maWd1 cmF0aW9uIHNlcnZlci4gVGhlbiB0aGUgY29uZmlndXJhdGlvbiBzZXJ2ZXIgaGFuZHMgYmFjayBj cmVkZW50aWFscyBmb3IgdXNlIGluIFNJUC4gQ3VycmVudGx5IHdlIGFyZSBoYW5kaW5nIGJhY2sg dXNlcmlkL3B3IHRoZXJlLiBCdXQgaXQgY291bGQganVzdCBhcyB3ZWxsIGJlIGEgdG9rZW4uIE9y IHdlIGNvdWxkIGFsbG93IHRoYXQgdG8gYmUgYSBjaG9pY2UgbWFkZSBieSB0aGUgcHJvdmlkZXIu DQoNClRoZXJlIGlzIGFsc28gdGhlIGlzc3VlIG9mIHJlZnJlc2hpbmcgdGhlIGNvbmZpZ3VyYXRp b24gaWYgc29tZXRoaW5nIGluIGl0IGhhcyBjaGFuZ2VkLiAoRS5nLiBhIGNyZWRlbnRpYWwgcmV2 b2NhdGlvbi4pIFRoYXQgc2hvdWxkIGJlIGFibGUgdG8gaGFwcGVuIHdpdGhvdXQgdGhlIGh1bWFu LiBJIGd1ZXNzIHRoYXQgbWF5IGJlIGEgcmVhc29uIHRvIHVzZSBPQVVUSCBzbyB0aGF0IHRoZXJl IGNhbiBiZSBhIHJlZnJlc2ggdG9rZW4uDQoNCiAgICAgICAgICAgICAgIFRoYW5rcywNCiAgICAg ICAgICAgICAgIFBhdWwNCg0KLS0NClJ1bSBtYWlsaW5nIGxpc3QNClJ1bUBpZXRmLm9yZzxtYWls dG86UnVtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dW0NCg0K --_000_MN2PR09MB5948215AEF1814D683FAA8FDB9FB0MN2PR09MB5948namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzIGJlbG93IGluIHt9PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tSmltPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIHByb2JsZW0g aXMgd2hvIHJ1bnMgdGhlIGNvbmZpZ3VyYXRpb24gc2VydmVyIGFuZCB3aG8gcnVucyB0aGUgT0FV VEggSURQPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IGZ1bmRhbWVudGFsIHRoaW5nIHdlIGFyZSB0cnlpbmcgdG8gZG8gaGVyZSBpcyBzdXBwb3J0IG11 bHRpcGxlIGFjY291bnRzIGF0IGRpZmZlcmVudCBwcm92aWRlcnMuICZuYnNwO1dl4oCZcmUgYWxs IGFncmVlaW5nIHRoYXQgbmVlZHMgdG8gYmUgc2VjdXJlLCBhbmQgaW4gb25lIHdheSBvciBhbm90 aGVyLCB0aGUgaHVtYW4gdXNlciBoYXMgdG8gYXV0aGVudGljYXRlLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSB3ZSBzaG91bGQgc3Rh cnQgYXQgcmVxdWlyZW1lbnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+MS4gQ29uZmlndXJhdGlvbiBpcyBwZXIgcHJvdmlkZXI8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIE11bHRpcGxlIGFj Y291bnRzIGF0IGRpZmZlcmVudCBwcm92aWRlcnMgbXVzdCBiZSBzdXBwb3J0ZWQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+ezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVz IOKAkyBhbmQgY29uZmlndXJhdGlvbnMgc2hvdWxkIGJlIHB1bGxlZCBmcm9tIGVhY2ggcHJvdmlk ZXIgaW5kZXBlbmRlbnRseS4gVGhlcmUgaXMgbm8gcmVhc29uIGZvciBhbnkgcHJvdmlkZXIgdG8g aGF2ZSB2aXNpYmlsaXR5IGludG8gYW5vdGhlciBwcm92aWRlcuKAmXMgaW5mb3JtYXRpb248bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPn08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+My4gQWxsIGluZm9ybWF0aW9uIG5lZWRlZCB0byBjb25uZWN0IHRvIGEgcHJv dmlkZXIgbXVzdCBiZSBpbiB0aGUgY29uZmlndXJhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4gU29tZSBmb3JtIG9mIChodW1hbikgdXNl ciBhdXRoZW50aWNhdGlvbiBpcyByZXF1aXJlZCAoYnV0IHRoZSBxdWVzdGlvbiBpcyB3aGVuLCBz ZWUgNSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2luY2UgdGhlIOKAnHB1bGzigJ0gaXMgb24gYSBwZXItcHJvdmlkZXIgYmFz aXMsIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBhbHNvIG9uIGEgcGVyLXByb3ZpZGVyIGJhc2lzLiZu YnNwOyBIZXcgKGFuZCB3aGVuKSBkbyBwcm92aWRlcnMgcmVxdWlyZSBhdXRoZW50aWNhdGlvbiBv biBtb2JpbGUgZGV2aWNlcyBvciBkZWRpY2F0ZWQgaGFyZHdhcmUgdG9kYXk/IEkgc3VzcGVjdCB0 aGUgYW5zd2VycyBkaWZmZXIgYmV0d2VlbiBwcm92aWRlcnMNCiBhbmQgYWNyb3NzIGRldmljZSB0 eXBlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgSSBhZ3JlZSB3aXRoIE9sbGXigJlz IHNlbnRpbWVudCB0aGF0IHRoZSBSRkMgc2hvdWxkIG5vdCBsaW1pdCBhdXRoZW50aWNhdGlvbiB0 byB0aGUg4oCcYXMtaXPigJ0gbWVjaGFuaXNtcyBpbiB1c2UgdG9kYXksIGl0IGlzIGltcG9ydGFu dCB0byBwcm92aWRlIGEgbWlncmF0aW9uIHBhdGggZnJvbSBleGlzdGluZyBtZWNoYW5pc21zIHRv IGN1cnJlbnRseSBhY2NlcHRhYmxlIChhbmQsIHdoZXJlIHBvc3NpYmxlLA0KIGZ1dHVyZSkgbWVj aGFuaXNtcy4mbmJzcDsgTW9zdCwgaWYgbm90IGFsbCwgY3VycmVudCBVUyBWUlMgcHJvdmlkZXJz IHJlbHkgb24gdXNlcm5hbWUvcGFzc3dvcmQgcGFpcnMgZm9yIHVzZXIgYXV0aGVudGljYXRpb24u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj59PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUuIFRoZSBtZWNoYW5pc21zIGhhcyB0byB3b3JrIG92ZXIg YSBwb3dlciBmYWlsdXJlOiBhZnRlciBwb3dlciBpcyByZXN0b3JlZCwgaW5jb21pbmcgY2FsbHMg aGF2ZSB0byBiZSByZWNlaXZlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj57PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgZG8gcHJvdmlkZXJzIGFjY29tcGxpc2ggdGhp cyB0b2RheT8mbmJzcDsgSG93IGRvIG90aGVyLCBjb21wYXJhYmxlLCBzZXJ2aWNlcyBoYW5kbGUg dGhpcyB0b2RheT8mbmJzcDsgU2VjdGlvbiA5IHN0YXRlcyDigJxBIFJVRSBkZXZpY2UgbWF5IHJl dHJpZXZlIGEgY29uZmlndXJhdGlvbiBmcm9tIGEgcHJvdmlzaW9uZWQgVVJMIHVzaW5nIEhUVFBz 4oCdLiBFdmVyeSBicm93c2VyIEkgdXNlIHNlZW1zIHRvIGJlIGFibGUgdG8gcmVtZW1iZXINCiB0 aGF0IEkgaGF2ZSBjcmVkZW50aWFscyBmb3IgbXVsdGlwbGUgc2l0ZXMgKGJ1dCBub3QgbXkgYmFu ayBvciBpbnN1cmFuY2UgcHJvdmlkZXIpIHdpdGhvdXQgYW55IGRpZmZpY3VsdHkuJm5ic3A7IENh biB3ZSBzcGVjaWZ5IHdoYXRldmVyIG1lY2hhbmlzbXMgYXJlIGNvbW1vbmx5IGluIHVzZSB0b2Rh eT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPn08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ni4gVGhlIG1lY2hhbmlzbSBtdXN0IGJlIHNlY3VyZSAo Zm9yIGV4YW1wbGUsIHN0b3JlZCBwYXNzd29yZCBtdXN0IGJlIGVuY3J5cHRlZCBpbiBzdG9yYWdl IGFuZCB0cmFuc2l0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Ny4gQXMgbXVjaCBhcyBwb3NzaWJsZSwgdGhlIHVzZXIgc2hvdWxkIG5vdCBoYXZl IHRvIGVudGVyIGNvbmZpZ3VyYXRpb24gZGF0YSBzdWNoIGFzIHByb3h5IHNlcnZlciBVUklzLCBU VVJOIHNlcnZlciBVUklzLCBldGMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPns8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0d28tdGllcmVkIGNvbmZpZ3VyYXRpb24g cmV0cmlldmFsIG91dGxpbmVkIGluIHRoZSBkb2N1bWVudCBzaG91bGQgZWxpbWluYXRlIHRoZSBu ZWVkIGZvciBhbnkgb2YgdGhlIGluZm9ybWF0aW9uIHlvdSBsaXN0ZWQgdG8gYmUgbWFudWFsbHkg ZW50ZXJlZC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDkuMSwmbmJz cDsgUlVFIFByb3ZpZGVyIFNlbGVjdGlvbiwgb3V0bGluZXMgYSBQcm92aWRlciBsaXN0IHdoaWNo IHdvdWxkIGJlIG1haW50YWluZWQgYnkgYSBzaW5nbGUgYXV0aG9yaXRhdGl2ZSBzb3VyY2UgKHBl cmhhcHMgdGhlIEZDQyBvciB0aGVpciBkZXNpZ25lZSBmb3IgdGhlIFVuaXRlZCBTdGF0ZXMpLiZu YnNwOyBUaGlzIGxpc3QgcHJvdmlkZXMgYSBtaW5pbWFsIHNldCBvZiBpbmZvcm1hdGlvbiBwZXIg cHJvdmlkZXINCiB0byBzdXBwbHkgdGhlIFJVRSB3aXRoIGEgbGlzdCBvZiBQcm92aWRlcnMgdGhh dCBjYW4gYmUgY29udGFjdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDkuMiwg UlVFIENvbmZpZ3VyYXRpb24gU2VydmljZSwgXzxpPnNob3VsZDwvaT5fIGNvbnRhaW4gYW5kIHJl cXVpcmVkIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gZm9yIHRoZSB1c2VyIHRvIGFjY2VzcyBh IHNwZWNpZmljIHByb3ZpZGVy4oCZcyBzZXJ2aWNlLiZuYnNwOyBJZiB0aGVyZSBpcyBzb21ldGhp bmcgbWlzc2luZywgd2Ugc2hvdWxkIGFkZCBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPn08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj9Nb3JlPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJpYW48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAyMywgMjAyMCwgYXQg MTowMCBQTSwgUGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5t aXQuZWR1Ij5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTEvMjAvMjAg MTA6MTAgQU0sIEJyaWFuIFJvc2VuIHdyb3RlOjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5JbiB0aGUgUlVNIG1lZXRpbmcsIE9sbGUgc3VnZ2VzdGVkIHdlIGxlYXZlIHVzZXJuYW1lL3Bh c3N3b3JkIGFzIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBmb3IgU0lQIChhbmQsIGhlIHByb3Bv c2VzLCBmb3IgdGhlIGNvZGUgYXV0aGVudGljYXRpb24gaXNzdWUpIGJlaGluZCwgYW5kIHVzZSBP QVVUSA0KIHRva2VucyBvciBjZXJ0cy48YnI+DQpJbiB0aGlua2luZyBhYm91dCB0aGlzLCBpdCBv Y2N1cnMgdG8gbWUgdGhhdCB0aGUgd2F5IHlvdSBhdXRoZW50aWNhdGUgdG8gdGhlIE9BVVRIIElE UCBpcywgd2FpdCBmb3IgaXQsIHVzZXJuYW1lIGFuZCBwYXNzd29yZCwgYW5kIHRoZSB3YXkgeW91 IGFjY2VzcyBhIHByaXZhdGUga2V5IGlmIGl04oCZcyBodW1hbiBiYXNlZCBhY2Nlc3MsIGlzIGEg cGFzcyBwaHJhc2UuICZuYnNwO1NvLCB3ZSBtaWdodCBiZSBpbXByb3ZpbmcgdGhlIGNyeXB0byBh IGJpdCwgYnV0DQogbm90IHRoZSBhdXRoZW50aWNhdGlvbiBzdHJlbmd0aC4gJm5ic3A7U28sIHdo eSBkbyBpdD88YnI+DQpNb3N0IElEUHMgdGhlc2UgZGF5cyBvZmZlciwgYW5kIHNvbWV0aW1lcyBy ZXF1aXJlIE1GQS4gJm5ic3A7VGhhdOKAmXMgYW4gaW1wcm92ZW1lbnQuIEFsdGhvdWdoIGl0IGNv dWxkIGJlIGNvbnNpZGVyZWQgYSBTSVAgZXh0ZW5zaW9uLCBzb21ldGhpbmcgc2ltcGxlIGxpa2Ug YXBwZW5kaW5nIGEgY29kZSB0byB0aGUgcGFzc3dvcmQgb3IgaGFzaGluZyB0aGUgcGFzc3dvcmQg d2l0aCBhIGNvZGUgd291bGQgZ2V0IHVzIHRoYXQgaWYgd2Ugd2FudGVkIGl0LiAmbmJzcDtJ4oCZ ZA0KIGFjdHVhbGx5IHByZWZlciBPQVVUSCwgYnV0IEkgY291bGQgc2VlIGRvaW5nIHRoYXQgZm9y IFJFR0lTVEVSLCBvciBmb3IgdGhhdCBtYXR0ZXIgSFRUUFMuICZuYnNwO0kgYWxzbyBub3RlIHRo YXQgdGhlIHRyYW5zYWN0aW9uIHRvIHByZXNlbnQgdGhlIEFQSSBLZXkgZG9lc27igJl0IG5lZWQg dXNlciBjcmVkZW50aWFscywgYnV0IGlmIHdlIGRpZG7igJl0IHVzZSB0aGVtLCB0aGVuIHdlIHdv dWxkIG5lZWQgYSB0b2tlbiByZXR1cm5lZCBmcm9tIHRoZSBIVFRQUw0KIEFQSSBLZXkgdHJhbnNh Y3Rpb24gdG8gYmUgaW5jbHVkZWQgaW4gdGhlIFJFR0lTVEVSIHRvIG1ha2Ugc3VyZSB0aGF0IGl0 IGNhbWUgZnJvbSB0aGUgYXBwcm92ZWQgYXBwLjxicj4NClRoZSBSVUUgY291bGQgcmVhc29uYWJs eSBjb25zdHJ1Y3QgYSBDUkwsIHBhc3MgaXQgdG8gYSBwcm92aWRlciwgZ2V0IGEgY2VydCBiYWNr IGFuZCB1c2UgQUNNRSB0byByZWZyZXNoIGl0LCBhbGwgd2l0aG91dCBhbnkgaHVtYW4gaW50ZXJh Y3Rpb24uICZuYnNwO1NvIEkgY2FuIHNlZSBob3cgdG8gZG8gY2VydHMuIE9BVVRIIGlzIGFsc28g b2J2aW91cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpJU1RNIHRoYXQgdGhlIHdheSB3ZSBh cmUgYXJyYW5naW5nIHRoaW5ncyB0aGVyZSBpcyBhIG5vbi1zaXAgc3RlcCBpbiBhdXRoZW50aWNh dGlvbiB0aGF0IGFsd2F5cyBpbnZvbHZlcyBhIGh1bWFuIGluIHJlYWwtdGltZS4gVXNpbmcgT0FV VEggdGhlcmUgc2VlbXMgZ29vZCBiZWNhdXNlIGl0IGNhbiBwdXNoIHRoZSBsb2dpYyBvZmYgdG8g c29tZSBvdGhlciBlbnRpdHkgd2hvc2UgY2hvaWNlIGlzIGJldHdlZW4gdGhlIHByb3ZpZGVyIGFu ZCB0aGUgdXNlci48YnI+DQo8YnI+DQpUaGF0IGlzIHByZXN1bWFibHkgdG8gZ2V0IHRvIHRoZSBj b25maWd1cmF0aW9uIHNlcnZlci4gVGhlbiB0aGUgY29uZmlndXJhdGlvbiBzZXJ2ZXIgaGFuZHMg YmFjayBjcmVkZW50aWFscyBmb3IgdXNlIGluIFNJUC4gQ3VycmVudGx5IHdlIGFyZSBoYW5kaW5n IGJhY2sgdXNlcmlkL3B3IHRoZXJlLiBCdXQgaXQgY291bGQganVzdCBhcyB3ZWxsIGJlIGEgdG9r ZW4uIE9yIHdlIGNvdWxkIGFsbG93IHRoYXQgdG8gYmUgYSBjaG9pY2UgbWFkZSBieSB0aGUNCiBw cm92aWRlci48YnI+DQo8YnI+DQpUaGVyZSBpcyBhbHNvIHRoZSBpc3N1ZSBvZiByZWZyZXNoaW5n IHRoZSBjb25maWd1cmF0aW9uIGlmIHNvbWV0aGluZyBpbiBpdCBoYXMgY2hhbmdlZC4gKEUuZy4g YSBjcmVkZW50aWFsIHJldm9jYXRpb24uKSBUaGF0IHNob3VsZCBiZSBhYmxlIHRvIGhhcHBlbiB3 aXRob3V0IHRoZSBodW1hbi4gSSBndWVzcyB0aGF0IG1heSBiZSBhIHJlYXNvbiB0byB1c2UgT0FV VEggc28gdGhhdCB0aGVyZSBjYW4gYmUgYSByZWZyZXNoIHRva2VuLjxicj4NCjxicj4NCjxzcGFu IGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bh bj5UaGFua3MsPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9zcGFuPlBhdWw8YnI+DQo8YnI+DQotLTxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpSdW0gbWFpbGluZyBsaXN0PGJy Pg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpSdW1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PlJ1bUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bTwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR09MB5948215AEF1814D683FAA8FDB9FB0MN2PR09MB5948namp_-- From nobody Tue Nov 24 09:43: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 2DE963A1243 for ; Tue, 24 Nov 2020 09:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[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 LhMX3NtHh95t for ; Tue, 24 Nov 2020 09:43:25 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 88B733A1236 for ; Tue, 24 Nov 2020 09:43:25 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id q22so21531027qkq.6 for ; Tue, 24 Nov 2020 09:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9u+5wVcfSZD37V8ojDQOEMrcYAyITIx1Rv01l7ZX7M4=; b=yEX6CQq1iP8W7wsMe8PDDKh2mgE7ssn3YnplIgD8G7WhgC+ah5n6T6SsU1K9m/H6B8 uxT2cM8lAOLgcyKYKrd14FKDC4QWgoRcZzhfo0njHbKMhjgEiBM+sKJKTScc/ceBD8uB TCGP1kuRw5gNoQ7iQNWYe5fVNEPBzHwWgaBh0NcXBHFqKqdwlgdeYfjIbOe/khNsnfSc iodzy3u/HIQMmf2Po6aIqtSq+Vx0DwxtqttOztWc5iJb5V9nwSv1jWxGVgKyVuSP2iTY 1J/n9RnXWHvjjgg7FKQ4Ijx9CDQM9vNY8mZl3CmpnMJLkhvisI9ZBNSqWSzed7ECVT7+ R/8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9u+5wVcfSZD37V8ojDQOEMrcYAyITIx1Rv01l7ZX7M4=; b=slHwzSrYbn04HM7AS006Cb8hqWsF363Ka0KykY43BzRu1NiAGvQ7RjGbPdkesvYXt2 Z7RPk3AF62eE23f5jISqMc6aOlXJCL7cf9CEna7j6XTgQ0nBLvz5mtzFpJ/4VA7P0GsA w0dYOUXH0Du0dYeIoFeUwO+Lu3v19ktPesaVo7yeTQzyspKy1GlcIRcj0bGbd48lFCiS yngVV4t38N5mTNpaik9iMHP3dPzZBY1Q9v+OVCIANaGgw1ayh+mWj7/caX9xZHeEkIoA i+a4m67cbhYKGRGD6Cu0RrIbiO7LWtg/UMpiDSyRCG3ocixpluMCsIVuKKZLL+EYodTH jI+w== X-Gm-Message-State: AOAM530jszi2n3t01huMfCCn0BndziboidlQ+KGAVelTndq97k/HlKU/ p1syf0kuXB938dHL+VCDDJ5LXg== X-Google-Smtp-Source: ABdhPJxr3Nmne8JS/YCJeWu8eWyTIHl0q0zDByorPE9SWjh9XWUhNEKcfDD5bKlc5CSO9DjIE+uPWQ== X-Received: by 2002:a05:620a:88e:: with SMTP id b14mr5881114qka.434.1606239804629; Tue, 24 Nov 2020 09:43:24 -0800 (PST) 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 h4sm13649038qkh.93.2020.11.24.09.43.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Nov 2020 09:43:24 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_907CE847-F9B3-4625-9E27-B21F9914DF61" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 24 Nov 2020 12:43:22 -0500 In-Reply-To: Cc: Paul Kyzivat , "rum@ietf.org" To: Jim Malloy References: <2F50A802-BC28-4A13-A9E1-A5271B642C1E@brianrosen.net> <672cab99-8611-7a34-b962-284b90438fdb@alum.mit.edu> <1691_1606234251_5FBD308B_1691_100_1_0D95D606-F858-4E86-BE4C-45C339DBD974@brianrosen.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] [EXT] Username/password vs cert/OAUTH token 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, 24 Nov 2020 17:43:28 -0000 --Apple-Mail=_907CE847-F9B3-4625-9E27-B21F9914DF61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One easy mechanism for the per provider config information is that the = HTTPS service we=E2=80=99ve talked about for the API key could return = the config for that provider. If we included the userid in the query, = that could be user-specific. That would NOT include any authentication = information, just the server URIs and other config data that wasn=E2=80=99= t private (but doesn=E2=80=99t need to be spread to the world. Jim, nearly every VoIP phone has a piece of local storage that holds all = the config information. It=E2=80=99s usually manually entered, = sometimes laboriously (using the 10 key pad), more often these days with = a built in web server and a browser. Most handle multiple lines. The = data includes username/password. It=E2=80=99s non-volatile storage. If = power fails, the phone boots, accesses this storage, and configures = itself, REGISTERs and is then ready to accept calls. No human = interaction. You can often put a username/password on the phone = configuration interface. I think we are replicating that, hopefully = with a bit more automation. Brian > On Nov 24, 2020, at 12:22 PM, Jim Malloy wrote: >=20 > Comments below in {} > =20 > --Jim > =20 > I think the problem is who runs the configuration server and who runs = the OAUTH IDP? > =20 > The fundamental thing we are trying to do here is support multiple = accounts at different providers. We=E2=80=99re all agreeing that needs = to be secure, and in one way or another, the human user has to = authenticate, > =20 > Maybe we should start at requirements: > 1. Configuration is per provider > 2. Multiple accounts at different providers must be supported > =20 > { > Yes =E2=80=93 and configurations should be pulled from each provider = independently. There is no reason for any provider to have visibility = into another provider=E2=80=99s information > } > 3. All information needed to connect to a provider must be in the = configuration > 4. Some form of (human) user authentication is required (but the = question is when, see 5) > =20 > { > Since the =E2=80=9Cpull=E2=80=9D is on a per-provider basis, the = authentication is also on a per-provider basis. Hew (and when) do = providers require authentication on mobile devices or dedicated hardware = today? I suspect the answers differ between providers and across device = types. > =20 > While I agree with Olle=E2=80=99s sentiment that the RFC should not = limit authentication to the =E2=80=9Cas-is=E2=80=9D mechanisms in use = today, it is important to provide a migration path from existing = mechanisms to currently acceptable (and, where possible, future) = mechanisms. Most, if not all, current US VRS providers rely on = username/password pairs for user authentication. > } > =20 > 5. The mechanisms has to work over a power failure: after power is = restored, incoming calls have to be received > =20 > { > How do providers accomplish this today? How do other, comparable, = services handle this today? Section 9 states =E2=80=9CA RUE device may = retrieve a configuration from a provisioned URL using HTTPs=E2=80=9D. = Every browser I use seems to be able to remember that I have credentials = for multiple sites (but not my bank or insurance provider) without any = difficulty. Can we specify whatever mechanisms are commonly in use = today? > } > =20 > 6. The mechanism must be secure (for example, stored password must be = encrypted in storage and transit) > 7. As much as possible, the user should not have to enter = configuration data such as proxy server URIs, TURN server URIs, etc. > =20 > { > The two-tiered configuration retrieval outlined in the document should = eliminate the need for any of the information you listed to be manually = entered.=20 > =20 > Section 9.1, RUE Provider Selection, outlines a Provider list which = would be maintained by a single authoritative source (perhaps the FCC or = their designee for the United States). This list provides a minimal set = of information per provider to supply the RUE with a list of Providers = that can be contacted. > =20 > Section 9.2, RUE Configuration Service, _should_ contain and required = configuration information for the user to access a specific provider=E2=80= =99s service. If there is something missing, we should add it. > } > =20 > =20 > =20 > ?More? > Brian >=20 >=20 > On Nov 23, 2020, at 1:00 PM, Paul Kyzivat > wrote: > =20 > On 11/20/20 10:10 AM, Brian Rosen wrote: >=20 > In the RUM meeting, Olle suggested we leave username/password as = authentication mechanism for SIP (and, he proposes, for the code = authentication issue) behind, and use OAUTH tokens or certs. > In thinking about this, it occurs to me that the way you authenticate = to the OAUTH IDP is, wait for it, username and password, and the way you = access a private key if it=E2=80=99s human based access, is a pass = phrase. So, we might be improving the crypto a bit, but not the = authentication strength. So, why do it? > Most IDPs these days offer, and sometimes require MFA. That=E2=80=99s = an improvement. Although it could be considered a SIP extension, = something simple like appending a code to the password or hashing the = password with a code would get us that if we wanted it. I=E2=80=99d = actually prefer OAUTH, but I could see doing that for REGISTER, or for = that matter HTTPS. I also note that the transaction to present the API = Key doesn=E2=80=99t need user credentials, but if we didn=E2=80=99t use = them, then we would need a token returned from the HTTPS API Key = transaction to be included in the REGISTER to make sure that it came = from the approved app. > The RUE could reasonably construct a CRL, pass it to a provider, get a = cert back and use ACME to refresh it, all without any human interaction. = So I can see how to do certs. OAUTH is also obvious. >=20 > ISTM that the way we are arranging things there is a non-sip step in = authentication that always involves a human in real-time. Using OAUTH = there seems good because it can push the logic off to some other entity = whose choice is between the provider and the user. >=20 > That is presumably to get to the configuration server. Then the = configuration server hands back credentials for use in SIP. Currently we = are handing back userid/pw there. But it could just as well be a token. = Or we could allow that to be a choice made by the provider. >=20 > There is also the issue of refreshing the configuration if something = in it has changed. (E.g. a credential revocation.) That should be able = to happen without the human. I guess that may be a reason to use OAUTH = so that there can be a refresh token. >=20 > Thanks, > Paul >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_907CE847-F9B3-4625-9E27-B21F9914DF61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One = easy mechanism for the per provider config information is that the HTTPS = service we=E2=80=99ve talked about for the API key could return the = config for that provider.  If we included the userid in the query, = that could be user-specific.  That would NOT include any = authentication information, just the server URIs and other config data = that wasn=E2=80=99t private (but doesn=E2=80=99t need to be spread to = the world.

Jim, = nearly every VoIP phone has a piece of local storage that holds all the = config information.  It=E2=80=99s usually manually entered, = sometimes laboriously (using the 10 key pad), more often these days with = a built in web server and a browser.  Most handle multiple lines. =  The data includes username/password.  It=E2=80=99s = non-volatile storage.  If power fails, the phone boots, accesses = this storage, and configures itself, REGISTERs and is then ready to = accept calls.  No human interaction.  You can often put a = username/password on the phone configuration interface.  I think we = are replicating that, hopefully with a bit more automation.

Brian

On Nov 24, 2020, at 12:22 PM, Jim Malloy = <jmalloy@mitre.org> wrote:

Comments below in {}
 
--Jim
 
I think the problem is who = runs the configuration server and who runs the OAUTH IDP?
 
The = fundamental thing we are trying to do here is support multiple accounts = at different providers.  We=E2=80=99re all agreeing that needs to = be secure, and in one way or another, the human user has to = authenticate,
 
Maybe we should start at = requirements:
1. Configuration is per provider
2. = Multiple accounts at different providers must be supported
 
{
Yes =E2=80=93 and = configurations should be pulled from each provider independently. There = is no reason for any provider to have visibility into another = provider=E2=80=99s information
}
3. All = information needed to connect to a provider must be in the = configuration
4. Some form of (human) user authentication is = required (but the question is when, see 5)
 
{
Since= the =E2=80=9Cpull=E2=80=9D is on a per-provider basis, the = authentication is also on a per-provider basis.  Hew (and when) do = providers require authentication on mobile devices or dedicated hardware = today? I suspect the answers differ between providers and across device = types.
 
While I agree with = Olle=E2=80=99s sentiment that the RFC should not limit authentication to = the =E2=80=9Cas-is=E2=80=9D mechanisms in use today, it is important to = provide a migration path from existing mechanisms to currently = acceptable (and, where possible, future) mechanisms.  Most, if not = all, current US VRS providers rely on username/password pairs for user = authentication.
}
 
5. = The mechanisms has to work over a power failure: after power is = restored, incoming calls have to be received
 
{
How do providers = accomplish this today?  How do other, comparable, services handle = this today?  Section 9 states =E2=80=9CA RUE device may retrieve a = configuration from a provisioned URL using HTTPs=E2=80=9D. Every browser = I use seems to be able to remember that I have credentials for multiple = sites (but not my bank or insurance provider) without any = difficulty.  Can we specify whatever mechanisms are commonly in use = today?
}
 
6. = The mechanism must be secure (for example, stored password must be = encrypted in storage and transit)
7. As much as possible, the user should = not have to enter configuration data such as proxy server URIs, TURN = server URIs, etc.
 
{
The two-tiered = configuration retrieval outlined in the document should eliminate the = need for any of the information you listed to be manually = entered. 
 
Section 9.1,  RUE = Provider Selection, outlines a Provider list which would be maintained = by a single authoritative source (perhaps the FCC or their designee for = the United States).  This list provides a minimal set of = information per provider to supply the RUE with a list of Providers that = can be contacted.
 
Section 9.2, RUE = Configuration Service, _should_ contain and required = configuration information for the user to access a specific provider=E2=80= =99s service.  If there is something missing, we should add it.
}
 
 
 
?More?
Brian


On = Nov 23, 2020, at 1:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:
 
On 11/20/20 10:10 AM, Brian Rosen wrote:

In the RUM meeting, Olle suggested we = leave username/password as authentication mechanism for SIP (and, he = proposes, for the code authentication issue) behind, and use OAUTH = tokens or certs.
In thinking about this, it occurs to me = that the way you authenticate to the OAUTH IDP is, wait for it, username = and password, and the way you access a private key if it=E2=80=99s human = based access, is a pass phrase.  So, we might be improving the = crypto a bit, but not the authentication strength.  So, why do = it?
Most IDPs these days offer, and sometimes require MFA. =  That=E2=80=99s an improvement. Although it could be considered a = SIP extension, something simple like appending a code to the password or = hashing the password with a code would get us that if we wanted it. =  I=E2=80=99d actually prefer OAUTH, but I could see doing that for = REGISTER, or for that matter HTTPS.  I also note that the = transaction to present the API Key doesn=E2=80=99t need user = credentials, but if we didn=E2=80=99t use them, then we would need a = token returned from the HTTPS API Key transaction to be included in the = REGISTER to make sure that it came from the approved app.
The RUE could reasonably construct a CRL, pass it to a = provider, get a cert back and use ACME to refresh it, all without any = human interaction.  So I can see how to do certs. OAUTH is also = obvious.

ISTM that the way we = are arranging things there is a non-sip step in authentication that = always involves a human in real-time. Using OAUTH there seems good = because it can push the logic off to some other entity whose choice is = between the provider and the user.

That is = presumably to get to the configuration server. Then the configuration = server hands back credentials for use in SIP. Currently we are handing = back userid/pw there. But it could just as well be a token. Or we could = allow that to be a choice made by the provider.

There is also the issue of refreshing the configuration if = something in it has changed. (E.g. a credential revocation.) That should = be able to happen without the human. I guess that may be a reason to use = OAUTH so that there can be a refresh token.

        &= nbsp;      Thanks,
        &= nbsp;      Paul
-- 
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_907CE847-F9B3-4625-9E27-B21F9914DF61-- From nobody Tue Nov 24 11:32:54 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 D6BF43A186C for ; Tue, 24 Nov 2020 11:32:52 -0800 (PST) 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 VsQHxW_CcY8w for ; Tue, 24 Nov 2020 11:32:48 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2047.outbound.protection.outlook.com [40.107.92.47]) (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 20F5F3A1869 for ; Tue, 24 Nov 2020 11:32:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aq92mpvLY+AbVOzFbKhFBTGi0qSk4PwnMSFApS2I7gvVxOoJmTm2VSruAYAMC4PRSrglZp3SEJdJVPATmoS3NXltkgqn1PTxGC9+aDBElRqiJfMuOfWd5XUy+YxaJ2KROGGw+HANmic85+eTAjj5CL+6t1+6Dzh+OtONrfr+1qR/bolnKgzM5jrDCav509aeXjwgi80c4ekBTaxthtQJAasr6ay5/FJLHov8pieg8GdPHUej1FaXY94kJ3DKoA9jQzJjvlGOZMLVngrFNfd4blrdMUtd3avWjKqwSta1OOn5GMY110BTl58RAPXyGDakGnLzl8JxndnzeZP416gYxg== 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=4pxvUBUabnMCx3gNub9Gbj7TATkXmF4bVhdRHiiORJk=; b=C+YinN8XKR2yxd2nF+Hd0Aas46kWcXSuoFpuRthOO5ftJ5K501UIL6woZrqUQEgq8JuV/C6O85K7Ue230590VTt1hOU+s4uXyiohf2jeXScjvJ34q3lDieiBQ5bxJKK+l0+rrUpOE4qPXY1fQHXTZuuS4aQo4PYuZqAXhrzmqJYWnumtgQ4h5HQMf5IRB7bC8XxhOu5kFSmF7qJDTmqF9v5SJy/ILo5htyb1rsUu1pgH59hiyYHhjKJWnw0YjA0zzltGbaI5zdin6O30Z2bipgjB1ZKWyicAKAWjVFNueSvER6cfzY5Ibwig1mRPpJ/2Q5c9fRIUtClY/tEQeWewMQ== 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=4pxvUBUabnMCx3gNub9Gbj7TATkXmF4bVhdRHiiORJk=; b=ILBvHAGjRbPMN5GRD0KnjEl3CUsiYQoJHus2z51aRWC6v3mN+kH/2fHpqsTosuponf5LOlnK6yZEm8r2RX0QNe3VI7uZ+U3H5o1p6CDjIr0ZXP6QIX10hEMcA9tIMLua+5uFbDUgAYeu2S3S2Anbe9xTpe0nFCW+/ONqrO4yzZo= Received: from DM5PR19CA0037.namprd19.prod.outlook.com (2603:10b6:3:9a::23) by BL0PR12MB2482.namprd12.prod.outlook.com (2603:10b6:207:4a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Tue, 24 Nov 2020 19:32:46 +0000 Received: from CY1NAM02FT023.eop-nam02.prod.protection.outlook.com (2603:10b6:3:9a:cafe::24) by DM5PR19CA0037.outlook.office365.com (2603:10b6:3:9a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20 via Frontend Transport; Tue, 24 Nov 2020 19:32: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 CY1NAM02FT023.mail.protection.outlook.com (10.152.74.237) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Tue, 24 Nov 2020 19:32:45 +0000 Received: from PaulKyzivatsMBP.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 0AOJWZA5028388 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 24 Nov 2020 14:32:36 -0500 To: rum@ietf.org References: <2F50A802-BC28-4A13-A9E1-A5271B642C1E@brianrosen.net> <672cab99-8611-7a34-b962-284b90438fdb@alum.mit.edu> <1691_1606234251_5FBD308B_1691_100_1_0D95D606-F858-4E86-BE4C-45C339DBD974@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Tue, 24 Nov 2020 14:32:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 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: 71f66cad-02db-4603-9462-08d890afb856 X-MS-TrafficTypeDiagnostic: BL0PR12MB2482: 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: LYMWhErg8h2HvRO6ds2VeG8NW3JykP2pWvcfDPFm6ZEA/Im0tCAepFeFZwLB0o3uKVnHtOfSbn/bZhx7FYnbzDna9NMWYMhEMmruo7Y5lViVkZMSL68dEClZcllelPayTs6wiWQkY7X9wgFiAwOMiCLT2r9kKTbt5QFIcXhoERfGVjNlKSwYlrgHRYInU9t0oyAFlNsedmUAFaTpa04qqOGVydmdhLGYs/gVpU/GZrjwoJLsZa4t0sBKTAJObQSBu2k5XH2IbgKIaFyH60gweYuG7sp6nyM/gRz3e/izKRMov5BbZy+G4gQG7Pjju1o7Wg64r3hqD7g20/dvwkH5AJYUZr4NJFKAJBdbMm6Jy1eP4LqO3Oen901dwzD09Mg8JIYiK+syXXacTzX2E1s6t5/vSkW8L0Ldq9OetH9fyfIiEPhydYLpOWXN20ZAmxbs7Nr//SqX9LfvDezpgVNguEFIXs5ECvJjw7qErm4r7Wker9HrtRWRbh7X/fRCcZk/ 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:(46966005)(2616005)(83380400001)(336012)(966005)(70206006)(47076004)(956004)(5660300002)(66574015)(498600001)(82310400003)(75432002)(8676002)(2906002)(36906005)(7596003)(6916009)(8936002)(186003)(356005)(70586007)(86362001)(31686004)(53546011)(31696002)(26005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2020 19:32:45.6934 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 71f66cad-02db-4603-9462-08d890afb856 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: CY1NAM02FT023.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB2482 Archived-At: Subject: Re: [Rum] [EXT] Username/password vs cert/OAUTH token 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, 24 Nov 2020 19:32:53 -0000 On 11/24/20 12:43 PM, Brian Rosen wrote: > One easy mechanism for the per provider config information is that the > HTTPS service we’ve talked about for the API key could return the config > for that provider.  If we included the userid in the query, that could > be user-specific.  That would NOT include any authentication > information, just the server URIs and other config data that wasn’t > private (but doesn’t need to be spread to the world. I think we need to distinguish *enrolling* the device/app with the provider from the device fetching the provider-specific configuration of the device/app. The enrollment would be a more or less one-time thing per device per provider, and would require the user to be present and to authenticate himself to the provider. The configuration may need to fetched every time the device starts up, or it may only need to be refreshed from time to time. (This requires discussion.) But it too needs to work without anyone present. Then it provides the credentials needed for sip - registration, subscription, etc. My thought has been that when the provider decides the device needs to be re-provisioned it can invalidate the sip credentials and unregister the device. That will trigger the device to attempt to reload its configuration, along the way receiving new sip credentials that will work. If the provider feels a need to force re-authentication by the human (re-enrollment), it should when possible defer that until it sees some action that indicates a human is present. For instance, when an outgoing call is initiated. (For politeness it might want until the bye of the outgoing call.) I'm not necessarily proposing that all of this mechanism be required. But rather that things be designed to accommodate this sort of behavior if the provider chooses to implement it. Thanks, Paul > Jim, nearly every VoIP phone has a piece of local storage that holds all > the config information.  It’s usually manually entered, sometimes > laboriously (using the 10 key pad), more often these days with a built > in web server and a browser.  Most handle multiple lines.  The data > includes username/password.  It’s non-volatile storage.  If power fails, > the phone boots, accesses this storage, and configures itself, REGISTERs > and is then ready to accept calls.  No human interaction.  You can often > put a username/password on the phone configuration interface.  I think > we are replicating that, hopefully with a bit more automation. > > Brian > >> On Nov 24, 2020, at 12:22 PM, Jim Malloy > > wrote: >> >> Comments below in {} >> --Jim >> I think the problem is who runs the configuration server and who runs >> the OAUTH IDP? >> The fundamental thing we are trying to do here is support multiple >> accounts at different providers.  We’re all agreeing that needs to be >> secure, and in one way or another, the human user has to authenticate, >> Maybe we should start at requirements: >> 1. Configuration is per provider >> 2. Multiple accounts at different providers must be supported >> { >> Yes – and configurations should be pulled from each provider >> independently. There is no reason for any provider to have visibility >> into another provider’s information >> } >> 3. All information needed to connect to a provider must be in the >> configuration >> 4. Some form of (human) user authentication is required (but the >> question is when, see 5) >> { >> Since the “pull” is on a per-provider basis, the authentication is >> also on a per-provider basis.  Hew (and when) do providers require >> authentication on mobile devices or dedicated hardware today? I >> suspect the answers differ between providers and across device types. >> While I agree with Olle’s sentiment that the RFC should not limit >> authentication to the “as-is” mechanisms in use today, it is important >> to provide a migration path from existing mechanisms to currently >> acceptable (and, where possible, future) mechanisms.  Most, if not >> all, current US VRS providers rely on username/password pairs for user >> authentication. >> } >> 5. The mechanisms has to work over a power failure: after power is >> restored, incoming calls have to be received >> { >> How do providers accomplish this today?  How do other, comparable, >> services handle this today?  Section 9 states “A RUE device may >> retrieve a configuration from a provisioned URL using HTTPs”. Every >> browser I use seems to be able to remember that I have credentials for >> multiple sites (but not my bank or insurance provider) without any >> difficulty.  Can we specify whatever mechanisms are commonly in use today? >> } >> 6. The mechanism must be secure (for example, stored password must be >> encrypted in storage and transit) >> 7. As much as possible, the user should not have to enter >> configuration data such as proxy server URIs, TURN server URIs, etc. >> { >> The two-tiered configuration retrieval outlined in the document should >> eliminate the need for any of the information you listed to be >> manually entered. >> Section 9.1,  RUE Provider Selection, outlines a Provider list which >> would be maintained by a single authoritative source (perhaps the FCC >> or their designee for the United States).  This list provides a >> minimal set of information per provider to supply the RUE with a list >> of Providers that can be contacted. >> Section 9.2, RUE Configuration Service, _/should/_ contain and >> required configuration information for the user to access a specific >> provider’s service.  If there is something missing, we should add it. >> } >> ?More? >> Brian >> >> >> On Nov 23, 2020, at 1:00 PM, Paul Kyzivat > > wrote: >> On 11/20/20 10:10 AM, Brian Rosen wrote: >> >> In the RUM meeting, Olle suggested we leave username/password >> as authentication mechanism for SIP (and, he proposes, for the >> code authentication issue) behind, and use OAUTH tokens or certs. >> In thinking about this, it occurs to me that the way you >> authenticate to the OAUTH IDP is, wait for it, username and >> password, and the way you access a private key if it’s human >> based access, is a pass phrase.  So, we might be improving the >> crypto a bit, but not the authentication strength.  So, why do it? >> Most IDPs these days offer, and sometimes require MFA.  That’s >> an improvement. Although it could be considered a SIP >> extension, something simple like appending a code to the >> password or hashing the password with a code would get us that >> if we wanted it.  I’d actually prefer OAUTH, but I could see >> doing that for REGISTER, or for that matter HTTPS.  I also >> note that the transaction to present the API Key doesn’t need >> user credentials, but if we didn’t use them, then we would >> need a token returned from the HTTPS API Key transaction to be >> included in the REGISTER to make sure that it came from the >> approved app. >> The RUE could reasonably construct a CRL, pass it to a >> provider, get a cert back and use ACME to refresh it, all >> without any human interaction.  So I can see how to do certs. >> OAUTH is also obvious. >> >> >> ISTM that the way we are arranging things there is a non-sip step >> in authentication that always involves a human in real-time. Using >> OAUTH there seems good because it can push the logic off to some >> other entity whose choice is between the provider and the user. >> >> That is presumably to get to the configuration server. Then the >> configuration server hands back credentials for use in SIP. >> Currently we are handing back userid/pw there. But it could just >> as well be a token. Or we could allow that to be a choice made by >> the provider. >> >> There is also the issue of refreshing the configuration if >> something in it has changed. (E.g. a credential revocation.) That >> should be able to happen without the human. I guess that may be a >> reason to use OAUTH so that there can be a refresh token. >> >> Thanks, >> Paul >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> > > From nobody Mon Nov 30 12:19:47 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 A26493A1110 for ; Mon, 30 Nov 2020 12:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 e00OLqeUg3rx for ; Mon, 30 Nov 2020 12:19:44 -0800 (PST) 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 01D1A3A0EF3 for ; Mon, 30 Nov 2020 12:19:44 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id u4so12140831qkk.10 for ; Mon, 30 Nov 2020 12:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=iPEiJIpPd/pSrt9/0msRwNuFSaacyWSK/kQPSi99ig8=; b=dFpd3vt5D/i0DlkcbL7wRz7UlfcPJ4mCQt+7MLEiJEUMeVWHz0TNLLpfRVvLbT4lcK 7A4R+rM99EqQkr9YHuptUfjvTXuULcCRx53fUqr11RR23q6uVmZXh9kMKf4DYZ9/3OeT Egx7UKqIdySKiJnTzD1PES+eW11SxbG8uZtV0Mbohs5IjoRNsvgh6iPj/C5j3bF5srQs YMDi/0Fk3dcMLzN9qWkXMMxECBPwodVFjwgfUbPf3sZJpRN7kAv/ld05e1ZAT9YdmGKZ jQ2MMa/pZgk0ImDnfTJvQcMhFZTT3GFktic1+3KTvxDACFNIWT/g0yO6DntbLKdsX6wk xrRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=iPEiJIpPd/pSrt9/0msRwNuFSaacyWSK/kQPSi99ig8=; b=pAaYTRMZ1QYqsMiWMbQ968Afonf/UbpVFDOZ95XAn2PJY6b/EHNqFlgqXTI23YoCxE wWMo23s9yLggOe2wVYe+gzvwLiNTpR7f/QUgM7JIpagGlepkI7pCJS2k0X1tLmVP+ID+ tIurMqWeJ8tzqmDgaywCaKi6pYL2xIL4N91i/S6YYc2qZnajxfjbbLlwPOSEH9oAqdNM /uJ6OyPYe9lsjvRpDjcFZFeAaLbyHJDUW26dHUId5BNKlR7jNPPhivSY1HAj0yTQWCB2 MN+EextsvGav4u71qFf8gQLMUIPixFdnIQ4foDiOWPVY0BsD2PLM45bRBwX6kS9G3bGL PD6w== X-Gm-Message-State: AOAM532FZgCyVtjNR/YeEOVFUyWad4p1tvTPsR02oELUO+ZIydTpw+S0 Yv1QubGwCwRA2Jrk7rxD5Fa5uKhrKjJsaaUj X-Google-Smtp-Source: ABdhPJzwQFgVTDZYGXn0aqP0wIwvqknl3QLUhgEo6Om3bUa8pxz3ZrOx2BEP98niRlSaXO4zxompjw== X-Received: by 2002:a37:a010:: with SMTP id j16mr25364322qke.347.1606767583014; Mon, 30 Nov 2020 12:19:43 -0800 (PST) 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 p12sm15513424qkp.88.2020.11.30.12.19.42 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Nov 2020 12:19:42 -0800 (PST) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <97E5D216-66C0-40AB-BA6A-2909AB93550E@brianrosen.net> Date: Mon, 30 Nov 2020 15:19:41 -0500 To: rum@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [Rum] Multi-party RTT 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, 30 Nov 2020 20:19:46 -0000 May I draw your attention to: https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix This document, which just entered the IETF approval process (=E2=80=9CWork= ing Group Last Call=E2=80=9D) defines a new mechanism to handle mixing = of RTT. =20 I would like us to consider requiring support for the =E2=80=9Cmulti-party= aware=E2=80=9D mechanism in our documents. If you have any technical comments on the multiparty rtt mix doc, the = avtcore working group would very much appreciate hearing from you, = Several members of this list have contributed comments and suggestions = already. If you have an opinion on my proposal to require support for it in our = document, send them to this list. Brian