Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Sep 2020 11:52:22 -0400

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.

The new text about uploading the geoloc to the registrar seems to 
introduce an additional issue for the security considerations section.

Another thing not discussed here is the desire by the providers to have 
a mechanism to restrict access to client implementations that have been 
previously validated. AFAIK this is hard to achieve. I don't think a 
workable mechanism has been proposed.

	Thanks,
	Paul

On 8/25/20 5:00 PM, Brian Rosen wrote:
> This version tries to address comments made.  The most extensive change 
> is the schemas, which are now full json schemas and pass validation, as 
> well as a check to make sure the examples validate to the schemas.
> 
> I haven’t done anything about the config file password issue yet, and 
> there are at least 2 or 3 other dangling items.  I’ll start separate 
> threads on those.
> 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-03.txt 
> <https://tools.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-03.txt> may be 
> helpful for you to see what I did.
> 
> Brian
> 
> 
>> On Aug 25, 2020, at 4:49 PM, [email-masked] 
>> <mailto:[email-masked]> wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Relay User Machine WG of the IETF.
>>
>>        Title           : Interoperability Profile for Relay User Equipment
>>        Author          : Brian Rosen
>> Filename        : draft-ietf-rum-rue-03.txt
>> Pages           : 32
>> Date            : 2020-08-25
>>
>> Abstract:
>>   Video Relay Service (VRS) is a term used to describe a method by
>>   which a hearing persons can communicate with deaf/Hard of Hearing
>>   user using an interpreter ("Communications Assistant") connected via
>>   a videophone to the deaf/HoH user and an audio telephone call to the
>>   hearing user.  The CA interprets using sign language on the
>>   videophone link and voice on the telephone link.  Often the
>>   interpreters may be supplied by a company or agency termed a
>>   "provider" in this document.  The provider also provides a video
>>   service that allows users to connect video devices to their service,
>>   and subsequently to CAs and other dead/HoH users.  It is desirable
>>   that the videophones used by the deaf/HoH/H-I user conform to a
>>   standard so that any device may be used with any provider and that
>>   video calls direct between deaf/HoH users work.  This document
>>   describes the interface between a videophone and a provider.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ 
>> <https://datatracker.ietf.org/doc/draft-ietf-rum-rue/>
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-rum-rue-03
>> https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-03
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-03
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> -- 
>> Rum mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rum
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 26 Sep 2020 13:20:57 -0400

> 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.

---

From: Brian Rosen <[email-masked]>
Date: Sat, 26 Sep 2020 20:58:18 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 27 Sep 2020 00:35:54 -0400

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

Yes, I think it is too simple. The RUE needs access to those sign-on 
credentials in situations where the user isn't present. For instance, 
suppose it is restarted due to power failure. Then it must reregister 
ASAP in order to be available to receive incoming calls. There are lots 
of other cases as well.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Sep 2020 15:33:01 -0400

On 9/27/20 12:35 AM, Paul Kyzivat wrote:
>> 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.
> 

I definitely am not up to speed on the state of the art in this area. I 
wonder if we can recruit an expert to help. Perhaps request a security 
review.

	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 29 Sep 2020 08:07:36 +0200

> On 28 Sep 2020, at 21:33, Paul Kyzivat <[email-masked]> wrote:
> 
>> Yes, I think it is too simple. The RUE needs access to those sign-on credentials in situations where the user isn't present. For instance, suppose it is restarted due to power failure. Then it must reregister ASAP in order to be available to receive incoming calls. There are lots of other cases as well.
> 
> I definitely am not up to speed on the state of the art in this area. I wonder if we can recruit an expert to help. Perhaps request a security review.
> 
I think RUM is a perfect use-case for the new Oauth2/OpenID Connect auth mechanism in SIP.

/O

---

From: Jim Malloy <[email-masked]>
Date: Tue, 29 Sep 2020 11:48:42 +0000

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. 

Thanks,

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

