[ntp:questions] Autokey users - please read

Dave Hart davehart at gmail.com
Fri Sep 11 17:05:34 UTC 2009


On Fri, Sep 11, 2009 at 1:37 PM, Ryan Malayter wrote:
> I don't use autokey in production, but I would also suggest that if
> the issue causes the reference implementation to violate RFCs and also
> creates a security issue with key shortening, it should be fixed
> without any options to go back to the bad behavior. Actually, the
> security issue might in fact be major, if the a zero is randomly
> generated in the first few bytes of the key, correct?

Incorrect.  While the behavior violates the Autokey spec, I doubt
there is any security issue.  The session keys are each used once, in
a sequence that is predictable only to the two parties involved,
thanks to a seed securely negotiated using a higher level of Autokey,
and to using the generated key list backwards.  Shortened individual
session keys can not be reused even if correctly guessed by a 3rd
party listener.  The session keys are used to sign traffic, not
encrypt it, FYI.

> Please don't take the Microsoft route, where praying to the altar of
> backwards compatibility means you are stuck with ugly hacks for
> decades.
[...]

Even if a runtime workaround were used to allow a single ntpd to
Autokey with both corrected and uncorrected ntpd peers simultaneously,
the "ugly hack" would not mean ntpd is stuck with it -- unless you
intend to use Autokey with uncorrected ntpd forever.  The workaround
could be disabled from the start, even when enabled was used only when
necessary.  Even when it was used with a configured peer, where ntpd
remembered that the peer needed shortened session keys, it would be
disabled on receipt of the first traffic signed by a complete key
subject to shortening, meaning the remote ntpd could be upgraded to a
corrected version while the local one stayed up without perpetuating
workaround's use any more than necessary.

It seems likely the runtime workaround will not be in ntpd because the
added complexity is not worth the benefit.  Instead, a configure knob
will allow building a new ntpd with the old behavior.  It may never be
used, and as with the runtime workaround option, it can be excised at
any time -- there is no reason ntpd would be stuck with it.

Cheers,
Dave Hart

Cheers,
Dave Hart




More information about the questions mailing list