[Nfd-dev] Close NFD backdoor

[Thompson, Jeff]

> currently. NDN-CCL provides the MemoryContentCache, per JeffT's e-mail, as a result of this pattern showing up repeatedly in our applications.

An indeed, the CCL implementation of ChronoSync2013 uses a MemoryContentCache and doesn't use the back door.
https://github.com/named-data/ndn-cpp/blob/7f95422eeb278f83c901d556e1a06df65c0510dd/include/ndn-cpp/sync/chrono-sync2013.hpp#L351


From: <Burke>, Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Date: Monday, September 8, 2014 9:04 AM
To: Yingdi Yu <yingdi at cs.ucla.edu<mailto:yingdi at cs.ucla.edu>>, nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>, NDN App <ndn-app at lists.cs.ucla.edu<mailto:ndn-app at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Close NFD backdoor

Hi Yingdi,
Some comments below.
Thanks,
Jeff

From: Yingdi Yu <yingdi at CS.UCLA.EDU<mailto:yingdi at CS.UCLA.EDU>>
Date: Sun, 7 Sep 2014 21:41:57 -0700
To: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>, "ndn-app at lists.cs.ucla.edu<mailto:ndn-app at lists.cs.ucla.edu>" <ndn-app at lists.cs.ucla.edu<mailto:ndn-app at lists.cs.ucla.edu>>
Subject: [Nfd-dev] Close NFD backdoor

Hi all,

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.


================
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?


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.

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?

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... ?


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?   Another possibility could be object-size based, # of request-based, etc.   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)


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.

At the nfd side, nfd will check:
a) whether the requested prefix matches the signing key name.
b) whether the key "/localhost/prefix-register-key/a/b/[keyId]" is signed by a trusted user.
c) whether the user is allowed to register the prefix.
The request will be accepted only if all the three conditions are satisfied.

If an app finds that the prefix-register-key it needs has already existed in the user's keystore (e.g., created by some other apps), it will ask the user for the access to the existing key. This access control feature is already supported by the osx-keychain based keystore.

================


Yingdi




_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140908/b33b6e79/attachment.html>