Re: [Rum] RUE client credentials

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 28 August 2019 13:47 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 446901201DB for <rum@ietfa.amsl.com>; Wed, 28 Aug 2019 06:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjU3hAhy-f-V for <rum@ietfa.amsl.com>; Wed, 28 Aug 2019 06:47:47 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 ED7981200E3 for <rum@ietf.org>; Wed, 28 Aug 2019 06:47:46 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7SDlhZr002411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 09:47:44 -0400
To: Brian Rosen <br@brianrosen.net>
Cc: rum@ietf.org
References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <054dde2a-7fa1-9941-986c-f3b3d8c0f76e@alum.mit.edu> <831AD5BE-0D8F-4968-ABC7-B8D52BB8D4B0@brianrosen.net>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <30a05d55-3aee-3195-3e2e-9ac1d92b886d@alum.mit.edu>
Date: Wed, 28 Aug 2019 09:47:43 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <831AD5BE-0D8F-4968-ABC7-B8D52BB8D4B0@brianrosen.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/1PWZ-PfpYZ8LWlF5zgXRpTDstKs>
Subject: Re: [Rum] RUE client credentials
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: Wed, 28 Aug 2019 13:47:48 -0000

On 8/27/19 3:32 PM, Brian Rosen wrote:
> Getting back to this, sorry for the delay.
> 
> 
> 
>> On Aug 12, 2019, at 3:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>
>> On 8/7/19 5:14 PM, Brian Rosen wrote:
>>> Working on these comments.  I submitted a new version (-01)
>>> I edited the doc to say the client cert is provisioned.  Given that it’s provisioned by the entity that the provides the server, do I need to say anything else about validating the cert?
>>
>> I think we need to examine what the goal is here, and whether it is being achieved. I don't think enough is said to decide.
>>
>> This client cert mechanism was first added way back when (2015 I think). IIRC, the motivation was because the providers wanted to restrict access to RUE *implementations* that have passed interoperability testing, in order to reduce the problems of dealing with buggy implementations or attackers.
> I think you are confusing validating an implementation from authenticating a user.  The notion of mutual auth with a per-device cert is completely separate from some notion of “signing” an implementations code.

No. You can argue that the client cert mechanism in not an appropriate 
mechanism for this, but it was the intent when the mechanism was proposed.

I can see how this might be confused if you weren't there at the time. 
And perhaps the thinking about it has evolved since it was first 
included. I wasn't party to what happened during 2016-18.

IIUC the providers still want this - a way to screen out RUE 
*implementations* that have not passed their testing. However, I don't 
know how to achieve that goal. And I'm inclined to think that it is an 
unreasonable expectation. It is akin to web site operators asking for a 
way to screen out any browser implementations that they haven't already 
tested against.

> We can decide we don’t want the option of having mutual auth.

Clearly there is need for some mechanism to securely associate a RUE 
with an account at the provider and a phone number. And this needs to 
work with devices that are persistently connected. If a RUE suffers a 
power or network outage that is restored in the middle of the night then 
it should be able to reconnect without a user login so that it can be 
available for incoming calls.

That was intended to be covered by passwords. But care must be taken to 
secure those.

	Thanks,
	Paul