Bug #1522
closed
Command Interests should not expect synchronized clock
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:
- A sends Command Interest 1 to P.
Command Interest 1 is treated as valid. - B sends Command Interest 2 to P. Command Interest 2 is treated as valid.
- 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:
- 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
Updated by Yingdi Yu over 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?
Updated by Alex Afanasyev over 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.
Updated by Junxiao Shi over 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.
Updated by Jerald Paul Abraham over 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?
Updated by Yingdi Yu over 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.
Updated by Yingdi Yu over 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).
Updated by Junxiao Shi over 10 years ago
- Status changed from New to Resolved
- Target version set to v0.1
This amendment makes sense.