Re: [Rum] Configuration file

Brian Rosen <br@brianrosen.net> Wed, 21 October 2020 16:04 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 CE5B73A128A for <rum@ietfa.amsl.com>; Wed, 21 Oct 2020 09:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 zLTuT-BiJBae for <rum@ietfa.amsl.com>; Wed, 21 Oct 2020 09:04:16 -0700 (PDT)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 882933A10AA for <rum@ietf.org>; Wed, 21 Oct 2020 09:04:16 -0700 (PDT)
Received: by mail-qv1-xf36.google.com with SMTP id s17so1351838qvr.11 for <rum@ietf.org>; Wed, 21 Oct 2020 09:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VgH7oWnUyy38aL3duMUteywmvs6B/S8SDqogBjdTZmQ=; b=zN+V0T5CRoKVQH4SjtdBXidc7TTmiu8IpTqH5D5ELf0pVP2sbdx9rvXo/OUZdQ6ZF8 upSIgHBHIMLN5VVg58yDEc5L+ekdMJEzqQHtyM8GuiWMOfn972cfJljL1qcjN7SyoiJV sxLe/tq2qDEscT6jF7bdpU9n9d5Dg9KPeltvWEQdgsZWKPA6XTadjCIyKT6aPCa2L/Mo 2IwPvAh2awNmEKyBjbu0QJkiSm1xq/pOJU4xOuIWQafxRAjwCnT8DciYwG1bWQVFE85H F7wou9cCnp4g9vs5Vroqc+aYLLq4VcwkGC0tx7NrQideyNIgvrYE+MCyj6bzHTEE60HO +5Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VgH7oWnUyy38aL3duMUteywmvs6B/S8SDqogBjdTZmQ=; b=rdZMm1kHYr/lwQqj1CPPW6qlDKjuowKiP1oCkHX2XQxW7gGTaWEvUb+LdPBFai7EK/ lZ0owmczmSG2+35jPuWdKqpH9Fw5j1QlqyhSOsdmSdU7/YI70UwsGFWEMGD9fkdyJupj qH+7Tq3hvGJ/cmQ6OmMDCjsrvaRG9XTmZObEZ63yUELJ0L1rMSPWW2Tg13nqTCD2hhi3 gjxA80oj5l5dtNaaO5GU/euL/mtruy0Xn68wDLK3biXZCm3RbOn/k85SAc93AEAVLV9Y SmPGYVXa4bqe7seyBXi3o1BT2Gp72iBHrWuktWu5AqIWfdY4OlW00YfQuyDIZ5gbyGG3 cShA==
X-Gm-Message-State: AOAM531WxPxLL8b9KPkFfa5O5FfLDDYZTYptWQIaT1NDqgUe+T/i5BLQ c4vg3zozYg7Zn5DXFVPnrw50FA==
X-Google-Smtp-Source: ABdhPJw0VpR4sYQ+/HHcGGh6mViHgS1eDgjsECsI4oKDboQWW3J5Jpak9TOk1GCbSnNEkruP+03ijA==
X-Received: by 2002:a05:6214:180f:: with SMTP id o15mr2752775qvw.16.1603296255397; Wed, 21 Oct 2020 09:04:15 -0700 (PDT)
Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id g15sm1500776qki.107.2020.10.21.09.04.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2020 09:04:14 -0700 (PDT)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <AE3E626F-39F0-4549-8E8B-78F1B0B8BC9B@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_22627886-4CAC-443D-BE61-F863B93E5923"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Wed, 21 Oct 2020 12:04:13 -0400
In-Reply-To: <e353ef87-1814-87b8-8a5e-52f8e325c54e@alum.mit.edu>
Cc: rum@ietf.org
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <B8C4519D-60F7-4AA0-BE5F-2494578656DB@brianrosen.net> <e353ef87-1814-87b8-8a5e-52f8e325c54e@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/pOBIrU3khMjZTSr8zZqoK8fyCXw>
Subject: Re: [Rum] Configuration file
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, 21 Oct 2020 16:04:19 -0000

Yeah, my model was different.  It assumed that whatever was done by the provider, the result was a single local file.

I’m not wedded to that.  We do need at least a piece of that to know which providers to look for, but a file per provider, downloaded when it’s needed is okay.

Brian


> On Oct 21, 2020, at 11:55 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> On 10/20/20 3:15 PM, Brian Rosen wrote:
>> This is still an open item and distinct from the “signed code” issue we’ve been discussing.
>> The current text describes a single file that can have multiple sets of provider configuration data.  This caters to the common case of a user having more than provider account.  The problem with the text is it has plaintext username/passwords, which is clearly wrong.
>> I see two solutions: require the local implementation to maintain a password (or other multi factor authentication, and encrypt the file so that the user needs to authenticate to access the file.  Paul is worried that the login data may be needed more frequently than is reasonable to enter the authentication data locally.
>> The other is to maintain separate files in provider systems, with a common authentication mechanism in each provider to access the file.
>> I think Paul’s argument doesn’t really hold much water: no SIP device I know of requires re-authentication that requires user interaction very often, so whatever they do now is okay.  I think they just keep the data locally, secure enough to re-use when they need to.  So unlock once, good for a very long time.
>> I’m reluctant to require all providers use the new OAUTH2 solution, but if they were okay with it, that would be excellent.  We would need some notion of common username, but otherwise it would just work.  Seems way too different from how things work now.  Very attractive, secure, and user-friendly.
> 
> My concern was with one configuration file vs. a separate one for each provider. This is rooted in how the file would be provisioned in the device.
> 
> My assumption is that this configuration is generated by the provider based on the user doing a web-based enrollment on the provider's web site, followed by the device downloading that configuration. If the user has accounts with different providers then this would happen separately for each, resulting is separate configuration files.
> 
> Do you have a different model in mind for how this would happen?
> 
> 	Thanks,
> 	Paul
> 
> -- 
> Rum mailing list
> Rum@ietf.org <mailto:Rum@ietf.org>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>