Subject: [Rum] Configuration file

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Oct 2020 15:15:43 -0400

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.

Brian

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 21 Oct 2020 07:28:06 +0200

> On 20 Oct 2020, at 21:15, Brian Rosen <[email-masked]> wrote:
> 

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 21 Oct 2020 10:50:58 -0400

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 <[email-masked]> wrote:
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2020 11:55:34 -0400

> 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 jus…

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 21 Oct 2020 12:04:13 -0400

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 <[email-masked]> wrote:
> 
> 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.
> 
> -- 
> Rum mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2020 12:39:27 -0400

On 10/21/20 12:04 PM, Brian Rosen wrote:
> 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.

Yes, the list of providers needs to be from a single source. That will 
present some administration challenges. But I don't think it makes sense 
for the providers to populate that with all the details needed for a RUE 
to connect to them.

It occurs to me that we might be able to get away with using DNS to hold 
the list of providers - avoiding the need to stand up a special server 
for that purpose.

I'm thinking that the RUE have a way to present the user with a list of 
available providers. The user would be able to select one and then ask 
to enroll with it. Then the user would get a browser connection to an 
enrollment page where he would sign up for service, be assigned a user 
name, password, and phone number. Then the device would connect to the 
config download service of the provider and download the configuration 
file. The RUE would save this. The RUE would then use the configuration 
info to do a SIP registration and be ready to both receive and initiate 
calls.

The RUE could do this for multiple providers. The result would 
presumably be a UI for something akin to a multi-line phone. (Remember 
those from the old days?)

	Thanks,
	Paul

> Brian
> 
> 
>> On Oct 21, 2020, at 11:55 AM, Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> 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.
>>
>> 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.
>>
>> https://www.ietf.org/mailman/listinfo/rum 
>> <https://www.ietf.org/mailman/listinfo/rum>
> 
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 21 Oct 2020 19:16:44 +0200

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 <[email-masked]> wrote:
> 
>> On Oct 21, 2020, at 1:28 AM, Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>>> On 20 Oct 2020, at 21:15, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> [email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Thu, 22 Oct 2020 09:11:35 -0400

Yes, I think that would work fine.  We would have to write text that said that.  We also would probably want to have text that made the upload of CSRs automated.

Brian

> On Oct 21, 2020, at 1:16 PM, Olle E. Johansson <[email-masked]> wrote:
> 
>> On 21 Oct 2020, at 16:50, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 22 Oct 2020 09:17:55 -0400

How would we use DNS to hold the list of providers?  Seems to me that the official list, at least in some places like the US, is controlled by the regulator.  That isn’t the case in other countries.  Where it is, there is an authoritative source.  Could we make the list a registry, make it country specific, and have an expert decide if a provider should be added to the list?

I think your description of signup and config is good.

Yes, I remember multi-line phones.  I have a SIP multi-line phone on my desk that has “lines” from multiple providers.

Brian

> On Oct 21, 2020, at 12:39 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Yes, the list of providers needs to be from a single source. That will present some administration challenges. But I don't think it makes sense for the providers to populate that with all the details needed for a RUE to connect to them.
> 
> It occurs to me that we might be able to get away with using DNS to hold the list of providers - avoiding the need to stand up a special server for that purpose.
> 
> I'm thinking that the RUE have a way to present the user with a list of available providers. The user would be able to select one and then ask to enroll with it. Then the user would get a browser connection to an enrollment page where he would sign up for service, be assigned a user name, password, and phone number. Then the device would connect to the config download service of the provider and download the configuration file. The RUE would save this. The RUE would then use the configuration info to do a SIP registration and be ready to both receive and initiate calls.
> 
> The RUE could do this for multiple providers. The result would presumably be a UI for something akin to a multi-line phone. (Remember those from the old days?)
> 
> 	Thanks,
> 	Paul
> 
>> Brian
>>> On Oct 21, 2020, at 11:55 AM, Paul Kyzivat <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum> <https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>>
> 
> -- 
> Rum mailing list

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Oct 2020 12:03:57 -0400

On 10/22/20 9:17 AM, Brian Rosen wrote:
> How would we use DNS to hold the list of providers? 

We could simply create a zone as the root for a regulatory entity, and 
then populate it with A and AAAA entries for each provider in the 
regulatory domain. (There would need to be some way to provision the RUE 
with the zone to consult.)

Or perhaps SRV records could be used for this.

My point is simply that a single domain name or URL per provider could 
be sufficient to bootstrap connecting to the corresponding provider. It 
would require establishing some conventions for how to do the bootstrapping.

> Seems to me that 
> the official list, at least in some places like the US, is controlled by 
> the regulator.  That isn’t the case in other countries.  Where it is, 
> there is an authoritative source.  Could we make the list a registry, 
> make it country specific, and have an expert decide if a provider should 
> be added to the list?

This *might* work given that the set of providers doesn't change 
rapidly. But if/when it does change it isn't evident how deployed RUEs 
would be updated. I guess it might just be treated as part of normal 
maintenance updates, however they are done.

> I think your description of signup and config is good.

It is just a rough start. It needs more discussion and fleshing out. I 
don't know if this needs to be normative. (It might just be something 
such as a non-normative annex.) The main value is to ensure that the 
mechanisms needed to support it *are* defined and normative.

	Thanks,
	Paul

