Renewing expiring key - done correctly?

[Leo Gaspard]

On Wed, Dec 04, 2013 at 10:04:44PM -0500, Robert J. Hansen wrote:
> On 12/4/2013 6:13 PM, Leo Gaspard wrote:
> > So you could only delay the expiration date by 15 min... So useful ?
> 
> Sure.  I can think of three ways to leverage a 15-minute maximum shift
> into dialing the clock back to whenever I want.  I'm sure if I were to
> spend more time thinking I could find more ways.  Spend some time
> considering the problem: it's a fun thought experiment and will help
> sharpen your skill at thinking like an attacker.
>
> NTP is not, and was never meant to be, secure against a malicious
> adversary.  It's resistant against random failures, but an attacker is
> going to induce conditions that are very far from random.

I only have in mind moving the clock 15min by 15min, but thought this method
could not be used. Indeed, the clock can only be reset 1000s by 1000s, and by
default I thought ntpd queries the server 1024s by 1024s, thus allowing the
attacker only to slow down time on the machine. However, it seems that by
sending times not exactly 1000s apart from the machine clock but alternatively
1000s - clock jitter and 1000s, you could force the query time to be back to
64s, thus making this attack possible.

However, a basic security measure (setting panic threshold to 50s, as there is
no reason the local time should be off by more than 50s, being re-updated every
1024s at most) would be enough to counter this fact.

BTW, reading more about ntpd [1], I learned that the query time could not be
back more than 300s. So, even in an unconfigured system, the attacker would
have to be in control of the victim's network for at least half the time since
the expiration date. Granted, this is not a lot (especially knowing the attacker
could have been attacking since before the expiration date), but is better than
mere immediate clock setting. And this 300s delay could be arbitrarily
increased, thus allowing to counter the attack by a second mean : setting it to
more than 2000s, for example.

Finally, I believe the user would notice, if their computer clock was suddenly
off one day / month / year / more...

One last comments : not everyone uses NTP (e.g. I rely on RTC, once in a while
syncing it with my watch -- did not have to for a year, and I'm 2min off)

Just wondering... What are your other two solutions ?

[1] http://www.eecis.udel.edu/~mills/ntp/html/clock.html