Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-evaluation-methodology-04.txt

From: Börje Ohlman <[email-masked]>
Date: Fri, 8 Apr 2016 14:48:14 +0200

> On 29 mars 2016, at 12:34, Nikos Fotiou <[email-masked]> wrote:
> 
> 
Hi Nikos,

Thanks for your comments. Please see below.
> On 29 mars 2016, at 12:34, Nikos Fotiou <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi all,
> In ICN 2014 (Paris) there was a paper titled "Analyzing Cacheable Traffic in ISP Access Networks for Micro CDN Applications via Content-Centric Networking" (http://conferences2.sigcomm.org/acm-icn/2014/papers/p57.pdf <http://conferences2.sigcomm.org/acm-icn/2014/papers/p57.pdf>). I believe the content of the paper fits in section 2.2 ( disclaimer, I am not affiliated with this paper).
Please see separate mail exchange regarding this issue.
> 
> Moreover, in section 3.2 there is the following text:
> "An authorization
>  delegation scheme has been proposed [ACDICN] but this requires access
>  to a server controlled by the publisher to obtain an access token
>  making it essentially just an out-of-band key distribution system"
> 
> Being the main author of [ACDICN] I would say that this statement is not accurate. The access token is not delivered out of band, neither is used as an encryption key. Moreover, the access control provider (i.e., the "server" mentioned in the text) is not controlled by the publisher but it is trusted by the publisher; in terms of currently used architectures, a publisher can be any user, the access control provider can be facebook, and the access control mechanism would be an enhanced version of facebook connect. The goal of the scheme is to allow a semi-trusted entity (e.g., a cache, a CDN node) to evaluate if a subscriber is authorized to access a publication, without having access to the user management system of the publisher. Therefore, encryption of the publication is orthogonal to this scheme. 
> 
> If you want, a more accurate description of [ACDICN] is the following:
> An authorization delegation scheme has been proposed [ACDICN]. This scheme allows semi-trusted entities (such as caches, CDN nodes) to delegate access control decisions to 3rd party access control providers that are trusted by the content publisher. The former entities have no access to subscriber related information and should respect the decisions of the access control providers. 

I think this is a good suggestion. have included your proposed text.
> 
> Finally, in the same section there is the following text
> "One possible technique that could allow for providing access control
>  to heterogeneous groups and still allow for a single encrypted object
>  representation that remains cacheable is Attribute Based Encryption
>  (ABE). A first proposal for this is presented in [ABE]"
> 
> I believe this statement is not very accurate. With Attribute Based Encryption , all attributes (and the corresponding cryptographic keys) must be derived by the same entity. 
This statement I don’t believe is correct. There are proposals for how to do multi-authority ABE, see e.g.
R. Longo, C. Marcolla, M. Sala, Key-policy multi-authority attributebased
encryption, Algebraic Informatics, Springer, 2015, pp. 152–164.
I propose to add a sentence about this and the reference to support it.

> Therefore, the group of users cannot be heterogeneous, instead users should belong to the same administrative domain (e.g., users of the same social network). Moreover, although probably out of the scope of this draft, it should be kept in mind that Attribute Based Encryption suffers from key escrow problems
> and key revocation posses non-negligible overhead. 
I agree that is out of scope for this document.

Best regards,
			Börje
> Best,
> Nikos
> 
> 
> On 21 March 2016 at 15:14, Dirk Kutscher <[email-masked] <mailto:[email-masked]>> wrote:
> Let's do another RG last call for this.
> 
> Please let us know of any comments until Monday, March 28th, 23:59 PST.
> 
> Best regards,
> Dirk
> 
> 
> > -----Original Message-----
> > From: icnrg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of internet-
> > [email-masked] <mailto:[email-masked]>
> > Sent: Montag, 21. März 2016 13:05
> > To: [email-masked] <mailto:[email-masked]>
> > Cc: [email-masked] <mailto:[email-masked]>
> > Subject: [icnrg] I-D Action: draft-irtf-icnrg-evaluation-methodology-04.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Information-Centric Networking of the IETF.
> >
> >         Title           : Information-centric Networking: Evaluation and Security
> > Considerations
> >         Authors         : Kostas Pentikousis
> >                           Borje Ohlman
> >                           Elwyn Davies
> >                           Spiros Spirou
> >                           Gennaro Boggia
> >       Filename        : draft-irtf-icnrg-evaluation-methodology-04.txt
> >       Pages           : 34
> >       Date            : 2016-03-11
> >
> > Abstract:
> >    This document presents a number of considerations regarding
> >    evaluating Information-centric Networking (ICN) and sheds some light
> >    on the impact of ICN on network security. It also surveys the
> >    evaluation tools currently available to researchers in the ICN area
> >    and provides suggestions regarding methodology and metrics.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-irtf-icnrg-evaluation-methodology/ <https://datatracker.ietf.org/doc/draft-irtf-icnrg-evaluation-methodology/>
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-04 <https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-04>
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-evaluation-methodology-04 <https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-evaluation-methodology-04>
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> >
> > _______________________________________________
> > icnrg mailing list
> > [email-masked] <mailto:[email-masked]>
> > https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>
> 
> _______________________________________________
> icnrg mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Nikos Fotiou <[email-masked]>
Date: Fri, 8 Apr 2016 17:10:17 +0300

Hi Borje,

I agree to add a reference about multi-authority ABE. I would suggest to
add this reference instead  Lewko, A., Waters, B.: Decentralizing
attribute-based encryption. In: Proc. of EUROCRYPT 11, LNCS, vol. 6632, pp.
568–588 (2011)

Best,
Nikos

On 8 April 2016 at 15:48, Börje Ohlman <[email-masked]> wrote:

> In ICN 2014 (Paris) there was a paper titled "Analyzing Cacheable Traffic
> in ISP Access Networks for Micro CDN Applications via Content-Centric
> Networking" (http://conferences2.sigcomm.org/acm-icn/2014/papers/p57.pdf).
> I believe the content of the paper fits in section 2.2 ( disclaimer, I am
> not affiliated with this paper).
>
> Being the main author of [ACDICN] I would say that this statement is not
> accurate. The access token is not delivered out of band, neither is used as
> an encryption key. Moreover, the access control provider (i.e., the
> "server" mentioned in the text) is not controlled by the publisher but it
> is trusted by the publisher; in terms of currently used architectures, a
> publisher can be any user, the access control provider can be facebook, and
> the access control mechanism would be an enhanced version of facebook
> connect. The goal of the scheme is to allow a semi-trusted entity (e.g., a
> cache, a CDN node) to evaluate if a subscriber is authorized to access a
> publication, without having access to the user management system of the
> publisher. Therefore, encryption of the publication is orthogonal to this
> scheme.
>
> An authorization delegation scheme has been proposed [ACDICN]. This scheme
> allows semi-trusted entities (such as caches, CDN nodes) to delegate access
> control decisions to 3rd party access control providers that are trusted by
> the content publisher. The former entities have no access to subscriber
> related information and should respect the decisions of the access control
> providers.
>
>
> I believe this statement is not very accurate. With Attribute Based
> Encryption , all attributes (and the corresponding cryptographic keys) must
> be derived by the same entity.
>
> Therefore, the group of users cannot be heterogeneous, instead users
> should belong to the same administrative domain (e.g., users of the same
> social network). Moreover, although probably out of the scope of this
> draft, it should be kept in mind that Attribute Based Encryption suffers
> from key escrow problems
>
> On 21 March 2016 at 15:14, Dirk Kutscher <[email-masked]> wrote:
>
>> > From: icnrg [mailto:[email-masked]] On Behalf Of internet-
>> > [email-masked]
>> > To: [email-masked]
>> > Cc: [email-masked]
>> > Subject: [icnrg] I-D Action:
>> draft-irtf-icnrg-evaluation-methodology-04.txt
>> >
>> >
>> https://datatracker.ietf.org/doc/draft-irtf-icnrg-evaluation-methodology/
>> >
>> > https://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-04
>> >
>> https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-evaluation-methodology-04
>> >
>> >
>> > until the htmlized version and diff are available at tools.ietf.org.
>> >
>> > ftp://ftp.ietf.org/internet-drafts/
>> >