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

David Mills mills at udel.edu
Thu Jul 9 17:17:39 UTC 2009


It actually does no harm to reply to a symmetric active packet without 
mobilizing an association and in fact is consistent with the spec in the 
finest Jon Postel tradition. There needs to be no option to disable it.

The code now has a new restrict bit mssntp that enables MS-SNTP 
processing. It is compatible with Autokey and interleaved modes. I have 
tested it here with both while enabling mssntp with no ill effects 
without compiling the optional code.

Can you or Andrew send me a few grafs for the Authentication Options 
page? I can edit the other pages that need it.


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

More information about the hackers mailing list