Actions
Bug #3821
closedCommandAuthenticator denial-of-service
Start date:
Due date:
% Done:
0%
Estimated time:
Description
CommandAuthenticator
design is subject to a form of denial-of-service attack.
Steps to reproduce:
- Generate signing certificate
A.ndncert
, whose private key is accessible by appA only. - In NFD configuration file, grant a privilege to
A.ndncert
. - From appB, send a control command of the granted privilege with current timestamp, a KeyLocator corresponding to
A.ndncert
, and a bogus signature. The authenticator will reject this control command due to invalid signature, but thendn::security::CommandInterestValidator
will internally record the timestamp. - From appB, send another control command of the granted privilege with current timestamp plus one day, a KeyLocator corresponding to
A.ndncert
, and a bogus signature. The authenticator will reject this control command due to invalid signature, but thendn::security::CommandInterestValidator
will internally bump the last timestamp ofA.ndncert
's key name by one day. - From appA, send a control command of the granted privilege with current timestamp, and correct KeyLocator and signature corresponding to
A.ndncert
.
Expected: The command from appA is accepted.
Actual: The command from appA is rejected due to backdated timestamp.
Updated by Junxiao Shi about 8 years ago
- Blocked by Bug #2063: CommandValidator uses deprecated CommandInterestValidator added
Updated by Junxiao Shi over 7 years ago
- Status changed from New to Closed
This problem is solved when transitioning to v2 ValidationPolicyCommandInterest
in nfd:commit:dbb6b3e1192cc9bcd88e5d8e10c656e764d729fb.
Actions