Re: [Rum] [EXT] RUM security model

["Asveren, Tolga" <[e-mail]>]

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 <[e-mail]> On Behalf Of Brian Rosen
Sent: Thursday, October 15, 2020 8:25 PM
To: Paul Kyzivat <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>> wrote:
On 10/15/20 7:52 PM, Brian Rosen 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.

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

> 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 <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> 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 [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>or by telephone at [phone], and destroy the original transmission and its attachments without reading them or saving them to disk.
>>> *From:* Brian Rosen <[e-mail]<mailto:[e-mail]>>
>>> *Sent:* Wednesday, September 30, 2020 5:47 PM
>>> *To:* Eugene Christensen <[e-mail]<mailto:[e-mail]>>
>>> *Cc:* [e-mail]<mailto:[e-mail]>
>>> *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 <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> 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 [e-mail]<mailto:[e-mail]>
>>>     <mailto:[e-mail]<mailto:[e-mail]>> 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
>>>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>     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
>> [e-mail]<mailto:[e-mail]>
>> 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.
-----------------------------------------------------------------------------------------------------------------------