Subject: [Rum] Proposed Solution for Configuration

From: Brian Rosen <[email-masked]>
Date: Thu, 3 Dec 2020 12:25:27 -0500

Olle will have an alternative proposal, here is mine.

I start with the provider list.  There is a list of providers per country.  There is an IANA registry that has a country code and a URL to get that list.

The list has an entry per provider.  The entry has sets of data objects, one set per language supported.  Each set is an object with Iname for the provider, a URL for its configuration service, a URL for its customer sign up service, a URL for a help desk, and a SIP URI for a dial around front door.  

A user starts with the sign up service, which uses a browser.  The result is a username/password for the account.  

The RUE has an administrative account, which it maintains locally.  There is a username and password for that.  The RUE stores the URLs for a provider configuration service, username and password locally.  Only a user with the administrative username/password can see or change the data.

When the RUE restarts for any reason, or following a change in username/password, it connects to the configuration service via HTTPS, authenticates with username/password and provides the API Key.  If the API Key is good, the configuration service responds with all of the server information (Registrar, outbound proxy, TURN server, …) for that user.

The RUE then configures for that provider, REGISTERs with the stored username and password, and is then ready to place or receive calls.

I’m thinking about some cleverness where if the RUE provides the browser that is used to sign up, perhaps there is a secure way for the provider to download username/password so it can be locally stored as above, so the user doesn’t have to enter it into the RUE.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 5 Dec 2020 12:07:07 -0500

Brian,

With my chair hat OFF:

> The list has an entry per provider.  The entry has sets of data objects, one set per language supported.  Each set is an object with Iname for the provider, a URL for its configuration service, a U…

I agree with James on this: simplify the list and retrieve all the 
provider-specific data from the provider site, probably via well known URLs.

> A user starts with the sign up service, which uses a browser.  The result is a username/password for the account.

Can providers give us some insight here. Will there be any potential 
customers that need some alternative mechanism to a browser?

> The RUE has an administrative account, which it maintains locally.  There is a username and password for that.  The RUE stores the URLs for a provider configuration service, username and password locally. 

Hopefully the RUE can save information for more than one provider 
account - all those for which the user has accounts.

Question: is it permissible for a RUE to only support one provider? Only 
one particular provider?

> Only a user with the administrative username/password can see or change the data.

Can someone without the admin id/pw make and answer calls? (I presume yes.)

If so, what can a person without the admin id/pw see? I think they 
should be able to see the phone numbers assigned to each provider 
account, and probably the names of the corresponding providers.

> When the RUE restarts for any reason, or following a change in username/password, it connects to the configuration service via HTTPS, authenticates with username/password and provides the API Key.…

When you say "change in username/password" above, which one do you mean?

The RUE won't necessarily know when the id/pw for the provider account 
changes. What it can know soonest is when the registration to the sip 
server ends and an attempt to register is rejected for a bad password. 
(Or similar failure when attempting to access address book.)

If that happens, reloading the configuration should get fresh versions 
of needed credentials.

It is more of a problem if the provider has need to force a change in 
the password for the users web account. But that is much like any web 
account, where typically the user is given a long time to make a change.

Perhaps there needs to be an indicator in the configuration data that 
the user needs to contact the provider.

> I’m thinking about some cleverness where if the RUE provides the browser that is used to sign up, perhaps there is a secure way for the provider to download username/password so it can be locally s…

Yes, that would be very helpful.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Mon, 7 Dec 2020 10:20:04 -0500

Responses in line (as author/contributor)

> On Dec 5, 2020, at 12:07 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Brian,
> 
> With my chair hat OFF:
> 
> I agree with James on this: simplify the list and retrieve all the provider-specific data from the provider site, probably via well known URLs.
Will Do
> Can providers give us some insight here. Will there be any potential customers that need some alternative mechanism to a browser?
There is no problem doing this, as long as the result is an account with username/password
> Hopefully the RUE can save information for more than one provider account - all those for which the user has accounts.
Yes, that was the idea
> 
> Question: is it permissible for a RUE to only support one provider? Only one particular provider?
Our goal was to not do that, but of course it’s possible.

