[ntp:hackers] Protocol specification modification for MS-SNTP
mills at udel.edu
Tue Jul 7 20:38:05 UTC 2009
Thanks, but no thanks.
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
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.
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.
Andrew Bartlett wrote:
>On Tue, 2009-07-07 at 03:41 +0000, David Mills wrote:
>>Ah well, I was having a funky dream. The suggestion on digest algorithm
>I don't mean to step beyond my place, but perhaps can I assist you in
>some way to obtain a w32time client?
>It would seem some of these discussions are going in circles because the
>client in question isn't available to you. I'm also more than happy to
>help you set up a Samba4 DC, to show how MS-SNTP authentication works in
More information about the hackers