[ntp:hackers] Protocol specification modification for MS-SNTP

Martin Burnicki 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 
earlier versions.

> > 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.



Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the hackers mailing list