> Yes, I remember multi-line phones.  I have a SIP multi-line phone on my 
> desk that has “lines” from multiple providers.
> 
> Brian
> 
> 
>> On Oct 21, 2020, at 12:39 PM, Paul Kyzivat <[email-masked] 
>>> Yeah, my model was different.  It assumed that whatever was done by 
>>> the provider, the result was a single local file.
>> present some administration challenges. But I don't think it makes 
>> sense for the providers to populate that with all the details needed 
>> for a RUE to connect to them.
>>
>> It occurs to me that we might be able to get away with using DNS to 
>> hold the list of providers - avoiding the need to stand up a special 
>> server for that purpose.
>>
>> I'm thinking that the RUE have a way to present the user with a list 
>> of available providers. The user would be able to select one and then 
>> ask to enroll with it. Then the user would get a browser connection to 
>> an enrollment page where he would sign up for service, be assigned a 
>> user name, password, and phone number. Then the device would connect 
>> to the config download service of the provider and download the 
>> configuration file. The RUE would save this. The RUE would then use 
>> the configuration info to do a SIP registration and be ready to both 
>> receive and initiate calls.
>>
>>>> <mailto:[email-masked]><mailto:[email-masked] 
>>>> <mailto:[email-masked]>>> wrote:
>>>>
>>>>> 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.
>>>>> 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.
>>>>> 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.
>>>> 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.
>>>>
>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] 
>>>> <mailto:[email-masked]>>
>>>> <https://www.ietf.org/mailman/listinfo/rum><https://www.ietf.org/mailman/listinfo/rum 
>>>> <https://www.ietf.org/mailman/listinfo/rum>>
>>
>> --
>> Rum mailing list

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 22 Oct 2020 18:08:20 +0200

Sounds like you are discussing a SAML-like trust model…

Just hinting.

/O

> On 22 Oct 2020, at 18:03, Paul Kyzivat <[email-masked]> wrote:
> 
> We could simply create a zone as the root for a regulatory entity, and then populate it with A and AAAA entries for each provider in the regulatory domain. (There would need to be some way to provision the RUE with the zone to consult.)
> 
> My point is simply that a single domain name or URL per provider could be sufficient to bootstrap connecting to the corresponding provider. It would require establishing some conventions for how to do the bootstrapping.
> 
>> Seems to me that the official list, at least in some places like the US, is controlled by the regulator.  That isn’t the case in other countries.  Where it is, there is an authoritative source.  Could we make the list a registry, make it country specific, and have an expert decide if a provider should be added to the list?
> 
> This *might* work given that the set of providers doesn't change rapidly. But if/when it does change it isn't evident how deployed RUEs would be updated. I guess it might just be treated as part of normal maintenance updates, however they are done.
> 
> It is just a rough start. It needs more discussion and fleshing out. I don't know if this needs to be normative. (It might just be something such as a non-normative annex.) The main value is to ensure that the mechanisms needed to support it *are* defined and normative.
> 
> 	Thanks,
> 	Paul
> 
>>> On Oct 21, 2020, at 12:39 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
>>>>> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum><https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>>
>>> 
>>> --
>>> Rum mailing list