Bug #1522
closed
Command Interests should not expect synchronized clock
Added by Junxiao Shi over 10 years ago.
Updated over 10 years ago.
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
|
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
|
|
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?
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.
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.
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?
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.
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).
- Status changed from New to Resolved
- Target version set to v0.1
This amendment makes sense.
- Status changed from Resolved to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by