[ntp:hackers] Protocol specification modification for MS-SNTP
martin.burnicki at meinberg.de
Thu Jul 9 07:55:39 UTC 2009
Dave Hart wrote:
> On Tue, Jul 7, 2009 at 8:38 PM, David Mills wrote:
> > I did a bit of poking and prying with the following results:
> > 1. Autokey and MS-SNTP now can run in a noninterfering manner on the
> > same server.
> > 2. A symetric passive packet is now returned in response to a symmetric
> > active packet in the same manner and with the same access monitoring as
> > in client/server mode. The WINTIME ifdef has been removed. The behavior
> > conforms with the spec and the security hole has been plugged.
Dave, thanks for the changes.
> With Harlan's help I've verified ntpd 4.2.5p186 compiled without
> #define WINTIME/--enable-wintime works for the "Internet Time" GUI in
> Windows XP. http://davehart.net/ntp/win/x86/ has p186 binaries for
> Windows for anyone else interested.
I've just tried to build with default configuration under Linux, and as
expected clients get replies to unauthenticated peer requests, just as with
> > 3. I did a small amount of rearranging so that the MS_SNTP code
> > completely disappears as does the Autokey code if not compiled.
> > The zero digest issue is no so much an unlikely hazard as an opportunity
> > for a terrorist to flood the sign daemon. This is not an idle threat; in
> > the PTTI paper we reported an incident where a perp tried to flood a
> > NIST server for a few seconds as fast as it could. In the current
> > design, such attacks are deflated by the rate controls and the sign
> > daemon would never see the flood.
> > However, there might be cases where an operator needs to enable MS-SNTP
> > clients for some networks and disable for others. A useful approach to
> > this problem is to use a restrict bit in the way that the KoD is
> > controlled. Unless the kod bit is enabled in the access word, it will
> > not be sent. I propose to do the same thing with a msntp bit, should
> > that be the consensus. I know I would like to do that if we ran this
> > stuff at Delaware.
> A restrict bit that defaults to off (meaning do not reply to
> unexpected symmetric packets) is a lot better than recompiling ntpd
> from source. Thank you for eliminating the build-time
> conditionalization of the symmetric client workaround. If maintaining
> historic ntpd behavior of replying by default is important, the
> restrict bit could be defined to mean do not reply if the bit is set,
> so those upgrading from 4.2.4 to 4.2.5/4.2.6 would not need to change
> their restrict configuration to continue responding to unconfigured
> symmetric traffic (including w32time clients).
I'm voting to enable this by default. At least the replies to peer packets
which have already been enabled in earlier stable versions.
Maybe support for MS style auth can be restricted to be off by default since
this has not been available in earlier stable versions and thus users can not
expect a certain default behaviour known from earlier versions.On the other
hand, I'd vote to enable this also by default since it obviously does not
cause any harm.
Finally, the obsolete configuration options (--enable-wintime for now) should
be removed from the autoconf stuff.
More information about the hackers