Re: [Rum] RUM security model

I think we do want the spec to support multiple providers on one device/user.  I think that’s the point of having the file.  If it wasn’t them the user could just use the password for the single provider directly and not need any other mechanism.

ISTM that if the user has a password (and possibly a second factor like a USB security device), then it can securely unlock a local resource that contains the credentials.  They can be stored encrypted, where the decrypt requires the passwords at least initially.

The simplest model is perhaps too simple: a local encrypted file containing sign-on credentials that is decrypted with the user entering a password.  That is one password per user regardless of how many providers they use.

> On Sep 26, 2020, at 1:20 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> 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.
> 
> -- 
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum