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 _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
