Project

General

Profile

Actions

Bug #1522

closed

Command Interests should not expect synchronized clock

Added by Junxiao Shi almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Protocol
Target version:
Start date:
04/21/2014
Due date:
% Done:

0%

Estimated time:

Description

Command Interests spec revision 5 says:

If the received Interest is supposed to be signed, it will be treated as invalid in the following four cases:

  • the producer has already received a valid signed Interest whose timestamp is equal or later than the timestamp of the received one.

Note that in order to detect the fourth case, the producer needs to maintain a latest timestamp state for each trusted public key (or global latest timestamp for all trusted public keys).

Note that for the first Interest, the state is not available. To handle this special situation, the producer should check the Interest's timestamp against a proper interval (e.g., 120 seconds) [current_timestamp - interval/2, current_timestamp + interval/2]. The first interest is invalid if its timestamp is outside of the interval.

The spec does not forbid usage of Command Interests across multiple machines, does not require each consumer to have different signing key, and even permits the producer to keep a global latest timestamp.

Scenario 1

Environment:

  • Producer P chooses to keep global latest timestamp
  • P and A have accurate clocks
  • B's clock is 1 hour ahead
  • A and B both have trusted keys.

Steps to reproduce:

  1. A sends Command Interest 1 to P.
    Command Interest 1 is treated as valid.
  2. B sends Command Interest 2 to P. Command Interest 2 is treated as valid.
  3. A sends Command Interest 3 to P.

Expected: Command Interest 3 is treated as valid.

Actual: Command Interest 3 is treated as invalid because its timestamp is earlier than Command Interest 2.

Scenario 2

Environment:

  • Producer P keeps latest timestamp per public key.
  • Clients A, B, C, D uses same signing key.
  • P, A, B, C, D are on same machine and thus have accurate clocks.

Steps to reproduce:

  1. Each of A,B,C,D sends a Command Interest to P at the same time.

Expected: All Command Interests are treated as valid.

Actual: 0~3 Command Interests are treated as invalid.


Files

test.tar.gz (1.92 KB) test.tar.gz script to reproduce scenario 2 using NFD and traffic-server, by @Jerald Junxiao Shi, 04/21/2014 01:19 PM
Actions #1

Updated by Yingdi Yu almost 10 years ago

The scenario 1 should not happen with current implementation, because we keep separate timestamp for each trusted key.

For the second scenario, my question is: is it correct to allow clients to share the same private key?

Actions #2

Updated by Alex Afanasyev almost 10 years ago

Different nodes should not share the private keys.

If needed, authorize multiple public keys for NFD. NRD can be configured to have common trust anchor, so only this anchor needs to be configured.

Actions #3

Updated by Junxiao Shi almost 10 years ago

This bug is about the protocol, not the implementation.

Scenario 1: Even if this won't happen in current implementation, the protocol allows an implementation to have global latest timestamp, which allows this scenario to happen.

Scenario 2: If sharing keys among different hosts or among different clients are not allowed, the protocol should explicitly forbid it, or reference another document that forbids such usage.

Actions #4

Updated by Jerald Paul Abraham almost 10 years ago

For scenario 2, when we say "the producer has already received a valid signed Interest whose timestamp is equal or later than the timestamp of the received one."

equal to the timestamp of the already received one, is it correct?

Does this mean that a valid interest, even if different would be treated invalid because it arrived at the same time of a previous one?

Actions #5

Updated by Yingdi Yu almost 10 years ago

Junxiao Shi wrote:

Scenario 1: Even if this won't happen in current implementation, the protocol allows an implementation to have global latest timestamp, which allows this scenario to happen.

I have removed the "global latest timestamp" from the spec.

Scenario 2: If sharing keys among different hosts or among different clients are not allowed, the protocol should explicitly forbid it, or reference another document that forbids such usage.

I have added a statement in the spec to emphasize such usage is not recommended and the potential issue of sharing private key.

Actions #6

Updated by Yingdi Yu almost 10 years ago

Jerald Paul Abraham wrote:

For scenario 2, when we say "the producer has already received a valid signed Interest whose timestamp is equal or later than the timestamp of the received one."

equal to the timestamp of the already received one, is it correct?

Does this mean that a valid interest, even if different would be treated invalid because it arrived at the same time of a previous one?

This constraint is to prevent replay attack. The one who generates command interests should guarantee the uniqueness of timestamp (check the implementation of CommandInterestGenerator as an example).

Actions #7

Updated by Junxiao Shi almost 10 years ago

  • Status changed from New to Resolved
  • Target version set to v0.1

This amendment makes sense.

Actions #8

Updated by Junxiao Shi almost 10 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF