Re: [Rum] RUE client credentials

Brian Rosen <br@brianrosen.net> Tue, 27 August 2019 19:32 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 BDAAB120089 for <rum@ietfa.amsl.com>; Tue, 27 Aug 2019 12:32:16 -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 S7-vmxJB9obk for <rum@ietfa.amsl.com>; Tue, 27 Aug 2019 12:32:14 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 579CD120828 for <rum@ietf.org>; Tue, 27 Aug 2019 12:32:14 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id f10so219662qkg.7 for <rum@ietf.org>; Tue, 27 Aug 2019 12:32:14 -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=7ox1yFl6IDIS7FzxWgPH6tsTYdS56/bA7Ag5QCzOJFY=; b=V8/+f8uM521qbSq84K/QXYKZZ4UQOsRgq9Q+k5IwP/pX3d9OGB4stK3QsBcG/1yNs+ eGxp1m7350e+L9ggnIvaAygI+51KNPEiq6LT5cS89FPQ/N88O+DJT5Mmib4bCdj0Y25v nvWy2aKvtUejQnLpIy2mhb9HZv3O126p4FU2w8D+CjK/jOLMr34kWctcGxhI9J+g9l4J mZkU9wfbaXuJqoE4+5h1cfLqimQsLrI+Evxp4aS8koX/PiMp1EDJG/0QufPA4lOeaW34 Py6ZU5yhkvuIogfYRhST34mYvxJrFH6+yIB8kHxw2T1FskXmvEDiXf+v03m0m1T+h4ln gsqQ==
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=7ox1yFl6IDIS7FzxWgPH6tsTYdS56/bA7Ag5QCzOJFY=; b=BodHkLyJfjxQeEAIdFeFkF3SfH6jWyo3c0Y+bIw8JTuUIkughK+aT8nFo/NzZLmJpp ehU/rKMs17paz6jPtpeffQHmGk9bEI4utUKoeNK+GofFdgaVufuX/0YYvE9tnfUNJNjT BCK5xJhVDX+/OaoQf3kT0fgFfa5B/0Sg0lxzzewLJ+RPXIXsUeMrLkDrCdOwoT9o7IVV 5+VQAd3ziQchFGRA4PVm9qc1PIA9Y9PTk9y2H1h8JvaaGHbzt7mTWfShIklhVKfAvOgu Ulw1OhPsvkRDVoj6/1BIckapInVPwckhrBFPkNnfEbXsXhfiXrHJ0pxeh3/QJV/ytMXQ 59XA==
X-Gm-Message-State: APjAAAXs7+bVj+yttQDj6hlh/1ynWnvSmhIUDrw3vvlnpW9GME6X+SWK UX3rT8vsmGPLNh30CLMd7IByPg==
X-Google-Smtp-Source: APXvYqwQT5MS1MC4t6UcJiT0zIeRV07as8gmZzqnDx1rpjaH3iDHvMh30V3S3g4BEba2s1Xnpix26g==
X-Received: by 2002:a37:e10f:: with SMTP id c15mr130819qkm.219.1566934333276; Tue, 27 Aug 2019 12:32:13 -0700 (PDT)
Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id 143sm161777qkl.114.2019.08.27.12.32.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 12:32:12 -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: <054dde2a-7fa1-9941-986c-f3b3d8c0f76e@alum.mit.edu>
Date: Tue, 27 Aug 2019 15:32:11 -0400
Cc: rum@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <831AD5BE-0D8F-4968-ABC7-B8D52BB8D4B0@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>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/vedham5WgCxSyWxFyBzC-COzI0s>
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: Tue, 27 Aug 2019 19:32:17 -0000

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.

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

> 
> The idea was that certs would only be made available to *implementations* (e.g. images) that have been tested. There was no expectation that each user who obtains a rue would need to have it tested.
> 
> But the exact mechanism for binding a cert to a tested implementation was never worked out. I've asked around from time to time and I haven't learned of any way to achieve this.
> 
> Brian's new text pushes this off one level but doesn't solve the problem. The provider's *sip* server can perhaps trust that the rue got the cert from the provider's provisioning server. But the provisioning server still has to decide if this is a trustworthy implementation.
> 
> The Apple store and the Google Play Store solve this problem by being the distributor of apps. The developer has to submit the app, which is then tested/verified by the store and then being assigned credentials. Potentially we could have something list that by having a RUE Store operated by a RUE testing authority. But I don't think anybody is prepared to operate such a thing and it would require the devices receiving these apps to bypass the normal vendor restrictions on installations.
> 
> I don't have a good answer here.
> 
> 	Thanks,
> 	Paul
> 
>