[ntp:questions] Autokey users - please read
tglassey at earthlink.net
Fri Sep 11 19:59:33 UTC 2009
David Mills wrote:
> Better do this quickly, cleanly and with minimum wiggle room. Otherwise,
> somebody who doesn't know anything will call it a security flaw, call
> the CERT and create an Incident.
You mean like 2009-USCERTv33I7IQA...
> This has happened before when somebody
> claimed a stack vulnerability which in fact was true in a most unlikely
> case. Although the reporter submitted a script allegedly proving this
> could occur, the script was defective and nobody was able to verify it.
> I'd like this not to happen again.
> My point being, fix the bug, put in a conditional to temporarily revert
> to past behavior and leave it be.
> 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?
>> 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
>> 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.
>> Dave Hart
>> Dave Hart
>> questions mailing list
>> questions at lists.ntp.org
> questions mailing list
> questions at lists.ntp.org
> 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