Re: [Rum] [EXT] RUM security model

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 16 October 2020 00:19 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 479EC3A0D32 for <rum@ietfa.amsl.com>; Thu, 15 Oct 2020 17:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.214
X-Spam-Level:
X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSOPKaB2Fgzm for <rum@ietfa.amsl.com>; Thu, 15 Oct 2020 17:19:47 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760073.outbound.protection.outlook.com [40.107.76.73]) (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 7B74A3A0D2C for <rum@ietf.org>; Thu, 15 Oct 2020 17:19:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TxX3XsGI/RJiDP/iKAjJUCGyk6nEUgQ3zwxtNg5YFJ7Bl582x3j0wVew06wDXxbJ7PAhue69R+1ncmqeuwKAzmW1ZjI35J9xm48MKiRnpXB5KOdJfFSPr8m+tV1xMwKoOS/vQGU80HXVDSk5lD3F2OuTL7ekL9Ma+tP56ChYygpIvWZXMaTsp+CV8xwvzfRYQgb3Gm/TcqEcwfzAbCKFjjM2DNcwwYyolLafr0aHsEmwR++OiElj6rb9/48LXKuF3ZlMwKIHZ0YeHOj2qDqiGOKA/O0hAN0S0/GLM9Hf3BaQl4S9kbcvrD9oDfeeUZjeqF0ZnJuJ2wMxx90agH+mjw==
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=9+pw9854nO3xJQBqKSJkoi5Q8xk7oiGmXrDd1kVW+vs=; b=C+aoCfLpAo5qHJabLS/cIw+Goo0D4cCtwigtZpi/X/I1Uf/lCqvIqg/B+ZFE1e8Rubr3d36RVCsLJe/JrCnsxlcH0MiAQBR7d9YprBkfPgC45iN72kel95DueG94eZwKTZYaFYdyqBUEqKVxQKPDvPzi8N8Wag+mNOZ8odk3VmFzt/B4pL2ckNkYnwYKHNVAFxBkpO3/y/kEIj3dg6Ta18JCqaq8iVVJ6Fy3ri6cCHxA5iPDLucNS6aEQpUhcIPVGyfolTPtyv+9Ztz03FOx3XAQulD0gai9lqL623P6iukbejA3r4rscxDZWZjnO1c+AZ5Iq7OB35+lv4/po9ZHYg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none (sender ip is 18.7.68.33) smtp.rcpttodomain=brianrosen.net smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9+pw9854nO3xJQBqKSJkoi5Q8xk7oiGmXrDd1kVW+vs=; b=jKfJkDGF64A2CW4ptTUKO152UZXz3sIt/bpFpLy1isW6EaNm/THSNep2pcDatV/qy0C0uhV5xTKZYQ1V1tLqv2qAlAprwaRWuQC1NF+atiSSo2ryEGThFlmLvZ0mxPlaQGRJ0YM9/wYtLgsTG0uyOXaWr2NWiSSEgIf43ZjpM+s=
Received: from SN4PR0201CA0008.namprd02.prod.outlook.com (2603:10b6:803:2b::18) by CY4PR12MB1605.namprd12.prod.outlook.com (2603:10b6:910:f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.20; Fri, 16 Oct 2020 00:19:40 +0000
Received: from SN1NAM02FT049.eop-nam02.prod.protection.outlook.com (2603:10b6:803:2b:cafe::64) by SN4PR0201CA0008.outlook.office365.com (2603:10b6:803:2b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Fri, 16 Oct 2020 00:19:40 +0000
X-MS-Exchange-Authentication-Results: spf=none (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=alum.mit.edu;
Received-SPF: None (protection.outlook.com: alum.mit.edu does not designate permitted sender hosts)
Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT049.mail.protection.outlook.com (10.152.72.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Fri, 16 Oct 2020 00:19:40 +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 09G0JbGW004217 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 15 Oct 2020 20:19:38 -0400
To: Brian Rosen <br@brianrosen.net>
Cc: rum@ietf.org
References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu>
Date: Thu, 15 Oct 2020 20:19:37 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.2
MIME-Version: 1.0
In-Reply-To: <7A11F680-9EA6-4477-9BD8-6A7755AD0054@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: c582b5b3-7a5b-427f-f9a5-08d871692c63
X-MS-TrafficTypeDiagnostic: CY4PR12MB1605:
X-Microsoft-Antispam-PRVS: <CY4PR12MB16055E863071ECCBF9E35798F9030@CY4PR12MB1605.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 0tg5yf7wO9K2FrihyWPJZSXlri6t1YjXaP9hRyhco5RGqrWckalAgVf62lqjrZkeRKFYjgjRmARoLElGfVkdR4tJWZfaBMUrvruynGU9dFzcBe9sgvuBaXiz9gN//7k/B0k3po4yJEQU6C+naTOSUFk8whqPnbSE9zTlTLZNVMZFhxyjews55VXxNjNfNhz/qy9aNz+ynu7yRf5iBKHxtVIZXUPDziMR+Kj1IMqYyrI2toypCxgjlERsFzGqIxb3I9XopSoYmdnjIrz00naCtuBWnXXaRtavRnF+D4I6VHxYRKGiEkEFtacP+jaD67nw2rCQUfKvVkbkcSW992pMB4t5OqLL8ucYTnODy6UVib8NvVqrUBe293bTYxH0hWsMv8bhpllNYafw8sE+3d/vh8I++DO1dB9WJ11/2zjnriNQwPRkPaydk5VIMwwSXh1AEiOu7pI2g8bYFVhmyKOPIlRfaxAgctOUS48TUTi865GEmdebic0lMDgD8WRE9Ynw
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(136003)(376002)(396003)(346002)(39860400002)(46966005)(356005)(478600001)(36906005)(8676002)(8936002)(86362001)(316002)(83380400001)(7596003)(47076004)(2906002)(4326008)(82740400003)(786003)(82310400003)(5660300002)(956004)(53546011)(2616005)(31696002)(966005)(336012)(186003)(75432002)(70206006)(6916009)(26005)(70586007)(15650500001)(31686004)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2020 00:19:40.1160 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c582b5b3-7a5b-427f-f9a5-08d871692c63
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: SN1NAM02FT049.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1605
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/_1jn57MQXc1V5544kTHe4ytICT4>
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: Fri, 16 Oct 2020 00:19:49 -0000

On 10/15/20 7:52 PM, Brian Rosen wrote:
> I don’t think even that would work because there isn’t any way to know that the app that was approved is the app that is being used.

Yes, I guess you are right. But at least it would require the end user 
to enter into a conspiracy with the app developers, and be able to get 
the credential out of one app and into another.

	Thanks,
	Paul

> What systems like iOS does is rely on the fact that you can’t download and run an app that hasn’t been vetted. The code is signed and the signature is checked every time the app starts. We don’t have an environment like that.  We can’t control what is downloaded and we can’t check signatures.

> I don’t think there is a reliable way to do this. If someone has an idea, please explain it, but we can’t be in a “you do something” position without a clue as to how.
> 
> Now, if the app was an iOS app, then the right thing happens. There are few other systems that are wired down like that. Android, for example, allows you to download and run from arbitrary sites if the device is configured to allow that.
> 
> Brian
> 
> 
>> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>
>> Eugene,
>>
>>> On 10/15/20 3:30 PM, Eugene Christensen wrote:
>>> Brian,
>>> Admittedly I do not fully understand certificates and authentication but would client certificates or mutual authentication with a shared secret work here?
>>
>> I'm also not a security expert. To my understanding, the key problem is that you want a proof that an implementation has passed some sort of test. That is more or less equivalent to having a special certification authority that is able to assign a certificate based on the passing of a test. But for the system to work that certificate needs to be bound to the entity (hw/sw) that passed the test. It can't be possible to transfer that certificate to a different device.
>>
>> A possible alternative would be for each provider to have its own test service. When a user gets a new device/application, as part of the initial registration of their device with the provider, this test would be run. Then the result of that would be granting of credentials for that device to access that provider's system.
>>
>>     Thanks,
>>     Paul
>>
>>> Thank you.
>>> 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 <mailto: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.
>>> *From:* Brian Rosen <br@brianrosen.net>
>>> *Sent:* Wednesday, September 30, 2020 5:47 PM
>>> *To:* Eugene Christensen <echristensen@sorenson.com>
>>> *Cc:* rum@ietf.org
>>> *Subject:* Re: [Rum] [EXT] RUM security model
>>> [EXTERNAL]
>>> I think we understand why you want it. What we don’t understand is what mechanism would provide it. I am generally aware of this class of problem and I’m not aware of a solution that will work.  So what we need is a suggested mechanism that provides the assurance you want that is technically sound.
>>> Brian
>>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen <echristensen@sorenson.com <mailto:echristensen@sorenson.com>> wrote:
>>>     Thanks for considering how we might implement this security
>>>     mechanism.  May I add my voice that it is essential that we find an
>>>     option for providing this desired security, whatever it is.  It
>>>     could be detrimental to the VRS providers to have UAs out there,
>>>     with the ability to register with VRS providers without first being
>>>     fully vetted.  It is our practice anytime we make updates to our UAs
>>>     to test how they work with our UAS before we ever release the new UA
>>>     software into our production environment.  We only want UAs
>>>     registering that have undergone this rigorous testing with our
>>>     systems and then only with users which we have awareness of.
>>>     Thanks,
>>>     Eugene Christensen
>>>     CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents,
>>>     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
>>>     <mailto:echristensen@sorenson.com> or by telephone at +1 (801)
>>>     287-9419, and destroy the original transmission and its attachments
>>>     without reading them or saving them to disk.
>>>     --     Rum mailing list
>>>     Rum@ietf.org <mailto:Rum@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/rum
>>>     <https://www.ietf.org/mailman/listinfo/rum>
>>
>> -- 
>> Rum mailing list
>> Rum@ietf.org
>> https://www.ietf.org/mailman/listinfo/rum