Re: [Rum] RUE client credentials

Brian Rosen <br@brianrosen.net> Wed, 28 August 2019 15:34 UTC

Return-Path: <br@brianrosen.net>
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 2D04E120059 for <rum@ietfa.amsl.com>; Wed, 28 Aug 2019 08:34:31 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 xCh2ai9FeRDQ for <rum@ietfa.amsl.com>; Wed, 28 Aug 2019 08:34:29 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 57A4012000F for <rum@ietf.org>; Wed, 28 Aug 2019 08:34:29 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id v38so32180qtb.0 for <rum@ietf.org>; Wed, 28 Aug 2019 08:34:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ifVq4NTFOnjHPBSrA58hhAfcIq4H5vBvILs8Q117iJg=; b=PE4sUyQ292KjBddPFR6H+YGWlOXXBK4SqdGTOZvUWB55mGTanu1ElASROxlvCJ/I/w KCcA1cHBIfVS0q05NLja1IIF8A/2C4U6qAeMqAO531jhPIFeXyc5qk1QKt8amC+y/eCb bmGPJjDrHbga+q006966xDARwVB1QzkjfNMHYjQjhqeckPHVEezcLkiqm4iizn5/V9qe Bh858HxKz2czvUReUnuL17n6q0hIADom5w9lILtLoOMlegv4R+QMI79jSnXqndHWPFsu vw5z+TTjPhgEP37MfAeKTPwyjMg0MqnwCAEl2g5Tecctr6oyAbWTAhbgcbG/1Aq7Hp34 dJjg==
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=ifVq4NTFOnjHPBSrA58hhAfcIq4H5vBvILs8Q117iJg=; b=XjzLs3aAIp4tdyMgTkm9tYQQE2ygJgPI6Z4fMNGDquL1yGF/CnMo3smWQJC8GGvkn0 2JYmBeshAsLDMAGIDGS02tK4Yk0ALgYL3Ji4HI7N1gKSv/BovhnRuj62ODPyrIbBR3Ke eLY2hSBYDE9v8i9ZRI1GQMLfYeHN5c9XWaM1FAN0chZf00Vhj7ahDP69UtzgaKzp4W5Y n8xL3JbuJStCe91bo7qB5WLQ8OIEwYMB0oco0T66NV/O7Gb6jKmBttLNPLpfxEhScifV CgxDD9oDH/kZ137HScNm1unPu6fktTkrxYSdYMBPCwNXvTBLsMsneLYf2xUIAXrVQMdx VBNA==
X-Gm-Message-State: APjAAAU4LqkbiDl/n0I7UbVjbnFsfjjXFCHEIzMzZ+4W6q55FnyFeKTd kw9K2t6VxQ1egwa/KiraSDbHjb2D9z0=
X-Google-Smtp-Source: APXvYqwzoE6iVijSMdf70FPSr4YH56WU8fsLUaVf0vib1t7AqMIfPn1s4pUyv0w/w9aPe0Eoaq8Wig==
X-Received: by 2002:ac8:4789:: with SMTP id k9mr4833476qtq.41.1567006468056; Wed, 28 Aug 2019 08:34:28 -0700 (PDT)
Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id w15sm1377551qkj.23.2019.08.28.08.34.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 08:34:27 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <414e3fa5-ae0f-a632-af75-f34f2842d85c@alum.mit.edu>
Date: Wed, 28 Aug 2019 11:34:25 -0400
Cc: rum@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <26090EC8-51D7-4BBA-BA37-838328226DD6@brianrosen.net>
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> <30a05d55-3aee-3195-3e2e-9ac1d92b886d@alum.mit.edu> <797A336B-0D32-4D4F-AF16-C5D8A4648D22@brianrosen.net> <414e3fa5-ae0f-a632-af75-f34f2842d85c@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/a2jAbb8_2P2fe68RPlak5Q1dJmI>
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 15:34:31 -0000

Good discussion to have.

A cert is public, so no real privacy issues other than what is in the identity (which a username gives you also).  How the private key associated with the cert is handled is of concern, but I imagine it’s the usual CSR thing which never reveals the key.  But we do need some kind of security on the provisioning information itself.  If there was a cert, then the provisioning could be signed by or for the rue.  I kind of like that.  It’s all new mechanism, but maybe worthwhile.  You run code on the device that creates the CSR, upload it, and download the cert.  Then the rue can sign the provisioning file (which really doesn’t need the cert, so it could do that any time).

There are two contact maintenance mechanisms in the draft now - file upload/download and CardDAV.  CardDAV is okay security-wise.  File upload and download is from a provider, so we could have providers sign the file with the cert so only that user could verify it.

Brian

> On Aug 28, 2019, at 11:14 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> On 8/28/19 10:41 AM, Brian Rosen wrote:
>> Ever since I’ve been working on this doc, the cert was for mutual auth of the user, instead of username and password.
> 
> OK. As long as we are clear that is what it is about.
> 
>> We get to use the IETF’s best practice here.  Do we require a RUM device to support mutual auth, or not?  We’re always going to support username and password for authentication.
>> We get to decide what else.
> 
> We've already been dinged about passing passwords around in configuration. Is it better if we use a password to fetch an initial device configuration that includes certs?
> 
> I think we need to have a new discussion of the overall security setup, including access to address book and video mail. Are they all under a single credential, or separate. Also how passwords expire and are refreshed/updated, etc. IIRC there were concerns about all of these.
> 
> 	Thanks,
> 	Paul
> 
>> Brian
>>> On Aug 28, 2019, at 9:47 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>> 
>>> 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
>