[Rum] RUM security model

[Paul Kyzivat <[e-mail]>]

On 9/18/20 11:52 AM, Paul Kyzivat wrote:
> Brian,
> 
> Thanks for reviving this and resolving some of the open issues. I hope 
> we can soon identify and resolve remaining issues.
> 
> I do think the password issue is going to be tricky to sort out. We 
> should get a discussion going on it. I'm thinking that we may need a 
> whole section discussing the security model.

Some brainstorming on this - half baked thoughts:

1) In many cases a RUM device is an always-on device. It must possess 
credentials that allow it to remain authenticated to a registrar even 
when no user is present. (Not different from many sip devices, but worth 
calling out.)

2) It is the user (owner?) of the RUM device that must first 
authenticate to a provider. This authentication then needs to be 
delegated to the RUM device to satisfy the requirements of (1).

3) There will be a need for the *user* to periodically reauthenticate. 
This may sometimes be time based, but may also be required when the 
device or server have been compromised, etc. This can be a problem if it 
occurs when the user isn't immediately available. In most cases the RUM 
device should still be allowed to remain registered for receipt of 
incoming calls until such time as a user is present to participate in 
reauthentication.

4) Credentials held by the RUM device in support of (1) and (2) must be 
secured. It should be impossible for an attacker to extract these 
credentials and reuse them in another device. (This is hard. We may not 
be able to fully achieve it in the spec. But we need to consider it.)

5) The security system for RUM devices must be compatible with RUM 
devices that support simultaneous registration to multiple VRS 
providers. However there is no requirement for a RUM device to support 
this feature. (It isn't clear to me if this requirement imposes any 
particular burden on the spec. I only bring it up to cover all the bases.)

Note:

In the above I keep using the term "RUM device". I did this because I 
*think* RUE is a more generic term that encompasses both RUM compliant 
devices and non-compliant ones like existing proprietary VRS provider 
supplied user devices.

I think it is too late to restrict the definition of RUE to being 
compliant to RUM, since it is used in the more generic sense in the 
provider profile. I'm content to keep using "RUM device" but I'm open to 
other suggestions. In any case, whatever we decide should go into the 
definitions.