[Nfd-dev] Close NFD backdoor

[Yingdi Yu]

Hi Jeff,

On Sep 8, 2014, at 9:04 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

>> Beichuan and I had a discussion about a backdoor of nfd which allows apps to dump unsolicited data packets into content store of local nfd and how to close the backdoor. Here is a summary of the discussion, we would like to hear your comments. If people agree with it, we will start the implementation soon.
> 
> 
> While it makes sense to address this in the implementation soon, I would really encourage that this be considered as part of an evolving but comprehensive design and description about "how NDN applications interact with the (local) forwarder" and "how end-users interact with NDN security."   A little more on this below.

Yes. I think through this process, we can nail down a standard mechanism for NDN apps to talk to local fowarder.

>> ================
>> 1. NFD backdoor
>> Current NFD implementation allows local applications to dump unsolicited data packets into content store. This backdoor enables malware to cache poison local content store. To close the backdoor, nfd should 1) reject unsolicited data packets and 2) authenticate prefix registration on local nfd.
> 
> 
> Solicitation = having an Interest in the PIT, right?  

Not only having an interest in the PIT, but also that the incoming data packet must be received from one of the faces to which the corresponding interest has been forwarded.

>> 2. In-app storage
>> Some existing applications (such as ChronoChat) are using the backdoor to abuse local content store as an in-memory storage of data packets, because current library does not provide in-app storage.
> 
> 
> This is only the case in ndn-cxx, currently. NDN-CCL provides the MemoryContentCache, per JeffT's e-mail, as a result of this pattern showing up repeatedly in our applications. 

It is good to hear that NDN-CCL has already supported this feature. ndn-cxx needs to catch up! :)  But what we want to do in ndn-cxx is a little bit more than MemoryContentCache. MemoryContentCache relies on the FreshnessPeriod, but in some use cases, apps may want to retain a data packet longer than that. I am making a wiki page for this in-memory storage, trying to collect a set of use cases of that. I will send the link to the wiki page later.

>> The differences between content store and in-app storage include: 
>> a) content store is a cache, it is not guaranteed that a data packet will always be there. In contrast, the existence of a data packet in an in-app storage is completely under the app's control.
> 
> 
> Ilya has previously proposed the notion of an API that would enable applications to request local storage from the content store.  This still seems like an interesting notion to consider long-term.  As AlexA has pointed out, in-application stores are likely redundant uses of memory, to some extent.  Is there a reason that we are not considering a content store API and providing it in the library instead?  

The differences is that the content store does not provide guaranteed storage. And content store really has no clue about whether the data is valid or obsoleted. So if the local forwarder gets a interest with MustBeFresh=true while the data in content store is marked as stale, the local forwarder will forward the interest to the app. But a stale data packet does not necessarily mean that the data packet is obsoleted from the perspective of the producer. Without having a copy of the data packet in the app, the app will have to generate the data packet (and sign it) again. I think such on-demand data generation is unnecessary.

>> b) content store is aware of FreshnessPeriod of data packets, but an in-app storage should not. 
> 
> 
> Not sure what this means.  FreshnessPeriod can have application-defined semantics, depending on how the app uses MustBeFresh... ? 

I think FreshnessPeriod is meaningful to intermediate routers and end-consumers. For data producer, FreshnessPeriod is only a suggestion that the producer gives to routers and consumers. 

>> The working flow of in-app storage is: an app creates its own in-app storage. If the app generates some unsolicited data packets and insert them in the in-app storage.
>> When receiving an interest, the app will first try to see if there is a matched data packet in the in-app storage and then process the interest if there is no matched data. With the in-app storage, apps do not need to abuse content store, and we can eliminate the source of unsolicited data in the localhost environment.
>> 
>> For now, we need to provide two types of in-app storage:
>> a) explicit-controlled storage: data packets need to be explicitly deleted; when storage is full, all data insertions must fail until app explicitly increases the capacity of the storage.
>> b) FIFO: capacity is fixed, the first inserted data will be automatically deleted when the storage is full.
>> The implementation of the in-app storage could be more flexible to support other strategies, but the two above seems to be sufficient for now.
> 
> 
> I generally agree but what use cases were considered to come up with these two approaches?  

I will send a link to a wiki page which describe the use cases of it.

> Another possibility could be object-size based, # of request-based, etc.  

Just curious, is there any use case for these policy?

> I also assume these would be configure per-namespace rather than per-application?  (e.g., an application might handle /foo/archive differently than /foo/latest)

I am a little bit confused here. This in-memory storage is not an independent service or program, it is a part of the application. And an app does not have to keep only one in-memory storage.

>> 3. Authentication of prefix registration on local nfd
>> Currently all apps are using the system-default key to sign prefix registration command. There are several drawbacks of this mechanism:
>> a) every app get the access to the system-default private key.
>> b) the system-default key is trusted to register any prefix.
>> 
>> A better model should be: users should have per-prefix registration keys (the privilege of the key is expressed in the key name), and authorize applications to get the access of key for particular prefixes.
>> This resembles the network control model of current os, e.g., when a user starts a new app which will listen to some ports, the os will ask user to give the permission to the app.
> 
> 
> This is where I think we should consider this within a more comprehensive model about how end-users interact with NDN security.  (e.g., what are all the things that an application has to configure/ask/do when first installed?  how much real transparency can be given to its use? and so on)
> 
> The current way that most applications and operating systems interact with users about security and privacy should not necessarily be our model.     :)  Perhaps this is a topic for some background research - I haven't looked at the literature for a bit, but consider papers like:
> 
>> Dourish, Paul, et al. "Security in the wild: user strategies for managing security as an everyday, practical problem." Personal and Ubiquitous Computing 8.6 (2004): 391-401.  [Dourish is at UCI]
>> 
>> Smetters, Diana K., and Rebecca E. Grinter. "Moving from the design of usable security technologies to the design of useful secure applications." Proceedings of the 2002 workshop on New security paradigms. ACM, 2002.  [Diana worked with Van on CCNx] 
> 
> 
> I'm on a slow connection so can't do a search, but would guess there are also some papers on interaction design / user experience for OS security settings.  (Once we get a student aboard on Katie's next ViD grant, perhaps they could contribute to this design effort.)
> 
>> 
>> More specifically, when an app wants to register a prefix "/a/b", it will first look for a key "/localhost/prefix-register-key/a/b/[keyId]" in the user's keystore. If there is no such key, the app will create one and ask for user's permission.
>> User authorizes that by signing the prefix-register-key using user's own key (whose privilege is pre-configured at nfd side). After that the app will use key "/localhost/prefix-register-key/a/b/[keyId]" to sign request for prefix "/a/b".
> 
> 
> From the system level, I understand this... but again, would encourage a design that incorporates this specific authorization into a more comprehensive picture about how installing a new NDN app would look to the end-user, and the level of knowledge expected from them to answer the questions presented.  
> 
> One way to do this would be to storyboard an end-user's entire interaction with NDN security infrastructure, starting from a freshly installed OS and a new identity and publishing prefix assignment from a service provider, and ending with application installation questions such as this. 

yes, the purpose is to make prefix registration as simple and straightforward as possible. This specific authorization mechanism is at least not worse than the current OS security model, but we definitely need to think about more appropriate solution.

Yingdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140908/ed2e7d90/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140908/ed2e7d90/attachment.bin>