[Ndn-interest] [Clue] A Cloud-Applicable Network Policy Enforcement Strategy using Named Data
tailinchu at gmail.com
Sat Sep 20 01:06:15 PDT 2014
> I hope you could read the spec of signed interest carefully and think a little bit more before making the claim above.
sorry, I was making an extreme example of unsynced clock (I know that
nfd uses unix UTC time).
Btw, do you know why we have both nonce and timestamp in signed
interest? Will seq no alone solve this problem? I am worried that msec
might not be sufficient in the future.
On Sat, Sep 20, 2014 at 12:19 AM, Yingdi Yu <yuyingdi at gmail.com> wrote:
> On Sep 19, 2014, at 10:01 PM, Tai-Lin Chu <tailinchu at gmail.com> wrote:
> However, desync clocks (for example. nfd runs UTC, and we are in a
> different timezone) makes signed interest unsecure. If we are in +8
> timezone, then all signed interests will give attackers 8 hours to
> replay any command before it gets too old. If we are in -8 timezone,
> then all signed interests are already too old. If we carefully match
> the time, the threshold for expiration will have to compensate
> network delay, and give attackers a few secs to replay. Therefore, the
> current signed interest is not very secure IMHO. Maybe you can also
> propose a better scheme for signed interest.
> Hi Tai-Lin
> I hope you could read the spec of signed interest carefully and think a
> little bit more before making the claim above.
> First, the spec says that timestamp is "millisecond offset from UTC
> 1970-01-01 00:00:00", that means it is independent from the time zone...
> Second, about timestamp checking, it is not
> check timestamp to see whether this command is too old
> The spec says that:
> Recipients of a signed interest may further check the timestamp and the
> uniqueness of the signed interest (e.g., when the signed interest carries a
> command). In this case, a signed interest may be treated as invalid if :
> a valid signed Interest whose timestamp is equal or later than the timestamp
> of the received one has been received before.
> This check simply prevents replay attack.
More information about the Ndn-interest