Re: [ntp:questions] Autokey users - please read
On Sep 10, 12:23 am, Harlan Stenn wrote: > https://support.ntp.org/bugs/show_bug.cgi?id=1243talks about a bug that > affects autokey users. > > We have a fix ready to go. > > There are 2 ways to go, however. > > One way is to just fix the problem, which will mean an "old" version of > ntpd will not authenticate with a "new" version of ntpd. > > The other way is to provide a backward-compatibility mode, and there > would be a switch in the config file that would say whether or not the > backward-compatible mechanism should be enabled or not. This has been resolved in 4.2.5p212. By default, that version and later will not interoperate with earlier ntpd's Autokey. ./configure --disable-bug1243-fix can be used before make to build a newer ntpd that has the older Autokey session key behavior and so will interoperate with pre-p212 Autokey, but not with default-configured newer ntpd Autokey. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Autokey users - please read
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@lists.ntp.org >> https://lists.ntp.org/mailman/listinfo/questions >> >> >> > > ___ > questions mailing list > questions@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 > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Autokey users - please read
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@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 > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Autokey users - please read
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? > > Please don't take the Microsoft route, where praying to the altar of > backwards compatibility means you are stuck with ugly hacks for > decades. That might make sense for MSFT and its customers, but I don't > think it makes sense here. The experts in this forum routinely advise > questioners "that's too old, upgrade to a newer release"; this > situation should prove no different. > If you 'fix' NTP like this it will be removed from the MANDATORY SW components of a number of standards because it will break the operations of existing systems. Todd Glassey > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.409 / Virus Database: 270.13.90/2361 - Release Date: 09/10/09 > 18:12:00 > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Autokey users - please read
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. 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@lists.ntp.org >https://lists.ntp.org/mailman/listinfo/questions > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Autokey users - please read
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
Re: [ntp:questions] Autokey users - please read
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? Please don't take the Microsoft route, where praying to the altar of backwards compatibility means you are stuck with ugly hacks for decades. That might make sense for MSFT and its customers, but I don't think it makes sense here. The experts in this forum routinely advise questioners "that's too old, upgrade to a newer release"; this situation should prove no different. -- RPM ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Autokey users - please read
Harlan, Folks should understand this is a rather trivial fix to make sure autokeys are no shortened when a null byte is generated at random. The bug has been present since 1993. Thus, "old" version will interoperate as will "new" versions, but old and new will not. I would like to simplify these things as much as possible. I am not interested in supporting both old and new at the same time and not interested in supporting on a per-associatino basis. The changes I suggested could easily be implemented as an option on the crypto command. There would be only one place to back out in the session_key() routine; the other changes in fact fix another bug in ntp_config.c. Dave Harlan Stenn wrote: >https://support.ntp.org/bugs/show_bug.cgi?id=1243 talks about a bug that >affects autokey users. > >We have a fix ready to go. > >There are 2 ways to go, however. > >One way is to just fix the problem, which will mean an "old" version of >ntpd will not authenticate with a "new" version of ntpd. > >The other way is to provide a backward-compatibility mode, and there >would be a switch in the config file that would say whether or not the >backward-compatible mechanism should be enabled or not. > >Does anybody *know* that: > >- they are actively using autokey >- they would have difficulty updating all of their autokey-using hosts > at the same time >- and therefore they would appreciate our implementing the backward- > compatibility fix > > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Autokey users - please read
https://support.ntp.org/bugs/show_bug.cgi?id=1243 talks about a bug that affects autokey users. We have a fix ready to go. There are 2 ways to go, however. One way is to just fix the problem, which will mean an "old" version of ntpd will not authenticate with a "new" version of ntpd. The other way is to provide a backward-compatibility mode, and there would be a switch in the config file that would say whether or not the backward-compatible mechanism should be enabled or not. Does anybody *know* that: - they are actively using autokey - they would have difficulty updating all of their autokey-using hosts at the same time - and therefore they would appreciate our implementing the backward- compatibility fix -- Harlan Stenn http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
