Nikos.Fotiou

Oct 172012
 

ICN is (among other things) about scattering information objects in many (network) locations: the same object can exist simultaneously in a web server, in a CDN server, in a cache, or even in the RAM of an ADSL gateway. While this feature is expected to facilitate content distribution, it raises a significant security concern: how can access control on data, stored outside the data-owner administrative boundaries, be imposed?

A straightforward approach for answering this question is to examine the current situation. A common solution to this problem is to not pose any access control on the data stored  by 3rd parties! Surprisingly,  this solution is widely adopted! Take for example facebook, that stores users’ pictures in Akamai’s CDN. If you have a facebook account perform this very simple experiment: upload a picture to your facebook profile, secure this picture by applying a strict access control policy (e.g., “only my friends can view the picture”), view the picture  and copy its URL (it should be something like that http://fbcdn-sphotos-g-a.akamaihd.net/  which is a URL pointing to an Akamai server),  and give this URL to somebody that does not even have a facebook account. You will be surprised to see that your picture can be accessed, bypassing the Facebook access control policy. Actually anybody can see this picture, provided that she has the pointer to it (the Akamai URL). Why does this happen is obvious: Akamai knows nothing about facebook policies.

An improvement to this approach is to allow 3rd parties to access the data-owner’s user directory and retrieve only the information that is required in order to evaluate an access control policy.  A common approach for achieving that is by using OAuth.  OAuth is a protocol that enables 3rd parties to request access to specific user attributes. OAuth has been widely adopted (e.g., by Google, Facebook, and many others). Moreover OAuth v2.0is aiming to become an IETF standard. Nevertheless OAuth comes with some drawbacks: (i) a 3rd party learns something about the user (the user attributes required in order to evaluate a policy), (ii)  a 3rd party has to be able to understand the meaning of the various user attributes (e.g., in the case of facebook it has to understand what a ‘friend’ means), and (iii) it can not be easily implemented resulting in broken (and broken) implementations.

With all these in mind, we created a solution that tries to overcome these problems and we adapted it to our ICN architecture. Our solution was presented during the second SIGCOMM workshop on Information Centric Networking (and received the best paper award).  In a nutshell our system works as follows: a data owner creates an access control policy and stores it in an Access Control Provider, it attaches a pointer to that policy (e.g., a URL) to every item the policy protects, any 3rd party can request users to authenticate themselves against a policy,  the authentication takes place at the location indicated by the pointer (i.e., at the Access Control Provider that holds the actual definition of the policy),  and upon a successful authentication 3rd parties are notified by the Access Control Provider.

This approach has many advantages compared to OAuth. First, 3rd parties remain oblivious about data-owner personal information. Second, 3rd parties do not have to understand user attributes in order to evaluate an access control policy; this task is performed by the Access Control Provider. Last, but not least, the access control policy is stored and managed in a separate (functionally centralized) module -the Access Control Provider- therefore it can be easily modified and re-used.

We believe that our solution can be easily adapted for other ICN architectures, as well as for similar systems (e.g., cloud storage, CDN services)