RE: NSD API security

Dear all,

the main use-case might be media sharing and future home automation. So in
order to have a practical tradeoff enabling non CORS legacy devices, we may
think off allowing only specific services around those use-cases.

i.e. looking at UpnP we may just allow:

Media Sharing

-          ConnectionManager:x

-          ContentDirectory:x

-           AVTransport:x

-          RenderingControl:x


-          DataStore:1

-          SensorTransportGeneric:1

-          ConfigurationManagement:1

Or explicitly disabling services that we for sure don’t want to control
such as the router related ones:

-          Layer3Forwarding:1

-          LANHostConfigManagement:1

-          WANCableLinkConfig:1

-          WANCommoninterfaceConfig:1

-          WANDSLLinkConfig:1

-          WANEhernetLinkConfig:1

-          WANIPConnection:1

-          WANPOTSLinnkConfig:1

-          WANPPPConnection:1



*From:* Giuseppe Pascale []
*Sent:* Freitag, 4. Oktober 2013 08:42
*Cc:* Dominique Hazael-Massieux; FABLET Youenn; Bin Hu; Rich Tibbett;; public-web-and-tv
*Subject:* Re: NSD API security

If we go for explicit opt-in from services, it will be up to device vendors
to decide if their device is secure enough. I think one of the main concern
was that these devices have not been designed to be exposed to any random
web app out there.

On Thu, Oct 3, 2013 at 12:43 PM, <> wrote:

agreed, my point is that if the security flaw in the benign  service allows
an attack on the sensitive one then the only real solution is not to enable
that device in our scenario (or to fix the underlying issue of course)

I like the phrasing, should be good for the  security considerations
section :)

regards, Frederick

Frederick Hirsch

On Oct 3, 2013, at 2:50 AM, ext Dominique Hazael-Massieux wrote:

> Le jeudi 03 octobre 2013 à 01:28 +0000, a
> écrit :
>> The fundamental flaw is that one device has two purposes  allowing
>> flaws from one to affect the other, yet this is also why it is sold
>> and valued - the convenience, cost reduction, lower hardware
>> footprint, easier management etc are also benefits.
> One simple (but of course not 100% effective) solution would be for such
> a dual serviced device to expose CORS headers only on the benign
> service, and not on the security-sensitive one.
> (if a bug in the benign service lets attack the sensitive one, of
> course, this won't be of much use)
> Dom


The contents of this e-mail message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. 
This transmission is sent in trust, and the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. 
If you are not the intended recipient, please immediately notify the sender by reply e-mailer and delete this message and its attachments, if any.
Thank you for your cooperation.

Received on Friday, 4 October 2013 15:34:13 UTC