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

Dave Hart davehart at gmail.com
Thu Jul 9 06:11:54 UTC 2009


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.

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.

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

Cheers,
Dave Hart


More information about the hackers mailing list