Subject: Re: [Rum] [EXT] RUM security model

From: Eugene Christensen <[email-masked]>
Date: Thu, 15 Oct 2020 19:30:52 +0000

Brian,

Admittedly I do not fully understand certificates and authentication but would client certificates or mutual authentication with a shared secret work here?

Thank you.

Eugene

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]<mailto:[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]>
Sent: Wednesday, September 30, 2020 5:47 PM
To: Eugene Christensen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] [EXT] RUM security model

[EXTERNAL]
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]<mailto:[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]<mailto:[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]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/rum

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Oct 2020 18:29:31 -0400

Eugene,

On 10/15/20 3:30 PM, Eugene Christensen wrote:
> Brian,
> 
> Admittedly I do not fully understand certificates and authentication but 
> would client certificates or mutual authentication with a shared secret 
> work here?

I'm also not a security expert. To my understanding, the key problem is 
that you want a proof that an implementation has passed some sort of 
test. That is more or less equivalent to having a special certification 
authority that is able to assign a certificate based on the passing of a 
test. But for the system to work that certificate needs to be bound to 
the entity (hw/sw) that passed the test. It can't be possible to 
transfer that certificate to a different device.

A possible alternative would be for each provider to have its own test 
service. When a user gets a new device/application, as part of the 
initial registration of their device with the provider, this test would 
be run. Then the result of that would be granting of credentials for 
that device to access that provider's system.

	Thanks,
	Paul

> Thank you.
> 
> Eugene
> 
> *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] <mailto:[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]>
> *Sent:* Wednesday, September 30, 2020 5:47 PM
> *To:* Eugene Christensen <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Rum] [EXT] RUM security model
> 
> [EXTERNAL]
> 
> 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] <mailto:[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]
>     <mailto:[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] <mailto:[email-masked]>
> 
>     <https://www.ietf.org/mailman/listinfo/rum>
> 
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 15 Oct 2020 19:52:39 -0400

I don’t think even that would work because there isn’t any way to know that the app that was approved is the app that is being used. 

What systems like iOS does is rely on the fact that you can’t download and run an app that hasn’t been vetted. The code is signed and the signature is checked every time the app starts. We don’t have an environment like that.  We can’t control what is downloaded and we can’t check signatures. 

I don’t think there is a reliable way to do this. If someone has an idea, please explain it, but we can’t be in a “you do something” position without a clue as to how. 

Now, if the app was an iOS app, then the right thing happens. There are few other systems that are wired down like that. Android, for example, allows you to download and run from arbitrary sites if the device is configured to allow that. 

Brian

> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Eugene,
> 
> I'm also not a security expert. To my understanding, the key problem is that you want a proof that an implementation has passed some sort of test. That is more or less equivalent to having a special certification authority that is able to assign a certificate based on the passing of a test. But for the system to work that certificate needs to be bound to the entity (hw/sw) that passed the test. It can't be possible to transfer that certificate to a different device.
> 
> A possible alternative would be for each provider to have its own test service. When a user gets a new device/application, as part of the initial registration of their device with the provider, this test would be run. Then the result of that would be granting of credentials for that device to access that provider's system.
> 
>    Thanks,
>    Paul
> 
>> Thank you.
>> Eugene
>> *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] <mailto:[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.
>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen <[email-masked] <mailto:[email-masked]>> wrote:
>>    --     Rum mailing list
> [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Oct 2020 20:19:37 -0400

> I don’t think even that would work because there isn’t any way to know that the app that was approved is the app that is being used.

Yes, I guess you are right. But at least it would require the end user 
to enter into a conspiracy with the app developers, and be able to get 
the credential out of one app and into another.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 15 Oct 2020 20:24:31 -0400

Nope, it just takes a hacker to create a piece of code that patches an app
to look like another app.

On Thu, Oct 15, 2020 at 8:19 PM Paul Kyzivat <[email-masked]> wrote:

> > I don’t think even that would work because there isn’t any way to know
> that the app that was approved is the app that is being used.
>
> > What systems like iOS does is rely on the fact that you can’t download
> and run an app that hasn’t been vetted. The code is signed and the
> signature is checked every time the app starts. We don’t have an
> environment like that.  We can’t control what is downloaded and we can’t
> check signatures.
>
> > I don’t think there is a reliable way to do this. If someone has an
> idea, please explain it, but we can’t be in a “you do something” position
> without a clue as to how.
> >
> > Now, if the app was an iOS app, then the right thing happens. There are
> few other systems that are wired down like that. Android, for example,
> allows you to download and run from arbitrary sites if the device is
> configured to allow that.
> >
> > Brian
> >
> >
> >>> Admittedly I do not fully understand certificates and authentication
> but would client certificates or mutual authentication with a shared secret
> work here?
> >>
> that you want a proof that an implementation has passed some sort of test.
> That is more or less equivalent to having a special certification authority
> that is able to assign a certificate based on the passing of a test. But
> for the system to work that certificate needs to be bound to the entity
> (hw/sw) that passed the test. It can't be possible to transfer that
> certificate to a different device.
> >>
> service. When a user gets a new device/application, as part of the initial
> registration of their device with the provider, this test would be run.
> Then the result of that would be granting of credentials for that device to
> access that provider's system.
> >>
> >>     Thanks,
> >>     Paul
> >>
> >>> Thank you.
> >>> Eugene
> 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]
> <mailto:[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.
> >>> 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] <mailto:[email-masked]>> wrote:

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 16 Oct 2020 11:13:17 +0000

A framework based on TPM could help but I am not sure whether mandating that is the right approach for this document. It may be sufficient to mention about the threat/possible remedy in the Security Considerations section.

Thanks,
Tolga

From: Rum <[email-masked]> On Behalf Of Brian Rosen
Sent: Thursday, October 15, 2020 8:25 PM
To: Paul Kyzivat <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] [EXT] RUM security model

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Nope, it just takes a hacker to create a piece of code that patches an app to look like another app.

On Thu, Oct 15, 2020 at 8:19 PM Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

        Thanks,
        Paul

>> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Eugene,
>>
>>> *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]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[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]<mailto:[email-masked]>>
>>> *To:* Eugene Christensen <[email-masked]<mailto:[email-masked]>>
>>> *Cc:* [email-masked]<mailto:[email-masked]>
>>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>     reply e-mail at [email-masked]<mailto:[email-masked]>
>>>     <mailto:[email-masked]<mailto:[email-masked]>> or by telephone at +1 (801)
>>>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>>     https://www.ietf.org/mailman/listinfo/rum<https://www.ietf.org/mailman/listinfo/rum>
>>>     <https://www.ietf.org/mailman/listinfo/rum<https://www.ietf.org/mailman/listinfo/rum>>
>>
>> --
>> Rum mailing list
>> https://www.ietf.org/mailman/listinfo/rum<https://www.ietf.org/mailman/listinfo/rum>

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2020 11:17:25 -0400

> app to look like another app.

I don't follow.

A user gets a device capable of passing the tests. He requests to enroll 
it with is provider as one of his devices. As part of that, a test is 
run between the device and the provider's enrollment server. Then the 
provider gives the device some sort of cert that can be used when 
registering.

Next, the user decides to try out some other rogue device on his 
account. Normally he would repeat the above, and the device would fail 
the test. Instead, he might cause the rogue device to steal the cert 
from the device that passed. I think he can't help but know he is doing 
something illicit.

I guess if these were both just apps, then a remote attack on the device 
could install a rogue app that impersonates the valid one and steals its 
credentials. Is that what you had in mind?

Perhaps we need to spend some time with the providers enumerating the 
attacks they are concerned with.

	Thanks,
	Paul

