[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.

Todd
>
> 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