Project

General

Profile

Actions

Task #1374

closed

nfd-status: enable verification of the data received from NFD

Added by Alex Afanasyev about 10 years ago. Updated almost 10 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Tools
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

nfd-status may need to verify data that is received from NFD

Actions #1

Updated by Chengyu Fan almost 10 years ago

  • Assignee set to Chengyu Fan
Actions #2

Updated by Alex Afanasyev almost 10 years ago

I'm not sure. Yes, I would be nice to have, but question is what is the base for this verification. How does nfd-status knows NFD's public key?

Actions #3

Updated by Chengyu Fan almost 10 years ago

Since the Interests sent by nfd-status just use prefix "/localhost", I assume that the nfd-status is running on the same machine.
So why not just parse the configuration file to get the NFD's public key?

Actions #4

Updated by Alex Afanasyev almost 10 years ago

nfd-status not necessarily knows where the config file is located. There are pre-defined locations, but anybody can change that. The only thing that nfd-status can know is how to connect to the running NFD (the socket address is either pre-configured or updated in ~/.ndn/client.conf).

Instead of verification, I would just print out NFD's public key certificate information.

Btw. This is for HTML output. CCNx had a nice trick of setting background color of HTML page partially based on the daemon's public key. This way, different colors would mean different instances of NFD. We could do a similar trick.

Actions #5

Updated by Junxiao Shi almost 10 years ago

  • NFD configuration file not necessarily readable by nfd-status, because NFD is started by root, and nfd-status may be called from a web server that runs under nobody.
  • NFD's public key is not in NFD configuration file.

A malicious app can send unsolicited Data under ndn:/localhost/nfd/status namespace, hoping one of them would satisfy a request from nfd-status.

However, we should assume localhost does not contain any malicious app.

Actions #6

Updated by Chengyu Fan almost 10 years ago

If the NFD can publish its public key using a local name, then all local apps can get it directly.
Data and Interest from apps must go through NFD, it has the ability to stop local malicious data injection, doesn't it?

Actions #7

Updated by Alex Afanasyev almost 10 years ago

NFD can (and probably should) publish, but this doesn't fix the problem. How would you verify that the publishing thing is correct. And if you can verify that, then we can verify nfd-status, but this is kind of a contradiction...

Actions #8

Updated by Beichuan Zhang almost 10 years ago

If there's a way to learn the socket address to connect to, why not use the same way to learn NFD's public key filename?

Actions #9

Updated by Alex Afanasyev almost 10 years ago

There isn't really NFD's public key file anywhere. What we have now is public key certificate that NRD is using to send commands (they happen to be the same right now, but it is not necessarily the case, unless we decide to make it the same). Even so, there is no standard filename for it, thus there is no default, and this file must be specified in the config file (right now it is really optional and you would need it only in exceptional cases).

Actions #10

Updated by Junxiao Shi almost 10 years ago

  • Status changed from New to Rejected

20140515 conference call decides that verification is unnecessary because /var/run/nfd.sock should be trusted. There is also no secure way to retrieve the public key of NFD.

Actions

Also available in: Atom PDF