>      > I don’t think even that would work because there isn’t any way to
>     know that the app that was approved is the app that is being used.
> 
>      > What systems like iOS does is rely on the fact that you can’t
>     download and run an app that hasn’t been vetted. The code is signed
>     and the signature is checked every time the app starts. We don’t
>     have an environment like that.  We can’t control what is downloaded
>     and we can’t check signatures.
> 
>      > I don’t think there is a reliable way to do this. If someone has
>     an idea, please explain it, but we can’t be in a “you do something”
>     position without a clue as to how.
>      >
>      > Now, if the app was an iOS app, then the right thing happens.
>     There are few other systems that are wired down like that. Android,
>     for example, allows you to download and run from arbitrary sites if
>     the device is configured to allow that.
>      >
>      > Brian
>      >
>      >
>      >>> Admittedly I do not fully understand certificates and
>     authentication but would client certificates or mutual
>     authentication with a shared secret work here?
>      >>
>      >> I'm also not a security expert. To my understanding, the key
>     problem is that you want a proof that an implementation has passed
>     some sort of test. That is more or less equivalent to having a
>     special certification authority that is able to assign a certificate
>     based on the passing of a test. But for the system to work that
>     certificate needs to be bound to the entity (hw/sw) that passed the
>     test. It can't be possible to transfer that certificate to a
>     different device.
>      >>
>      >> A possible alternative would be for each provider to have its
>     own test service. When a user gets a new device/application, as part
>     of the initial registration of their device with the provider, this
>     test would be run. Then the result of that would be granting of
>     credentials for that device to access that provider's system.
>      >>
>      >>     Thanks,
>      >>     Paul
>      >>
>      >>> Thank you.
>      >>> Eugene
>      >>> *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
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>or by telephone at +1 (801)
>      >>> *From:* Brian Rosen <[email-masked] <mailto:[email-masked]>>
>      >>> *Cc:* [email-masked] <mailto:[email-masked]>
>      >>> 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
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     <mailto:[email-masked]>
>      >>>     <mailto:[email-masked]
>     <mailto:[email-masked]>> or by telephone at +1 (801)
>      >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>>     <https://www.ietf.org/mailman/listinfo/rum
>     <https://www.ietf.org/mailman/listinfo/rum>>
>      >>
>      >> --
>      >> Rum mailing list

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Oct 2020 10:10:28 -0400

Yes, both apps, one app steals the credential from the other (same machine, same user).

I also don’t think a downloaded test would be particularly helpful unless we built in a bunch of mechanism that allowed automation of testing.

And then, what would stop an app from playing nice with a test, and then nasty when it wanted to?

Both of these exploits do assume that the app developer intends to flaunt approval in some way.  If that’s not a threat that is important to guard against then a simple magic number for an app is enough.  An app gets tested by a provider, and is given a magic number that it provides, securely, in some way.  As long as the providers trust the app developer to not misuse the magic number, it’s an indication that the app (at a particular version presumably) was trusted.

As long as malicious actors can be ignored, I think we could do something.  I don’t think that is worth much, but if it is, I can write text.

If you want to protect against malicious actors, then I don’t know how.  TPM won’t work - doesn’t work in Android/iOS.  It’s mostly a PC thing.  Even with TPM, what you need is something like a digest of the code.  You can’t get that.

Brian

> On Oct 16, 2020, at 11:17 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> A user gets a device capable of passing the tests. He requests to enroll it with is provider as one of his devices. As part of that, a test is run between the device and the provider's enrollment server. Then the provider gives the device some sort of cert that can be used when registering.
> 
> Next, the user decides to try out some other rogue device on his account. Normally he would repeat the above, and the device would fail the test. Instead, he might cause the rogue device to steal the cert from the device that passed. I think he can't help but know he is doing something illicit.
> 
> I guess if these were both just apps, then a remote attack on the device could install a rogue app that impersonates the valid one and steals its credentials. Is that what you had in mind?
> 
> Perhaps we need to spend some time with the providers enumerating the attacks they are concerned with.
> 
> 	Thanks,
> 	Paul
> 
>> On Thu, Oct 15, 2020 at 8:19 PM Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Oct 2020 11:34:18 -0400

I think this discussion highlights the need to first nail down the 
threat model that the providers want to protect against.

James: can you take a crack at that? Possibly pull in some of the other 
providers if you think they will be willing.

(I wonder if providers currently have any sort of robust protection 
against malicious impersonation of their devices? I'm guessing it is 
only security by obscurity.)

	Thanks,
	Paul

---

From: Eugene Christensen <[email-masked]>
Date: Wed, 21 Oct 2020 13:32:10 +0000

Brian,

