Feature #5114
closed
Accommodate certificate name in KeyLocator in /localhop/nfd/rib validation rules
100%
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
Updated by Junxiao Shi over 4 years ago
- Related to Feature #5112: Include certificate name in KeyLocator added
Updated by Davide Pesavento over 4 years ago
I'm not sure what we need to do here. Isn't this purely a configuration thing?
Updated by Junxiao Shi over 4 years 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.
- Change
nfd.conf.sample.inin NFD codebase and PPA package. - Deploy to testbed https://github.com/WU-ARL/NDN_Ansible/issues/35
- After that, an end host with #5112 can register prefix on testbed without being affected by this configuration.
Updated by John DeHart almost 4 years 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.
- Change
nfd.conf.sample.inin NFD codebase and PPA package.- Deploy to testbed https://github.com/WU-ARL/NDN_Ansible/issues/35
- 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?
Updated by Junxiao Shi almost 4 years 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.
Updated by Junxiao Shi almost 4 years ago
- File NFD-5114_20210129.pcapng NFD-5114_20210129.pcapng added
- Status changed from New to In Progress
- Assignee set to Junxiao Shi
- % Done changed from 0 to 50
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.
Updated by Junxiao Shi almost 4 years 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.
Updated by Junxiao Shi over 3 years ago
- Status changed from In Progress to Closed
- Target version set to 22.02
- % Done changed from 50 to 100