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

David Mills mills at udel.edu
Thu Jul 9 12:14:16 UTC 2009


I might not have been clear. The resonse to a symmetric active request 
is unconditionally a symmetric pasive packet. If authentirated, an 
association is mobilized. There is no way a symmetric active peer can 
tell if an association has been mobilized or not. This is all consistent 
with the spec and no enable bit is necessary.

I continue to be uncomfortable with an agenda that says compile the code 
whether or not it might be used. Is there some way you can tell from the 
environment that Samba is active? Thie Autokey code is compiled only if 
OpenSSL is present by default. This puppy is getting downright huge and 
needs to be potty trained.


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