Re: NSD API security

I agree w/ Giuseppe. For instance, in my experience, I don't wanna
expose ContentDirectory.
There are lots  of issues for being exposed to the web.

2013/10/4 Giuseppe Pascale <giuseppep@opera.com>:
> This still doesn't address the concern that these services have not been
> designed to be exposed to the web.
>
> /g
>
>
> On Fri, Oct 4, 2013 at 9:11 AM, Klaus Kranz <klaus.kranz@access-company.com>
> wrote:
>>
>> 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
>>
>>
>>
>> HMA
>>
>> -          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
>>
>>
>>
>> Rgds
>>
>> Klaus
>>
>> From: Giuseppe Pascale [mailto:giuseppep@opera.com]
>> Sent: Freitag, 4. Oktober 2013 08:42
>> To: frederick.hirsch@nokia.com
>> Cc: Dominique Hazael-Massieux; FABLET Youenn; Bin Hu; Rich Tibbett;
>> public-device-apis@w3.org; 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, <Frederick.Hirsch@nokia.com> 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
>> Nokia
>>
>>
>>
>>
>> On Oct 3, 2013, at 2:50 AM, ext Dominique Hazael-Massieux wrote:
>>
>> > Le jeudi 03 octobre 2013 à 01:28 +0000, Frederick.Hirsch@nokia.com 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 09:07:54 UTC