Bug #3640
closedECDSA key unusable with automatic prefix propagation
100%
Description
Steps to reproduce:
- On machine A, request a certificate from ndncert system. Once it's approved, install the certificate.
- On machine B, generate a certificate request under the namespace of step1 certificate.
- On machine A, sign step2 certificate request with step1 key.
- On machine A, publish step3 certificate with repo-ng, and make sure
ndnpeek
can retrieve this certificate anywhere on the testbed. - On machine B, install step3 certificate.
- On machine B, start NFD, and trigger automatic prefix propagation using step3 certificate.
Expected: automatic prefix propagation succeeds
Actual: fail to propagate <step2 identity> reason:Signature type does not match: 1!=3
Root cause: testbed nodes are not properly configured to accept ECDSA signatures
Updated by Junxiao Shi over 8 years ago
- Assignee set to John DeHart
I'm seeing this on a testbed router:
localhop_security
{
rule
{
id "NRD Prefix Registration Command 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>]*<KEY><>*<ksk-.*><ID-CERT>$
}
}
}
rule
{
id "NDN Testbed Hierarchy Rule"
for data
filter
{
type name
regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT><>$
}
checker
{
type hierarchical
sig-type rsa-sha256
}
}
trust-anchor
{
type file
file-name keys/ndn-testbed-root.ndncert.base64
}
}
All these rules are RSA only. They should be modified to permit ECDSA.
ECDSA signature acceptance is important for automatic prefix propagation from devices with limited computation power.
Updated by John DeHart over 8 years ago
Are there any other key types that are needed?
Updated by John DeHart over 8 years ago
And is the proper sig-type:
sig-type ecdsa-sha256
Updated by Zhiyi Zhang over 8 years ago
John DeHart wrote:
Are there any other key types that are needed?
Up to now, in ndn-cxx, there are two types of sig type : sha256 with RSA and sha256 with ECDSA. You may ask Yingdi. He knows this part better.
Updated by Junxiao Shi over 8 years ago
- Status changed from New to Feedback
I notice the configuration has been updated. I haven't tested ECDSA, but prefix registrations with RSA signatures are failing:
Named Data Networking (NDN), Data, Name: /localhop/nfd/rib/unregister/hndn broadcasto@/
Data, Type: 6, Length: 798, Name: /localhop/nfd/rib/unregister/hndn broadcasto@/
Name: /localhop/nfd/rib/unregister/h\025\a\020\b\003ndn\b\tbroadcasto\001@/
NameComponent: localhop
NameComponent: nfd
NameComponent: rib
NameComponent: unregister
NameComponent: h\025\a\020\b\003ndn\b\tbroadcasto\001@
NameComponent:
NameComponent: \022e\357\277\275\357\277\275
NameComponent: \026K\033\001\001\034F\aD\b\003ndn\b\003edu\b\aarizona\b\003KEY\b\002cs\b\nshijunxiao\b\021ksk-1457557007329\b\aID-CERT
SignatureInfo, Type: 22, Length: 75, SignatureType: 1, KeyLocator: Name: /ndn/edu/arizona/KEY/cs/shijunxiao/ksk-1457557007329/ID-CERT
SignatureType: 1
KeyLocator, Type: 28, Length: 70, Name: /ndn/edu/arizona/KEY/cs/shijunxiao/ksk-1457557007329/ID-CERT
Name: /ndn/edu/arizona/KEY/cs/shijunxiao/ksk-1457557007329/ID-CERT
NameComponent: \027\357\277\275\001
SignatureValue: 17fd010019582fee35af0e7c1ddef11dd8fb4dd23494def0..., Type: 23, Length: 256
MetaInfo, Type: 20, Length: 0
Content: \025+e)f\002\001\357\277\275g#Signature type does not match: 3!=1, Type: 21, Length: 43
SignatureInfo, Type: 22, Length: 65, SignatureType: 1, KeyLocator: Name: /localhost/daemons/nfd/KEY/ksk-1460130487796/ID-CERT
SignatureValue: 17fd0100811238c37358d16abf9d0e2a48845f2d5ffc84a2..., Type: 23, Length: 256
Can @Zhiyi supply a correct configuration snippet that accepts both RSA and ECDSA signatures?
Updated by Yingdi Yu over 8 years ago
The spec of validator configuration is correct, but there is an implementation bug in security::conf::Checker
, we need to fix http://redmine.named-data.net/issues/3645 first.
Updated by Yingdi Yu over 8 years ago
- Blocked by Bug #3645: Checkers in ValidatorConfig directly invoke ValidationFailureCallback added
Updated by Junxiao Shi over 8 years ago
Updated by John DeHart about 8 years ago
Junxiao Shi wrote:
The spec of validator configuration is correct, but there is an implementation bug in
security::conf::Checker
, we need to fix #3645 first.#3645 is closed. After deployment, how to proceed with this? How to write the configuration?
Now that 0.5.0 is deployed in the Testbed are we ready to turn on ECDSA rules?
Updated by Zhiyi Zhang about 8 years ago
I think just add checker in each rule and it should work.
The checker in the "NRD Prefix Registration Command Rule" :
checker
{
type customized
sig-type ecdsa-sha256
key-locator
{
type name
regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$
}
}
The checker in the "NDN Testbed Hierarchy Rule"
checker
{
type hierarchical
sig-type ecdsa-sha256
}
Then add a new trust anchor in the end.
trust-anchor
{
type file
file-name keys/ndn-testbed-root.ecdsa.ndncert.base64
}
Updated by Junxiao Shi about 8 years ago
Follow-up to note-10:
Can you add the example into nfd.conf.sample
file, and also modify IntegrationTests auto prefix propagation scenario to test with a mix of RSA and ECDSA keys?
Updated by Zhiyi Zhang about 8 years ago
I will, but it may take some time. I have never got into detail of NFD. I may first need to know what's going on now and then do the change.
Updated by Junxiao Shi about 8 years ago
- Blocks Feature #3826: Automatic prefix propagation scenario: ECDSA signing added
Updated by Junxiao Shi about 8 years ago
- Assignee changed from John DeHart to Zhiyi Zhang
- Estimated time set to 3.00 h
I've split IntegrationTests work to #3826. This issue can close as soon as nfd.conf.sample
is updated.
Updated by John DeHart about 8 years ago
Zhiyi Zhang wrote:
I think just add checker in each rule and it should work.
The checker in the "NRD Prefix Registration Command Rule" :checker { type customized sig-type ecdsa-sha256 key-locator { type name regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$ } }
The checker in the "NDN Testbed Hierarchy Rule"
checker { type hierarchical sig-type ecdsa-sha256 }
Then add a new trust anchor in the end.
trust-anchor { type file file-name keys/ndn-testbed-root.ecdsa.ndncert.base64 }
Has an ecdsa root key been generated by anyone for this trust anchor?
Updated by Zhiyi Zhang about 8 years ago
We can use RSA root key only, and update config file to support the ECDSA key validation. Sure we can have a ECDSA root key and it can work.
Updated by Zhiyi Zhang about 8 years ago
- % Done changed from 0 to 80
Now we can support ECDSA signature. However seems we have a new bug now: when do remote prefix registration with ECDSA key signature for the first time, there will be a failure because of validating parameters (code: 400). The second time try will succeed.
Updated by Junxiao Shi about 8 years ago
Reply to note-17:
What's the relevant log lines, on both end host and router?
What's seen in tcpdump?
I suspect there's a time synchronization problem or certificate retrieval delay.
Updated by Zhiyi Zhang about 8 years ago
Reply to note-18:
On my localhost test:
The log from NFD:
1478288791.079004 INFO: [UnixStreamTransport] [id=0,local=unix:///private/var/run/nfd.sock,remote=fd://33] Creating transport
1478288791.079022 INFO: [FaceTable] Added face id=266 remote=fd://33 local=unix:///private/var/run/nfd.sock
1478288791.127800 INFO: [Transport] [id=266,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState UP -> FAILED
1478288791.127837 INFO: [Transport] [id=266,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState FAILED -> CLOSED
1478288791.145549 INFO: [FaceTable] Removed face id=266 remote=fd://33 local=unix:///private/var/run/nfd.sock
The result after running nfdc register for the first time:
Failed in unregistering name: failed in validating parameters (code: 400)
For the second try:
From NFD:
1478288793.624334 INFO: [UnixStreamTransport] [id=0,local=unix:///private/var/run/nfd.sock,remote=fd://33] Creating transport
1478288793.624363 INFO: [FaceTable] Added face id=267 remote=fd://33 local=unix:///private/var/run/nfd.sock
1478288793.663790 INFO: [RibManager] Removing route /ndn nexthop=264 origin=255
1478288793.664282 INFO: [Transport] [id=267,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState UP -> FAILED
1478288793.664319 INFO: [Transport] [id=267,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState FAILED -> CLOSED
1478288793.694358 INFO: [FaceTable] Removed face id=267 remote=fd://33 local=unix:///private/var/run/nfd.sock
Result of nfdc register:
Successful in unregistering name: ControlParameters(Name: /ndn, FaceId: 264, Origin: 255, )
Updated by Junxiao Shi almost 8 years ago
note-19 does not answer ALL questions in note-18. Complete answers in exactly same scenario (i.e. remote prefix registration) are needed.
Updated by Zhiyi Zhang almost 8 years ago
Don't know how to go further, maybe someone who is familiar with NFD can solve the problem.
There is no error for my most recent try and I don't know why.
This is the most recent tcpdump log:
15:09:37.729876 IP wifi-131-179-33-163.host.ucla.edu.63922 > ndn-remap-p05.it.ucla.edu.6363:
Flags [S], seq 3920632055, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 236349370 ecr 0,sackOK,eol], length 0
15:09:37.734723 IP ndn-remap-p05.it.ucla.edu.6363 > wifi-131-179-33-163.host.ucla.edu.63922:
Flags [S.], seq 131968288, ack 3920632056, win 28960, options [mss 1380,sackOK,TS val 434287326 ecr 236349370,nop,wscale 7], length 0
15:09:37.734753 IP wifi-131-179-33-163.host.ucla.edu.63922 > ndn-remap-p05.it.ucla.edu.6363:
Flags [.], ack 1, win 4104, options [nop,nop,TS val 236349374 ecr 434287326], length 0
15:09:37.734860 IP wifi-131-179-33-163.host.ucla.edu.63922 > ndn-remap-p05.it.ucla.edu.6363:
Flags [P.], seq 1:269, ack 1, win 4104, options [nop,nop,TS val 236349374 ecr 434287326], length 268
15:09:37.738731 IP ndn-remap-p05.it.ucla.edu.6363 > wifi-131-179-33-163.host.ucla.edu.63922:
Flags [.], ack 269, win 235, options [nop,nop,TS val 434287327 ecr 236349374], length 0
15:09:37.756521 IP ndn-remap-p05.it.ucla.edu.6363 > wifi-131-179-33-163.host.ucla.edu.63922:
Flags [P.], seq 1:646, ack 269, win 235, options [nop,nop,TS val 434287332 ecr 236349374], length 645
15:09:37.756563 IP wifi-131-179-33-163.host.ucla.edu.63922 > ndn-remap-p05.it.ucla.edu.6363:
Flags [.], ack 646, win 4083, options [nop,nop,TS val 236349395 ecr 434287332], length 0
Updated by Junxiao Shi almost 8 years ago
note-19 and note-21 did not answer ALL questions in note-18. Complete answers in exactly same scenario (i.e. remote prefix registration) are needed. tcpdump trace should be attached as .pcap file, rather than pasted as text output.
Updated by Zhiyi Zhang almost 8 years ago
How can I get the log lines of the router? I mean where can find, for example I tested on the REMAP, how can I find the log information of REMAP's NFD.
Updated by Junxiao Shi almost 8 years ago
How can I get the log lines of the router?
You'll need to work with the operator of this router. If you don't know who's the operator, ask operators
mailing list.
- You can determine which NFD log sources need more detailed logs in order to help you diagnose the problem. I suggest
Forwarder=DEBUG
as a start. - Ask the operator to set the log levels, then send a signal to let NFD reload configuration; also, start a
tcpdump
session to capture NDN traffic. - You can run the test on a laptop connected to the router. Don't forget to raise log levels and
tcpdump
locally. - Ask the operator to restore the log levels, and send you the NFD logs and
tcpdump
trace.
Updated by Zhiyi Zhang almost 8 years ago
OK, it takes a little bit time. I will coordinate with REMAP's operator Zhehao to figure it out. I will do the update in time once we figure it out.
Updated by Alex Afanasyev almost 8 years ago
Here are my comments, based on experimentation during the retreat:
I have kind of succeeded to run (remote/automatic) prefix registration using ECDSA keys, but I'm getting unpredictable NFD crashes and failures:
Also, registration doesn't succeed from the first time for all types of keys:
(ECDSA)
✘ 17:07 ~/Downloads/1 [ master | ✚ 1 ] $ ndnsec-set-default /ndn/edu/ucla/%40GUEST/aa%40cs.ucla.edu
✘ 17:07 ~/Downloads/1 [ master | ✚ 1 ] $ ./reg 128.97.98.7
FAILURE: authorization rejected
✔ 17:08 ~/Downloads/1 [ master | ✚ 1 ] $ ./reg 128.97.98.7
FAILURE: failed in validating parameters
✔ 17:08 ~/Downloads/1 [ master | ✚ 1 ] $ ./reg 128.97.98.7
SUCCESS waiting
(RSA)
✔ 17:10 ~/Downloads/1 [ master | ✚ 1 ] $ ndnsec-set-default /ndn/edu/ucla/remap/%40GUEST/aa%40cs.ucla.edu
✔ 17:10 ~/Downloads/1 [ master | ✚ 1 ] $ ./reg 128.97.98.7
FAILURE: failed in validating parameters
✔ 17:10 ~/Downloads/1 [ master | ✚ 1 ] $ ./reg 128.97.98.7
SUCCESS waiting
Updated by Zhiyi Zhang almost 8 years ago
The question is here:
From ndn-cxx/src/mgmt/nfd/control-command.cpp
void
ControlCommand::FieldValidator::validate(const ControlParameters& parameters) const
{
const std::vector<bool>& presentFields = parameters.getPresentFields();
for (size_t i = 0; i < CONTROL_PARAMETER_UBOUND; ++i) {
bool isPresent = presentFields[i];
if (m_required[i]) {
if (!isPresent) {
BOOST_THROW_EXCEPTION(ArgumentError(CONTROL_PARAMETER_FIELD[i] + " is required but "
"missing"));
}
}
else if (isPresent && !m_optional[i]) {
BOOST_THROW_EXCEPTION(ArgumentError(CONTROL_PARAMETER_FIELD[i] + " is forbidden but "
"present"));
}
}
}
There is a throw happened here so that the response is failed in validating parameters. For RibRegisterCommand, the parameter list is:
m_requestValidator
.required(CONTROL_PARAMETER_NAME)
.optional(CONTROL_PARAMETER_FACE_ID)
.optional(CONTROL_PARAMETER_ORIGIN)
.optional(CONTROL_PARAMETER_COST)
.optional(CONTROL_PARAMETER_FLAGS)
.optional(CONTROL_PARAMETER_EXPIRATION_PERIOD);
So the question is in NAME? Anyone may know the reason?
Updated by Junxiao Shi almost 8 years ago
Reply to note-27:
I don't know what you are asking, but this code can validate the response ControlParameters
from rib/register command according to RibMgmt spec, and throws if Name field is missing or a field not in the optional list appears.
Updated by Zhiyi Zhang almost 8 years ago
The error message is failed in validating parameters
, which can only happen in ControlCommand::FieldValidator::validate function
.
Here is my test:
I use
/ndn/edu/ucla/zhiyi
as the intermediate CA and create a ECDSA certificate for/ndn/edu/ucla/zhiyi/ecdsa-node
I added the new config file which support ECDSA to my localhost part in nfd.conf
I added std::cout in the ControlCommand::FieldValidator::validate function and reinstall the ndn-cxx library and then reinstall the NFD.
The function is now like:void ControlCommand::FieldValidator::validate(const ControlParameters& parameters) const { const std::vector<bool>& presentFields = parameters.getPresentFields(); for (size_t i = 0; i < CONTROL_PARAMETER_UBOUND; ++i) { bool isPresent = presentFields[i]; if (m_required[i]) { if (!isPresent) { std::cout << CONTROL_PARAMETER_FIELD[i] << " is required but missing" << std::endl; BOOST_THROW_EXCEPTION(ArgumentError(CONTROL_PARAMETER_FIELD[i] + " is required but missing")); } } else if (isPresent && !m_optional[i]) { std::cout << CONTROL_PARAMETER_FIELD[i] << " is forbidden but present" << std::endl; BOOST_THROW_EXCEPTION(ArgumentError(CONTROL_PARAMETER_FIELD[i] + " is forbidden but present")); } } }
I add the ECDSA certificate to repo and also add prefix to repo-ng.conf. Then I run repo-ng
I set /ndn/edu/ucla/zhiyi/ecdsa-node as default identity and run
nfdc register /ndn udp://spurs.cs.ucla.edu
. Here is the outputs. client part:~ nfdc register /ndn udp://spurs.cs.ucla.edu Failed in name registration: failed in validating parameters (code: 400) ~ nfdc register /ndn udp://spurs.cs.ucla.edu Successful in name registration: ControlParameters(Name: /ndn, FaceId: 264, Origin: 255, Cost: 0, Flags: 0x1, )
nfd part:
1482628587.603428 INFO: [UnixStreamTransport] [id=0,local=unix:///private/var/run/nfd.sock,remote=fd://33] Creating transport 1482628587.603447 INFO: [FaceTable] Added face id=267 remote=fd://33 local=unix:///private/var/run/nfd.sock 1482628587.720483 INFO: [Transport] [id=267,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState UP -> FAILED 1482628587.720522 INFO: [Transport] [id=267,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState FAILED -> CLOSED 1482628587.737156 INFO: [FaceTable] Removed face id=267 remote=fd://33 local=unix:///private/var/run/nfd.sock 1482628603.310834 INFO: [UnixStreamTransport] [id=0,local=unix:///private/var/run/nfd.sock,remote=fd://33] Creating transport 1482628603.310858 INFO: [FaceTable] Added face id=268 remote=fd://33 local=unix:///private/var/run/nfd.sock Name is required but missing 1482628605.807625 INFO: [Transport] [id=268,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState UP -> FAILED 1482628605.807752 INFO: [Transport] [id=268,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState FAILED -> CLOSED 1482628605.827329 INFO: [FaceTable] Removed face id=268 remote=fd://33 local=unix:///private/var/run/nfd.sock 1482628626.390622 INFO: [UnixStreamTransport] [id=0,local=unix:///private/var/run/nfd.sock,remote=fd://33] Creating transport 1482628626.390641 INFO: [FaceTable] Added face id=269 remote=fd://33 local=unix:///private/var/run/nfd.sock 1482628626.473108 INFO: [RibManager] Adding route /ndn nexthop=264 origin=255 cost=0 1482628626.473636 INFO: [Transport] [id=269,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState UP -> FAILED 1482628626.473662 INFO: [Transport] [id=269,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState FAILED -> CLOSED 1482628626.504099 INFO: [FaceTable] Removed face id=269 remote=fd://33 local=unix:///private/var/run/nfd.sock 1482628626.581862 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn
Result:
Notice the output of NFD. For the first nfdc command, there is a Name is required but missing
. For the second command, everything is OK. Now we know the error is because that for the first time, the command has no name or wrong name? Anyone knows what's going on here?
Updated by Junxiao Shi almost 8 years ago
- Target version changed from v0.5 to v0.6
Reply to note-29:
"Name is required but missing" indicates the ControlParameters
struct in either the request (a component of the Interest name) or the response (in the Data payload) is missing the Name
field. To figure out whether the problem is with the request or the response, look at call stack or add additional logging statements at callsite.
It's unclear whether the log is captured on the end host or the gateway router. It's necessary to debug on both ends.
Also, a Wireshark trace of the network packets will be helpful to determine which ControlParameters
struct is wrong. You may analyze the trace with NDN dissector for Wireshark, available from ndn-tools repository. You'll probably need to read raw TLV structs since the tool doesn't recognize management protocol TLV-TYPE codes.
Updated by Zhiyi Zhang almost 8 years ago
It can only indicates the ControlParameters. The error string "failed in validating parameters" is only in the request validation part. The problem may exist in the command generation in end host side. I will check it.
Updated by Junxiao Shi over 7 years ago
- Related to Bug #4059: localhop prefix registration "400 failed in validating parameters" at the first time added
Updated by Junxiao Shi over 7 years ago
- Status changed from Feedback to Closed
- % Done changed from 80 to 100
I confirm prefix registration with commands signed by ECDSA is now working, although "400 failed in validating parameters" error remains and it's tracked as #4059.