Project

General

Profile

Bug #3640

ECDSA key unusable with automatic prefix propagation

Added by Junxiao Shi over 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
RIB
Target version:
Start date:
06/02/2016
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

Steps to reproduce:

  1. On machine A, request a certificate from ndncert system. Once it's approved, install the certificate.
  2. On machine B, generate a certificate request under the namespace of step1 certificate.
  3. On machine A, sign step2 certificate request with step1 key.
  4. On machine A, publish step3 certificate with repo-ng, and make sure ndnpeek can retrieve this certificate anywhere on the testbed.
  5. On machine B, install step3 certificate.
  6. 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


Related issues

Related to NFD - Bug #4059: localhop prefix registration "400 failed in validating parameters" at the first timeClosed2017-04-20

Blocked by ndn-cxx - Bug #3645: Checkers in ValidatorConfig directly invoke ValidationFailureCallbackClosed2016-06-08

Blocks NFD - Feature #3826: Automatic prefix propagation scenario: ECDSA signingNew

History

#1 Updated by Junxiao Shi over 3 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.

#2 Updated by John DeHart over 3 years ago

Are there any other key types that are needed?

#3 Updated by John DeHart over 3 years ago

And is the proper sig-type:

sig-type ecdsa-sha256

#4 Updated by Zhiyi Zhang over 3 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.

#5 Updated by Junxiao Shi over 3 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?

#6 Updated by Yingdi Yu over 3 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.

#7 Updated by Yingdi Yu over 3 years ago

  • Blocked by Bug #3645: Checkers in ValidatorConfig directly invoke ValidationFailureCallback added

#8 Updated by Junxiao Shi about 3 years ago

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?

#9 Updated by John DeHart almost 3 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?

#10 Updated by Zhiyi Zhang almost 3 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
 }

#11 Updated by Junxiao Shi almost 3 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?

#12 Updated by Zhiyi Zhang almost 3 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.

#13 Updated by Junxiao Shi almost 3 years ago

  • Blocks Feature #3826: Automatic prefix propagation scenario: ECDSA signing added

#14 Updated by Junxiao Shi almost 3 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.

#15 Updated by John DeHart almost 3 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?

#16 Updated by Zhiyi Zhang almost 3 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.

#17 Updated by Zhiyi Zhang almost 3 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.

#18 Updated by Junxiao Shi almost 3 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.

#19 Updated by Zhiyi Zhang almost 3 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, )

#20 Updated by Junxiao Shi almost 3 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.

#21 Updated by Zhiyi Zhang almost 3 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

#22 Updated by Junxiao Shi almost 3 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.

#23 Updated by Zhiyi Zhang almost 3 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.

#24 Updated by Junxiao Shi almost 3 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.

  1. 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.
  2. 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.
  3. You can run the test on a laptop connected to the router. Don't forget to raise log levels and tcpdump locally.
  4. Ask the operator to restore the log levels, and send you the NFD logs and tcpdump trace.

#25 Updated by Zhiyi Zhang almost 3 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.

#26 Updated by Alex Afanasyev almost 3 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

#27 Updated by Zhiyi Zhang over 2 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?

#28 Updated by Junxiao Shi over 2 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.

#29 Updated by Zhiyi Zhang over 2 years ago

The error message is failed in validating parameters, which can only happen in ControlCommand::FieldValidator::validate function.
Here is my test:

  1. I use /ndn/edu/ucla/zhiyi as the intermediate CA and create a ECDSA certificate for /ndn/edu/ucla/zhiyi/ecdsa-node

  2. I added the new config file which support ECDSA to my localhost part in nfd.conf

  3. 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"));
       }
      }
    }
    
  4. I add the ECDSA certificate to repo and also add prefix to repo-ng.conf. Then I run repo-ng

  5. 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?

#30 Updated by Junxiao Shi over 2 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.

#31 Updated by Zhiyi Zhang over 2 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.

#32 Updated by Junxiao Shi over 2 years ago

  • Related to Bug #4059: localhop prefix registration "400 failed in validating parameters" at the first time added

#33 Updated by Junxiao Shi over 2 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.

Also available in: Atom PDF