[ntp:hackers] MS-SNTP

David L. Mills mills at udel.edu
Sat Mar 29 17:48:03 UTC 2008


Andrew,

The problem is a stateless server used by clients including Microsoft 
and non-Microsoft key management. The only information available to 
distinguish between the various flavors is the NTP packet itself, in 
particular the key ID. The current MS-SNTP design with, as I have been 
told is hashed RID, completely takes over the key ID space, so would 
preclude operation with non-Microsoft clients. This may well be the 
explicit intent of the design, but it does preclude interoperation with 
national standards laboratories and the existing symmetric key 
infrastructure.

I did a bit of checking and found the MS-SNTP client message with empty 
digest does not work with either NTPv3 or NTPv4 reference 
implementations. A whisker-close reading of the v3 and v4 specs does not 
prohibit an empty digest, but either implementation would treat that as 
an authentication failure. In fact, provisions for this are not hard to 
do, but the NTPv4 spec would have to say exactly how to deal with it.

This is quickly becoming a failed mission. If Microsoft insists on 
propagating MS-SNTP, they should provide their own infrastructure 
independent of the existing NTP infrastructure. I would very much like 
to see the existing key management system overhauled as proposed, but 
only if it can be configured to support the present model based on local 
files. I would expect the server to support authenticated MS-SNTP 
clients or current clients, but not both in the same machine. It also 
means a MS-SNTP server or client cannot be an authenticated client of a 
standards laboratory in the US or Canada and very likely other countries.

Dave

Andrew Bartlett wrote:

> On Fri, 2008-03-28 at 18:03 +0000, David L. Mills wrote:
>
>> Andrew,
>>
>> I have no idea why MS-SNTP assumes little-endian. All past and present
>> IETF protocols assume network byte order, which is big-endian. I find it
>> highly surprising that the authors of the MS-SNTP spec apparently did
>> not know that. The timestamps and other data in the NTP header,
>> including the key ID and message digest, are in big-endian order.
>
>
> Microsoft does this. Often... Welcome to my nightmare :-)
>
>> If as presumed the RIDs are small numbers, they would appear in the high
>> order bit positions of the NTP key ID and break any possibility for
>> coexisence with Autokey. It would not be possible for an NTP server to
>> distinguish between MS-SNTP and Autokey and a server could not do both.
>> If the endian was corrected and the RIDs or hashes of them could be
>> limitied to 16 low-opder bits, coexistence is possible and practical.
>>
>> The Autokey module was carefully crafted to be replaceable by another
>> module with different functions, so in principle MS-SNTP coult be
>> supported without gross invasion of the existing code. However, if these
>> functions did not include the existing symmetric key ID and keys file,
>> the modified server would be useful only to Microsoft clients and could
>> not serve as an authenticated client of existing NTP servers.
>
>
> If that is the cost, it's fine by me. But surely the server could tell
> when it is being a server and when it is being a client?
>
> Andrew Bartlett




More information about the hackers mailing list