Project

General

Profile

Feature #5114

Accommodate certificate name in KeyLocator in /localhop/nfd/rib validation rules

Added by Junxiao Shi over 1 year ago. Updated 7 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
RIB
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
1.50 h

Description

Currently, command validation rules for /localhop/nfd/rib command are written as:

rule
{
    for interest
    filter
    {
        type name
        regex ^[<localhop><localhost>]<nfd><rib>[<register><unregister>]<><><>$
    }
    checker
    {
        type customized
        sig-type rsa-sha256
        key-locator
        {
            type name
            regex ^<>*<KEY><>$
        }
    }
}

This means, the validator can only accept a signed Interest if its KeyLocator contains key name, but would reject a signed Interest if its KeyLocator contains certificate name.

Since #5112, KeyLocator would contain certificate name. Additionally, legacy client may continue to send KeyLocator with key name.
Thus, this rule should be relaxed to accept either key name or certificate name as KeyLocator.


Files

NFD-5114_20210129.pcapng (8.96 KB) NFD-5114_20210129.pcapng Junxiao Shi, 01/28/2021 09:51 PM

Related issues

Related to ndn-cxx - Feature #5112: Include certificate name in KeyLocatorNew

Actions
#1

Updated by Junxiao Shi over 1 year ago

  • Related to Feature #5112: Include certificate name in KeyLocator added
#2

Updated by Davide Pesavento over 1 year ago

I'm not sure what we need to do here. Isn't this purely a configuration thing?

#3

Updated by Junxiao Shi over 1 year ago

I'm not sure what we need to do here. Isn't this purely a configuration thing?

Yes, this is a configuration change only.

  1. Change nfd.conf.sample.in in NFD codebase and PPA package.
  2. Deploy to testbed https://github.com/WU-ARL/NDN_Ansible/issues/35
  3. After that, an end host with #5112 can register prefix on testbed without being affected by this configuration.
#4

Updated by John DeHart 8 months ago

Junxiao Shi wrote in #note-3:

I'm not sure what we need to do here. Isn't this purely a configuration thing?

Yes, this is a configuration change only.

  1. Change nfd.conf.sample.in in NFD codebase and PPA package.
  2. Deploy to testbed https://github.com/WU-ARL/NDN_Ansible/issues/35
  3. After that, an end host with #5112 can register prefix on testbed without being affected by this configuration.

Can we do the update for Issue 35 on the testbed before this issue 5114 is resolved? If so, what exactly is the change to the rib validation rule that needs to be applied in nfd.conf?

#5

Updated by Junxiao Shi 8 months ago

John DeHart wrote in #note-4:

Can we do the update for Issue 35 on the testbed before this issue 5114 is resolved? If so, what exactly is the change to the rib validation rule that needs to be applied in nfd.conf?

Yes and no. note-3 step 1 is to answer "what exactly is the change to the rib validation rule". Thus, this part of this issue must be complete before https://github.com/WU-ARL/NDN_Ansible/issues/35 can happen.

#6

Updated by Junxiao Shi 8 months ago

I made some progress on this.

infoedit -f /etc/ndn/nfd.conf -d rib.auto_prefix_propagate
infoedit -f /etc/ndn/nfd.conf -d rib.localhop_security
curl -sfL https://named-data.net/ndnsec/ndn-testbed-root-x3.ndncert | base64 | tee /etc/ndn/certs/ndn-testbed-root-x3.ndncert
echo '
rule
{
  id "rib register command"
  for interest
  filter
  {
    type name
    regex ^<localhop><nfd><rib>[<register><unregister>]<>{3}$
  }
  checker
  {
    type customized
    sig-type ecdsa-sha256
    key-locator
    {
      type name
      regex ^<>*<KEY><>{1,3}$
    }
  }
}
rule
{
  id "hierarchy"
  for data
  filter
  {
    type name
    regex ^<>*<KEY><>{3}$
  }
  checker
  {
    type customized
    sig-type ecdsa-sha256
    key-locator
    {
      type name
      hyper-relation
      {
        k-regex ^(<>*)<KEY><>{1,3}$
        k-expand \\1
        h-relation is-prefix-of
        p-regex ^(<>*)$
        p-expand \\1
      }
    }
  }
}
trust-anchor
{
  type file
  file-name certs/ndn-testbed-root-x3.ndncert
}
' | infoedit -f /etc/ndn/nfd.conf -a rib.localhop_security

The pcap trace is my test result.
There are two (logical) end hosts connected to the same NFD router, one uses UDP and the other uses TCP.

All certificates are fetched into the router cache before sending the registration command.
This is for convenience, and does not affect validation logic in any way.

Frame 7 is a prefix registration command with a certificate name in the KeyLocator: /ndn/gr/edu/mmlab1/%40GUEST/robik29763%40sofiarae.com/KEY/36=%00%05%B8%BE%DBm%07%B0/NA/%FD%00%00%01v%F9%94%1E%1A.
This certificate and its ancestors all have key names in their KeyLocator fields.

Frame 22 is a prefix registration command with a key name in the KeyLocator: /ndn/gr/edu/mmlab1/%40GUEST/robik29763%40sofiarae.com/sunny5/KEY/%A2%3D%E3%06Fb%86%3F.
The referenced certificate is /ndn/gr/edu/mmlab1/%40GUEST/robik29763%40sofiarae.com/sunny5/KEY/%A2%3D%E3%06Fb%86%3F/NDNts-Personal-CA/35=%00%00%01wL%A5%91%22, retrieved in frame 20.
Its KeyLocator has a certificate name /ndn/gr/edu/mmlab1/%40GUEST/robik29763%40sofiarae.com/KEY/36=%00%05%B8%BE%DBm%07%B0/NA/%FD%00%00%01v%F9%94%1E%1A.

This test confirms that the given configuration snippet can accommodate both key name and certificate name in the KeyLocator of both signed Interest and Data.
However, current snippet only recognizes ECDSA signatures, but does not recognize RSA signatures.

#7

Updated by Junxiao Shi 8 months ago

https://gerrit.named-data.net/c/NFD/+/6331

Currently, "NDN Testbed Hierarchy Rule" uses key-locator.hyper-relation to define the hierarchical relation.
This would allow a quick roll-out that can be deployed today.

After #5142, it will be switched back to use the hierarchical checker.

#8

Updated by Junxiao Shi 7 months ago

  • Status changed from In Progress to Closed
  • Target version set to v0.8
  • % Done changed from 50 to 100

This feature is merged.
Library issues discovered during code review are reported as #5145 and #4524.

Also available in: Atom PDF