Re: [Rum] Configuration file

A problem that has to be solved is key rollover - how do you change the  keys if you have X certificates that signed them?
Well, you can generate new CSRs for each provider based on a new key pairs, which means that you will have certs
ready (while the old ones are still in use) and manage your own roll over.

/O

> On 21 Oct 2020, at 16:50, Brian Rosen <br@brianrosen.net> wrote:
> 
> This is actually a good idea I think.  The light bulb for me was “same key pair”.
> 
> So suppose the device generated a key pair, and used a local passcode or pass phrase to access the private key.  For each provider, the provider issues a cert, and that cert is used for TLS client authentication.  Same key pair for each provider, different cert.  It would work for any provider to issue a cert that other providers accepted, but it would be an easier “sell”, I think, if they each issued a cert to their customer.  The cert can be used with TLS to retrieve a per-provider configuration file as well as SIP operations.  Persistent TLS could be used to avoid requiring entering credentials often at the user end.
> 
> Would that be acceptable?
> 
> Brian
> 
>> On Oct 21, 2020, at 1:28 AM, Olle E. Johansson <oej@edvina.net <mailto:oej@edvina.net>> wrote:
>> 
>> 
>> 
>>> On 20 Oct 2020, at 21:15, Brian Rosen <br@brianrosen.net <mailto:br@brianrosen.net>> 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.
>> 
>> To add to your list: Don’t forget about using TLS client certs. It’s not very hard, can securely be provisioned using Oauth or other means
>> and can be re-issued often. For the telco business it’s unusal, but it’s frequently used in other solutions, like VPNs.
>> 
>> You can one per provider, based on the same key pair or separate key pairs.
>> 
>> /O
> 
> -- 
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum