Re: Security Considerations - Push/Pull Migration

On Tue, 07 Jun 2011 19:43:26 +0200, Mays, David <>  

> On today's call we discussed that there are some security issues around
> both the push and pull Application Migration use cases.
> For reference:
> ation
> Migration
> I'm having trouble figuring out how to incorporate these concerns into  
> the
> top-level security document here:
Hi Dave,
thanks for raising the issue. Let me briefly explain the idea behind this  
security document [1]:

since most of the usecases have common security issues,
my idea was to collect all of them in one place, to have a better overview.
The document also mention different approaches to solve the  
security/privacy problems.

The document is just a draft, my idea was to use it as a starting point  
for discussion.
So feel free to propose any extension to it. Note also that the document  
try to collect different ideas and not to propose one approach,
so any contribution is welcome.

That said, if there are particular security concerns specific for one use  
case, is ok to mention them in the use case description.
Otherwise, all the generic security and privacy requirements will be  
listed in the requirement document in a separate section (still empty now)  

> In one sense it's a security issue, given that pushing a malicious,
> inappropriate or undesired application could expose the system to a
> variety of attacks. It also could serve as a denial-of-service vector,
> assuming that such requests could flood a system and cause it to become
> unusable or unreachable.
I've seen you have added this in the current document,

I agree with your addition.

> In another sense it's a User Experience (UX) issue that is somewhat
> separable from being a security concern.
> I think the basic principle here is that these actions are by their  
> nature
> interruptive and therefore should require confirmation at the affected  
> end
> of the transaction. E.g. When a user requests to push an application to a
> target device, the target should provide confirmation UI. Conversely,  
> when
> a user requests to pull an application from another device, the source
> device should provide confirmation UI.
This point can be probably covered by the use cases itself, even though  
given that most of the UX will be controlled by the UA, I doubt you can  
mandate much in this area.

On a similar topic, is still not clear to me what is the "appropriate"  
level of information and control that should be exposed to the application,
and this is both for security and UX reasons.

Let's take a UPnP example:
is it appropriate to give to an application direct access (e.g. via an  
API) to all UPnP functionalities?
Or should some operations still be handled by the UA, giving to the  
application only access to a minimal subset of info and operations? If so,  
where would one draw the line?

I've drafted some ideas at the end of my proposal

feel free to comment further if you have any opinion on this.

> Perhaps both of these activities (push/pull application migration) should
> be at least gated by the presence of a pairing relationship as described
> here:
> #Device_Pairing
I think most of the scenarios we foresee should include some pairing/login  
Without that, I have hard time believing we can guarantee a minimal level  
of security.


> Dave

Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Wednesday, 15 June 2011 10:13:05 UTC