Re: [Rum] [EXT] RUM security model

["Olle E. Johansson" <[e-mail]>]

> On 21 Oct 2020, at 16:40, Brian Rosen <[e-mail]> wrote:
> 
> 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.
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
> 
> Brian
> 
> 
>> On Oct 21, 2020, at 9:32 AM, Eugene Christensen <[e-mail]> wrote:
>> 
>> 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 [e-mail] or by telephone at [phone], and destroy the original transmission and its attachments without reading them or saving them to disk.
>> 
>> -----Original Message-----
>> From: Rum <[e-mail]> On Behalf Of Paul Kyzivat
>> Sent: Tuesday, October 20, 2020 9:34 AM
>> To: Brian Rosen <[e-mail]>
>> Cc: [e-mail]
>> 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
>> 
>> On 10/20/20 10:10 AM, Brian Rosen wrote:
>>> 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 <[e-mail]> wrote:
>>>> 
>>>> On 10/15/20 8:24 PM, Brian Rosen wrote:
>>>>> Nope, it just takes a hacker to create a piece of code that patches an 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
>>>> 
>>>>> 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 +1 (801)
>>>>>   287-9419, 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>
>>>> 
>>> 
>> 
>> --
>> Rum mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rum
> 
> -- 
> Rum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rum