[ntp:questions] Autokey users - please read

Todd Glassey tglassey at earthlink.net
Fri Sep 11 19:59:33 UTC 2009


David Mills wrote:
> Dave,
>
> 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...

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