Re: [Rum] [EXT] RUM security model

[Brian Rosen <[e-mail]>]

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
>