Project

General

Profile

Feature #4804

Signed Interest v0.3

Added by Junxiao Shi over 1 year ago. Updated 8 days ago.

Status:
Code review
Priority:
Normal
Assignee:
Category:
Base
Target version:
Start date:
Due date:
% Done:

50%

Estimated time:

Description

Implement Signed Interest as defined in NDN Packet Format v0.3.


Related issues

Blocked by NDN Specifications - Feature #4599: Redesign Signed Interest and Command Interest for packet format v0.3ClosedZhiyi Zhang

Actions
Blocked by ndn-cxx - Feature #4567: Encode Interest into v0.3 format and drop support for v0.2 formatClosedDavide Pesavento

Actions
Blocks NFD - Feature #4786: KITE implementationIn ProgressZhongda Xia

Actions
Blocks NFD - Feature #4650: Accept and store PrefixAnnouncement in rib/register commandIn ProgressJunxiao Shi

Actions
#1

Updated by Junxiao Shi over 1 year ago

  • Blocked by Feature #4599: Redesign Signed Interest and Command Interest for packet format v0.3 added
#2

Updated by Junxiao Shi over 1 year ago

  • Blocked by Feature #4567: Encode Interest into v0.3 format and drop support for v0.2 format added
#3

Updated by Junxiao Shi 11 months ago

From https://gerrit.named-data.net/5494

I had a working design earlier in the quarter where an InterestSignatureInfo was a subclass of SignatureInfo, and that worked well independently, but it became very messy in conjunction with Signature.

Given InterestSignatureInfo and DataSignatureInfo can have different fields, they should be different classes.

/// base class
class SignatureInfo
{
  // have fields that appear in both Interest and Data
};

class InterestSignatureInfo extends SignatureInfo
{
  // implicitly constructible from SignatureInfo
  // add fields that appear in Interest only
};

class DataSignatureInfo extends SignatureInfo
{
  // implicitly constructible from SignatureInfo
  // add fields that appear in Data only, ValidityPeriod and "other TLVs" should be moved there
};

The Signature type is messy and difficult to use. Deprecate it, and replace with four methods on both Interest and Data: getSignatureInfo setSignatureInfo getSignatureValue setSignatureValue.

#4

Updated by Junxiao Shi 11 months ago

https://gerrit.named-data.net/5502 patchset3 extends ValidatorConfig with three replay checkers that verifies SignatureNonce SignatureTime SignatureSeqNum elements according to spec. They appear as a checker under a rule, along with two key name checkers.
According to rules in general section:

A packet is treated as valid if it can pass at least one of the checkers and as invalid when it cannot pass any checkers.

This means, suppose I write a rule that contains two key name checkers, one SignatureTime checker, and one SignatureSeqNum checker, a signed Interest would be treated as valid if it (1) has an untrusted key name (2) has an unacceptable SignatureTime (3) has an acceptable SignatureSeqNum, because all it takes to pass the validator is one successful checker.
This violates the signed Interest spec that requires all three checkers to pass.

Simply defining all replay checkers to have an AND relation is insufficient, because an application may want to allow the incoming signed Interest to carry either a valid SignatureTime or a valid SignatureSeqNum. This practice is permitted by the spec: the spec requires validation of both SignatureTime and SignatureSeqNum if they are present, but does not forbid an application to accept either of them.

To solve this problem, define explicit logical relation operators among checkers:

checker {
  type AND
  checker {
    type OR
    checker {
      type hierarchical
      sig-type rsa-sha256
    }
    checker {
      type hierarchical
      sig-type ecdsa-sha256
    }
  }
  checker {
    type timestamp
  }
  checker {
    type seq-num
  }
}
#5

Updated by Vladimir Vysotsky 11 months ago

Given InterestSignatureInfo and DataSignatureInfo can have different fields, they should be different classes.

/// base class
class SignatureInfo
{
  // have fields that appear in both Interest and Data
};

class InterestSignatureInfo extends SignatureInfo
{
  // implicitly constructible from SignatureInfo
  // add fields that appear in Interest only
};

class DataSignatureInfo extends SignatureInfo
{
  // implicitly constructible from SignatureInfo
  // add fields that appear in Data only, ValidityPeriod and "other TLVs" should be moved there
};

Sounds great. Should these be in separate files? If so, should they go in a signature/ or security/signature/ subdirectory, since there would be 6 files total? I don't want to spam the top-level dir with that many related components.

#6

Updated by Junxiao Shi 11 months ago

  • Status changed from New to In Progress
  • Assignee set to Vladimir Vysotsky
#7

Updated by Zhongda Xia 11 months ago

#8

Updated by Davide Pesavento 9 months ago

  • Target version changed from v0.7 to v0.8
#9

Updated by Davide Pesavento 8 months ago

  • Assignee deleted (Vladimir Vysotsky)
#11

Updated by Junxiao Shi 6 months ago

  • Assignee changed from Alex Afanasyev to Zhongda Xia

Since Zhongda wants this feature, I'm assigning this to him.

#12

Updated by Junxiao Shi 4 months ago

  • Blocks Feature #4650: Accept and store PrefixAnnouncement in rib/register command added
#13

Updated by Davide Pesavento about 2 months ago

  • Assignee deleted (Zhongda Xia)
  • Estimated time deleted (6.00 h)
#14

Updated by Eric Newberry about 2 months ago

  • Assignee set to Eric Newberry
#15

Updated by Junxiao Shi about 2 months ago

#16

Updated by Davide Pesavento about 2 months ago

#17

Updated by Eric Newberry 15 days ago

  • Status changed from In Progress to Code review
  • % Done changed from 0 to 50
#18

Updated by Eric Newberry 8 days ago

On the NDN platform call on May 29, 2020, it was decided to change SignatureNonce into a variable-length field with a minimum length of 1. In the spec, we will recommend a minimum length of 8.

Also available in: Atom PDF