-----Original Message-----
From: Rum <[email-masked]> On Behalf Of Paul Kyzivat
Sent: Saturday, September 26, 2020 1:21 PM
To: [email-masked]
Subject: [EXT] [Rum] RUM security model

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.

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.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Sep 2020 08:58:01 -0400

While I personally think thats the way to go, most existing providers use
the existing registration mechanisms. If they were supportive of using
OAUTH2 instead, I would be VERY happy to make that change.

But that wouldn’t solve the problem we are discussing, which is how the RUE
device maintains credentials from multiple providers.  I suppose the
providers could use another provider as a identity provider for the
purposes of logging in their own customer, but that is even more remote
from where they are now.

Brian

On Tue, Sep 29, 2020 at 2:08 AM Olle E. Johansson <[email-masked]> wrote:

> 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.
>
> >>>
>
> 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.
>
> >>>
>
> 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.
>
> suppose it is restarted due to power failure. Then it must reregister ASAP
> in order to be available to receive incoming calls. There are lots of other
> cases as well.
>
> >
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Sep 2020 12:16:09 -0400

Jim,

> 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

---

From: Jim Malloy <[email-masked]>
Date: Tue, 29 Sep 2020 17:13:56 +0000

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

-----Original Message-----
From: Rum <[email-masked]> On Behalf Of Paul Kyzivat
Sent: Tuesday, September 29, 2020 12:16 PM
To: [email-masked]
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".)
> 

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 for reviving this and resolving some of the open issues. I 
>> hope we can soon identify and resolve remaining issues.
>>
> when no user is present. (Not different from many sip devices, but 
> worth calling out.)
> 
> 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.)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Sep 2020 13:27:59 -0400

> 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'r…

Right now the entire mechanism is proprietary and may well depend on 
security by obscurity.

Further, the intent here is to open things up to open source 
implementations. Those definitely can't rely on obscurity. (Though 
*nobody* should.)

These are the discussions we should be having.

	Thanks,
	Paul

---

From: Eugene Christensen <[email-masked]>
Date: Wed, 30 Sep 2020 22:30:20 +0000

Thanks for considering how we might implement this security mechanism.  May I add my voice that it is essential that we find an option for providing this desired security, whatever it is.  It could be detrimental to the VRS providers to have UAs out there, with the ability to register with VRS providers without first being fully vetted.  It is our practice anytime we make updates to our UAs to test how they work with our UAS before we ever release the new UA software into our production environment.  We only want UAs registering that have undergone this rigorous testing with our systems and then only with users which we have awareness of.

Thanks, 
Eugene Christensen

CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at [email-masked] or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 30 Sep 2020 19:46:48 -0400

I think we understand why you want it. What we don’t understand is what
mechanism would provide it. I am generally aware of this class of problem
and I’m not aware of a solution that will work.  So what we need is a
suggested mechanism that provides the assurance you want that is
technically sound.

Brian

On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen <
[email-masked]> wrote:

> Thanks for considering how we might implement this security mechanism.
> May I add my voice that it is essential that we find an option for
> providing this desired security, whatever it is.  It could be detrimental
> to the VRS providers to have UAs out there, with the ability to register
> with VRS providers without first being fully vetted.  It is our practice
> anytime we make updates to our UAs to test how they work with our UAS
> before we ever release the new UA software into our production
> environment.  We only want UAs registering that have undergone this
> rigorous testing with our systems and then only with users which we have
> awareness of.
>
>
>
> Thanks,
>
> Eugene Christensen
>
>
>
> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files
> or previous e-mail messages attached to it, may contain confidential and
> proprietary information. If you are not the intended recipient, or a person
> responsible for delivering it to the intended recipient, you are hereby
> notified that any disclosure, copying, distribution or use of any of the
> information contained in or attached to this message is STRICTLY
> PROHIBITED. If you have received this transmission in error, please
> immediately notify me by reply e-mail at [email-masked] or by
> telephone at +1 (801) 287-9419, and destroy the original transmission and
> its attachments without reading them or saving them to disk.
>
>
>
> --
>
> Rum mailing list
>
> [email-masked]
>