Re: [Rum] [EXT] RUM security model

[Jim Malloy <[e-mail]>]

Got it.

Every existing VRS provider, in some manner, manages to cache configuration information and credentials on their devices (proprietary, Windows, Android, iOS) today.  Does this demonstrate that we're not in the "magic" domain? Or, is the challenge that each provider uses a (potentially) proprietary mechanism which impacts how and what data needs to be transmitted?

Thanks,

Jim Malloy
Principal Information System Engineer
The MITRE Corp.
703 983 2835

-----Original Message-----
From: Rum <[e-mail]> On Behalf Of Paul Kyzivat
Sent: Tuesday, September 29, 2020 12:16 PM
To: [e-mail]
Subject: Re: [Rum] [EXT] RUM security model

Jim,

On 9/29/20 7:48 AM, Jim Malloy wrote:
> Paul -
> 
> Quick clarification - when you said "Credentials held by the RUM 
> device in support of (1) and (2) must be secured", were you referring 
> to secured in transit or secured while stored on the RUM device?  If 
> the latter, does this fall within the scope of this document?  ("This 
> document describes the interface between a videophone and a 
> provider".)
> 
> I agree that device characteristics, including security, is an important topic, but not one we've been addressing.

I meant secured on the device.

IMO some aspects of this have to be in scope. It would be irresponsible to specify an interface that requires magic to be secured on the device. 
The mechanism(s) used to secure things on the device are likely to impact the interface with the provider even though the *precise* mechanisms used locally to accomplish this will be out of scope.

In any case, the statements are my personal thoughts on what is needed to have a viable spec. Obviously these are subject to discussion and revision.

	Thanks,
	Paul

> Thanks,
> 
> Jim Malloy
> Principal Information System Engineer
> The MITRE Corp.
> 703 983 2835
> 
> -----Original Message-----
> From: Rum <[e-mail]> On Behalf Of Paul Kyzivat
> Sent: Saturday, September 26, 2020 1:21 PM
> To: [e-mail]
> Subject: [EXT] [Rum] RUM security model
> 
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/rum