[Nfd-dev] Question about localhop security policy of NDN testbed nodes

[Junxiao Shi]

Hi Haitao


> Previously, I used this tool remote-register-prefix
> <https://github.com/yoursunny/ndn6-tools/blob/master/remote-register-prefix.md> (on
> Linux machine) and use interest "/localhop/nfd/rib/register/<control
> parameter>" (on Android) to register back route on NDN testbed edge router,
> the signing identity/key/certificate (/org/openmhealth/<user-id>) was
> issued by NDNFit trust anchor (/org/openmhealth); however, it doesn't work
> any more.
>
I'm unaware of testbed configuration change affecting this in past 3 months.
It shouldn't have worked previously.

I believe it's because the localhop security policy was changed (i.e.,
> localhop_security field of nfd.conf was changed), so only interests signed
> by identity/key/certificate that can be tracked back to NDN testbed trust
> anchor could register back route on NDN testbed successfully. It this true,
> or is there another reason?
>
Yes, the signing certificate must be issued from the testbed root.


> If my suspicion is true, could you help to manually issue a cert to NDNFit
> trust anchor using NDN testbed trust anchor (or could you grant me the
> privilege to do so), so that my remote register interest can be verified?
>
No, because the configuration enforces hierarchical certificate names. You
can sign /org/openmhealth/haitao with /ndn/edu/ucla/cs/haitao, but it
wouldn't be trusted. See https://yoursunny.com/t/2016/ndncert/ "can I
impersonate as Google with my intermediate CA" section.

I want to manually do this because NDNFit trust anchor was not bound with
> an email. Another option is to replace NDNFit trust anchor with an
> identity/key/certificate that is bound with an email (we can create a new
> email account). I prefer the former choice as we want to keep the identity
> name "/org/openmhealth".
>
You don't have to change anything in your application's trust model or
trust anchor. You just need a second certificate on each end host that is
issued from testbed root.
You will be able to register and readvertise /org/openmhealth/haitao with a
testbed-issued certificate for now (until
https://redmine.named-data.net/issues/2856 is implemented; I abuse this a
lot in my apps so obviously I would not push for 2856 despite it's approved
long ago, but I couldn't reject a patch if someone implements it).
Eventually, you could only register the prefix same as testbed identity,
and you'll have to reach /org/openmhealth/haitao using a forwarding hint.

Also, you should not issue certificates to other users from your
email-verified certificate as intermediate CA. I asked testbed operations
about this in 2013 and I'm told that I would get into trouble if my end
user abuses the testbed.
In other words, if each end host needs a testbed certificate, they should
separately request from ndncert system rather than issued from your
intermediate CA. You can automate the email part, but it would still be a
big headache because the issurance delay of up to 24 hours.
The new ndncert system for certificate v2 seems to only support email at
launch. I wish they can have Twitter or OpenID authentication, and
immediate issurance.

Yet another solution is to use the same trick as HomeCam
https://yoursunny.com/t/2017/homecam-NDN-prefix/ .
You can deploy a server that holds a testbed certificate, and end hosts
only have openmhealth certificate. Whenever an end host wants to register
/org/openmhealth/haitao, it sends an Interest which is forwarded to your
server. Your server should then sign a registration command using its
testbed certificate, encrypt it using end host's openmhealth public key,
and return it in the Data payload. The end host can decrypt the payload to
get the registration command Interest, and send out the Interest.
This avoids the complexity of adding a second certificate on each end host,
but you'll need the server.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170731/a48edd01/attachment.html>