Re: [Rum] [EXT] RUM security model

[Brian Rosen <[e-mail]>]

Usually, an API key is used for all transactions.  In our case, there would be the file download that has credentials (the 2nd file), and there is the SIP REGISTER and INVITE transactions.  Either or both could be annotated with the API Key.

File 1 is a public file and there is only one per country (not per user).

The reason file 2 had credentials in it was to avoid having users that maintained accounts at multiple providers have to remember password per provider.  The idea is that the file is protected, using some way to have users authenticate to get access to it, and then that had the per-provider authentication information in it.  As currently described, there is one file and it has multiple provider credentials in it.

There is discussion now of file (2) per provider, which is okay, but would need some common authentication and not the per-provider credentials to get at.

I remind you that essentially all VoIP phones store provider credentials locally, with zero local authentication.  The notion is that you need physical access to get to those credentials.  The soft phone guys copy that idea, with varying degrees of security on the file that holds the VoIP provider credentials.  Users don’t type credentials per use and most current VoIP phones maintain multiple “lines” with per “line” credentials, i.e. exactly what I’m trying to maintain here.


> On Nov 9, 2020, at 3:22 PM, Eugene Christensen <[e-mail]> wrote:
> 
> Brian,
> 
> I think we are working towards a solution that I agree with.  Just to make sure we are clear, let me state a couple of things.
> 
> In section 9 of the draft document, it identifies two files.  The first (I’ll call file1) is a file that “provides a directory of providers” and the second (I’ll call file2) “provides configuration data for the device”.  The document also says “The VRS user interacts with the RUE to select from the Provider list one or more Providers with whom the user has already established an account”.
> 
> With the above understanding, I believe access to the second file requires two levels of security with the host of file2 (presumably the Provider with whom the user wishes to register and use the RUE).  The first level of security is the API key that I believe we have been talking about.  The second level of security must include user authentication based on the established account with the Provider.
> 
> I would prefer to see the API key done over HTTPS, not SIP. 
> 
> It may be desirable to have an API key to access file1 as well but whatever entity is hosting file1 should weigh in on this.
> 
> When the RUE has obtained file2 and is then ready to register with said Provider, I believe we should still have mutual authentication as part of the session establishment.  The certificate and API keys could be embedded into the RUE application.  The certificate could also potentially be received as part of the exchange for file2.
> 
> In both cases, I believe we should make the use of API key and the mutual authentication optional at the Provider’s discretion.
> 
> Thank you.
> 
> 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] or by telephone at [phone], and destroy the original transmission and its attachments without reading them or saving them to disk.
> 
> -----Original Message-----
> From: Brian Rosen <[e-mail]> 
> Sent: Tuesday, November 3, 2020 1:34 PM
> To: Paul Kyzivat <[e-mail]>
> Cc: Eugene Christensen <[e-mail]>; Olle E. Johansson <[e-mail]>; [e-mail]
> Subject: Re: [Rum] [EXT] RUM security model
> 
> [EXTERNAL] 
> 
> Classic API Keys don’t depend on user sign in: it’s built into the code.  In terms of our spec, all we would need is the mechanism to send the code, and we wouldn’t deal with how the code developer got the key.  Classically, it’s sent in some initial transaction after TLS is established, so the key can’t be observed.
> 
> If API Key’s are a satisfactory (to providers) way of controlling what implementations are allowed access, we can discuss mechanism and I’ll write text.
> 
> I think the fundamental question is do we want a SIP mechanism (which means TCP/TLS signaling) or an HTTP mechanism?  We could tie it to the retrieval of the config file if that is per-provider, which would be an HTTP mechanism, or we could include it in, say, a Call-Info header on a SIP REGISTER if that was TLS protected.
> 
> Brian
> 
> 
>> On Nov 3, 2020, at 3:25 PM, Paul Kyzivat <[e-mail]> wrote:
>> 
>> Eugene,
>> 
>> On 10/30/20 5:40 PM, Eugene Christensen wrote:
>>> 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).
>> 
>> It depends on how key management works. Does each device/app need to test with each provider and receive a separate key from each provider?
>> Or does the testing happen with some testing organization who then provides a key that all providers accept?
>> 
>> The logistics of testing and revocation differ in these cases.
>> 
>>> 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.
>> 
>> From a practical perspective I think we need to authenticate using a password at some point. (Just due to logistics of bootstrapping and identifying the human user. Perhaps only for the config service.) Or perhaps could use OAuth to authenticate using Facebook/Google/...
>> 
>> From there it might make sense to provide certs for subsequent use.
>> 
>>> 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).
>> 
>> Possibly. The devil is in the details here.
>> 
>> 	Thanks,
>> 	Paul
>> 
>>> 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: Paul Kyzivat <[e-mail]>
>>> Sent: Thursday, October 22, 2020 9:34 AM
>>> To: Olle E. Johansson <[e-mail]>; Brian Rosen 
>>> <[e-mail]>
>>> Cc: Eugene Christensen <[e-mail]>; [e-mail]
>>> Subject: Re: [Rum] [EXT] RUM security model [EXTERNAL] On 10/22/20 
>>> 2:29 AM, Olle E. Johansson wrote:
>>> [snip]
>>>>> 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.
>>> 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
>> 
>