Re: NSD API security

On Fri, Sep 20, 2013 at 9:28 AM, Rich Tibbett <richt@opera.com> wrote:
> On Fri, Sep 20, 2013 at 1:18 AM, Giuseppe Pascale <giuseppep@opera.com> wrote:
>> On Thu, Sep 19, 2013 at 11:00 AM, FABLET Youenn
>> <Youenn.Fablet@crf.canon.fr> wrote:

> 1. Focus the specification around a CORS-only solution. CORS is an
> accepted mechanism to allow cross-origin communication on the web and
> could work well in the local network environment also. The problem
> with adopting a CORS-only approach is we have zero devices currently
> ready to step in to this brave new world with us. A specification that
> allows you to connect with precisely zero network services will not be
> useful.
>

We can always structure the spec so that:
- the core spec is designed to only cover opt-in and CORS enabled devices
- and addendum/annex explaining how someone using this solution in an
environment with a stricter trust model (then the web one) could relax
some of the constraints

I know this means 0 services support from day one, but may be easy for
implementer to allow something like this to start with, and without
browser support this spec is not going to be useful anyway.

In short, we should focus our first iteration of the spec in allowing
communication between apps and services that have been designed with
this use. In order to do that we need to discuss what extensions would
be needed to the discovery protocols (and services) to enable this


> 2. Support whitelisting of specific local network services in the user
> agent, at the user's request to enable communication with those
> services. Even if we went with a CORS-only approach (see (1.) above),
> this could be a practical fallback to support existing/legacy network
> services. This would provide non-CORS-enabled services with the same
> privileges as CORS-enabled services from the user agent without the
> service itself needing to support CORS implicitly (as also proposed in
> the current NSD API specification).
>

the problem is how this whitelist is built. If you imagine that the
user is "just" asked "do you want to whitelist x" then is probably not
too safe. If you imagine a browse menu where people can manually
whitelist services, that maybe a little bit safer, although a page
could still try to convince users to go there and enable these
services.


> 3. We could support blacklisting of local network services in the user
> agent ([7]). The current specification currently 'keys' local network
> service API access on its respective network service type identifier
> (e.g. 'zeroconf:_boxee-jsonrpc._tcp',
> 'upnp:urn:schemas-upnp-org:service:ContentDirectory:1', etc). We could
> deliberately disable certain service identifiers from being exposed to
> web pages.

We should probably start by blacklisting all those services/devices
that are present high risk of being attached, like routers.
There is an issue though: some network devices host multiple services.
Routers for example can also be used as mediaservers.
Anyway, if we go for the opt-in model, we will only expose
devices/services that voluntarily ask to be exposed.

>So if the user agent discovers a service whose type
> identifier lives in the network services blacklist, it would never be
> offered to a web page, even if that web page was attempting to access
> that specific service by its given id.
>
> I would prefer a solution that incorporates both (1.)+(2.) above -
> where we support CORS as the primary mode for communicating with
> local-networked services but still provide a fallback mechanism that
> allows users to override that requirement in the user agent - to
> interact with non-CORS enabled network services.
>

Agree but this fallback is probably going to be carefully designed and
some services should be blacklisted no matter what the user says.

> Option (3.) has the least impact on the current specification and does
> not require any changes to the respective discovery mechanisms of
> UPnP, Zeroconf or DIAL (to indicate CORS support). If we are unable or
> unwilling to go with a (1.)+(2.) approach then (3.) seems like a
> viable shorter-term alternative. We could start creating an initial
> blacklist of _bad_ local network services today and incorporate that
> list in to the NSD API spec very quickly.
>

We could start by documenteing these risks in the security section of the spec.


> Other proposals would of course be welcome that address the concerns
> raised in the original threads ([1] [2] [3]).
>
>>>
>>> The discovery part of the NSD API specification seems already in a pretty
>>> good shape.
>>>
>>> The access granting part of the NSD API specification may take more time to
>>> mature.
>>>
>>> Given all of that, would it make sense to split the NSD API specification in
>>> two documents?
>>>
>>
>> What I personally think it could make sense is to try and define a
>> "secure" version of the full spec, that "loose" the requirement for
>> supporting legacy devices and instead assume that discovery protocols
>> and services need to be (slightly) changed to opt-in for this feature.
>> >From there it should be easy to imagine an extension that people can
>> use in other scenarios where they want to support also legacy
>> protocols and they are able to secure the user home network via some
>> other means).
>
> I think option (1.) + (2.) above could achieve this. If we went with a
> CORS-only approach we would possibly also be able to drop the
> requirement for user opt-in interfaces on a request-by-request basis
> (since it would be the local network services themselves that opt-in
> to the communication in the first place _potentially_ negating the
> need for users to opt-in also).
>
> So, a more secure spec with less user opt-in UI requirements? Yes, please.
>

not sure this is true. From a security perspective, CORS could help.
Opt-in though would address the privacy concern. If a device/service
doesn't want to be exposed to the outside world, it must be able to
express this desire. Even if CORS may prevent a web page from taking
with a given device, you have already given out some information e.g.
that such device is there.

We have designed the spec in such a way that the information that we
expose after the discovery phase are limited, but still those
information could be valuable for "evil" pages.

>>
>> BTW assuming we still want to have an api that works across multiple
>> discovery protocols, this group would have to liaise with the groups
>> in charge of standardizing such discovery protocols in order to agree
>> on a way for services to opt-in for this API.
>
> For HTTP-based discovery mechanisms, it may be sufficient to provide
> 'Access-Control-Allow-Origin: *' HTTP headers in the network discovery
> messages - those can be interpreted by the user agent to mean that
> this device/service supports CORS. For DNS-based discovery mechanisms
> we would need to figure out another way to do this.
>

Would this be enough also to epxress the opt-in? in other words, can
it be that I want to support cors, but I don't want to be exposed to a
web app?

> Regardless of the actual solution it would be good if we could get
> some discussion going in the respective groups around this
> requirement.
>

Agree, let's first update the spec though, so that it's easier to
explain what we are after.

Received on Friday, 20 September 2013 11:46:58 UTC