[ntp:questions] Autokey users - please read

Todd Glassey tglassey at earthlink.net
Fri Sep 11 17:29:28 UTC 2009

Dave Hart wrote:
> 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?

The real question comes into using AutoKEY enablement with systems who 
would only want AutoKEY for certain hosts and not others.

> 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
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
> ------------------------------------------------------------------------
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.409 / Virus Database: 270.13.91/2363 - Release Date: 09/11/09 09:15:00

More information about the questions mailing list