You mentioned the use of a magic number.  Is that the same as the use of an authorization key that is built into the product with the respective provider's key(s)?  If so I believe that could possibly work.  If I understand that correctly, the provider's would give a key to the developer that would be unique to that application and version.  When that application attempts to connect to a provider, the provider will know what company's app and version it is and be able to accept the connection once it has been verified in the lab.  If it goes rogue thereafter, as I understand it, the providers could revoke that access.

Regarding some concerns with an open API, here are three that should be captured:
- Brute force attacks - A bad actor could use an API to determine a user's password.
- Untested clients - A problem caused unintentionally by an endpoint developer with good intentions. 
- DDOS attacks - A bad actor could try to bring a system down by sending multiple requests from different IP addresses making it difficult to block.

Thanks,
Eugene.

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.

-----Original Message-----
From: Rum <[email-masked]> On Behalf Of Paul Kyzivat
Sent: Tuesday, October 20, 2020 9:34 AM
To: Brian Rosen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] [EXT] RUM security model

[EXTERNAL] 

I think this discussion highlights the need to first nail down the threat model that the providers want to protect against.

James: can you take a crack at that? Possibly pull in some of the other providers if you think they will be willing.

(I wonder if providers currently have any sort of robust protection against malicious impersonation of their devices? I'm guessing it is only security by obscurity.)

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 21 Oct 2020 10:40:10 -0400

If a magic number (often this is called an “API Key”) is good enough, I can write text for it.  The client code would have a version and the key sent to the server in Registration.  The server can verify the code was one it issued, for that version.  The code would be per-provider.

Brute force and DDoS attacks can’t be addressed by this document except in the Security Consideration section.  They are implementation issues.  

Brian

> On Oct 21, 2020, at 9:32 AM, Eugene Christensen <[email-masked]> wrote:
> 
> Brian,
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 22 Oct 2020 08:29:25 +0200

> On 21 Oct 2020, at 16:40, Brian Rosen <[email-masked]> wrote:
> 
Sending API keys or any other tokens in a header in SIP is not a good idea. Which is why we said MUST encrypt in the SIP/Oauth2 document.
Remember that there can be multiple proxys in the path and giving them the API key is not a good thing.

The API key can be used as a secret in a HTTP digest auth with a strong checksum (hint: Not MD5)

> Brute force and DDoS attacks can’t be addressed by this document except in the Security Consideration section.  They are implementation issues.  
If there are specific attack vectors to RUM that doesn’t apply to SIP implementations in general, yes.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Oct 2020 11:33:42 -0400

On 10/22/20 2:29 AM, Olle E. Johansson wrote:

[snip]

> If there are specific attack vectors to RUM that doesn’t apply to SIP implementations in general, yes.

AFAIK there should be nothing special about VRS that makes it any more 
vulnerable to attack than any other sip service accessed over the public 
internet.

I'd like to hear from the providers if I am wrong about this.

	Thanks,
	Paul

---

From: Eugene Christensen <[email-masked]>
Date: Fri, 30 Oct 2020 21:40:46 +0000

There has to be some amount of trust between the providers so I think we should consider the use of an API key for access to the provider's configuration service.  If an API key is given and another provider abuses that, it obviously could result in something bad but it could quickly be revoked by the provider; right?  And the company that has abused it will likely not be trusted in the future (motivation for maintaining trust).

Would it also be wise to use a client certificate for SIP communications once the RUE has the necessary info from the configuration service?  The client certificate could be embedded into the application.

Is there any reason we cannot use language that makes the use of the API key and client certificate optional, at the discretion of the provider?  (e.g. The providers MAY require an API key for their configuration service and/or a client certificate for SIP communications).

Thanks,

Eugene.

-----Original Message-----
From: Paul Kyzivat <[email-masked]> 
Sent: Thursday, October 22, 2020 9:34 AM
To: Olle E. Johansson <[email-masked]>; Brian Rosen <[email-masked]>
Cc: Eugene Christensen <[email-masked]>; [email-masked]
Subject: Re: [Rum] [EXT] RUM security model

[EXTERNAL] 

[snip]

> If there are specific attack vectors to RUM that doesn’t apply to SIP implementations in general, yes.

AFAIK there should be nothing special about VRS that makes it any more vulnerable to attack than any other sip service accessed over the public internet.

	Thanks,
	Paul