Re: [Rum] [EXT] RUM security model

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 03 November 2020 20:25 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 <rum@ietfa.amsl.com>; 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 <rum@ietfa.amsl.com>; 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 <rum@ietf.org>; 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 <echristensen@sorenson.com>, "Olle E. Johansson" <oej@edvina.net>, Brian Rosen <br@brianrosen.net>
Cc: "rum@ietf.org" <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> <CAOPrzE1ONDUcGwvcfRhpyu9YM5JJJD92AsLKaeXvXqH4fmNbBw@mail.gmail.com> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> <F03944C6-0C19-4964-94A8-658B338526D4@brianrosen.net> <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> <BYAPR04MB49835526E9F63A38A5C56B86A31C0@BYAPR04MB4983.namprd04.prod.outlook.com> <38090A50-6572-4A8E-97D4-C260323365AE@brianrosen.net> <EC92824F-0175-407A-8175-A95DFE197B22@edvina.net> <f5c85256-45fe-2c0b-2b93-3fe4fd24e557@alum.mit.edu> <BYAPR04MB4983A00EF9CA72582AC270FAA3150@BYAPR04MB4983.namprd04.prod.outlook.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <90279636-259e-8ff6-7e28-406a84ddeccc@alum.mit.edu>
Date: Tue, 03 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: <BYAPR04MB4983A00EF9CA72582AC270FAA3150@BYAPR04MB4983.namprd04.prod.outlook.com>
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: <BN8PR12MB3586EA1E31B0988D55FBA62FF9110@BN8PR12MB3586.namprd12.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/rum/LIkANbTIHWMNfzFDB2vWzOH55CY>
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 <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=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 <pkyzivat@alum.mit.edu>
> Sent: Thursday, October 22, 2020 9:34 AM
> To: Olle E. Johansson <oej@edvina.net>; Brian Rosen <br@brianrosen.net>
> Cc: Eugene Christensen <echristensen@sorenson.com>; 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
>