> Can someone without the admin id/pw make and answer calls? (I presume yes.)
Yes, in the same sense that if any existing device is logged in, and someone other than the account owner is sitting in front of it, it will work,  There are legal implications of that in some jurisdictions, but no device I know requires login per call.

> 
> If so, what can a person without the admin id/pw see? I think they should be able to see the phone numbers assigned to each provider account, and probably the names of the corresponding providers.
Yeah, although that’s probably not something I think we would put in the doc other than possibly noting that’s an issue in the security considerations.

> When you say "change in username/password" above, which one do you mean?
“Forgot Password” type reset, or something where the username has to change.  If either changes, the local file has to change

> 
> The RUE won't necessarily know when the id/pw for the provider account changes. What it can know soonest is when the registration to the sip server ends and an attempt to register is rejected for a bad password. (Or similar failure when attempting to access address book.)
Yeah, and I don’t think we care.  There would have to be UI to change it, and there might be errors until it does.  If it’s changes, REGISTER would be re-run.

> 
> If that happens, reloading the configuration should get fresh versions of needed credentials.
There is only the local file.  If one account changes, nothing would affect other accounts.  What other credentials are there?
> 
> It is more of a problem if the provider has need to force a change in the password for the users web account. But that is much like any web account, where typically the user is given a long time to make a change.
Yes
> 
> Perhaps there needs to be an indicator in the configuration data that the user needs to contact the provider.
More UI stuff that probably isn’t in the spec.
> -- 
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 7 Dec 2020 11:00:56 -0500

Hi Brian,

More inline.

>> On Dec 5, 2020, at 12:07 PM, Paul Kyzivat <[email-masked]> wrote:
[snip]
> There is no problem doing this, as long as the result is an account with username/password

I guess worst case is that a potential customer without any browser 
device might need to request the assistance of somebody with a browser 
to do the initial signup. Given that pretty much any cell phone has this 
capability that is probably not too much to ask. So I agree we should be 
able to ignore this as a problem.

> Our goal was to not do that, but of course it’s possible.

The question is whether one or both of these features should be part of 
the spec.

> Yes, in the same sense that if any existing device is logged in, and someone other than the account owner is sitting in front of it, it will work,  There are legal implications of that in some juri…

Again, we should consider whether this needs to be part of the spec.

> Yeah, although that’s probably not something I think we would put in the doc other than possibly noting that’s an issue in the security considerations.

Seems worthwhile to say *something*, even if non-normative.

> “Forgot Password” type reset, or something where the username has to change.  If either changes, the local file has to change

I think your intent was regarding change in the administrative id/pw. 
But the text wasn't clear about that. You might have meant to include 
change to the one of the id/pws that had previously been loaded via the 
configuration. I was just seeking clarification of the text.

> Yeah, and I don’t think we care.  There would have to be UI to change it, and there might be errors until it does.  If it’s changes, REGISTER would be re-run.

I'm just seeking clarity in how various issues are indicated by the 
provider and how the RUE is expected to respond to them so that the RUE 
isn't required to have provider-specific logic in order to provide good 
service.

> There is only the local file.  If one account changes, nothing would affect other accounts.  What other credentials are there?

IIUC, the configuration downloaded by the RUE from a provider contains 
credentials for sip registration, address book sync, etc. If the 
provider finds a need to change those, it should not require a reload of 
the RUE or any overt action by the user for the RUE to discover that it 
needs to reload the configuration to fix the problem.

And this is independent for each provider the RUE is attached to.

> More UI stuff that probably isn’t in the spec.

What the UI looks like in response is out of scope. But an indicator in 
the config that action by the user is required could be in scope.

Perhaps we could simply include in the config some announcement text 
that the RUE should display to the user.

Alternately we could just assume that if the provider needs to alert the 
user of some needed action then it has other means, such as email, to 
send that alert.

	Thanks,
	Paul