[ntpwg] [ntp:hackers] MS-SNTP

[David L. Mills]

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.

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.

Still anothere consideration is that both Canadian and NIST servers now 
support NTP symmetric key cryptography. It would be highly ironic if 
MS-SNTP clients could not use those servers.

Dave

Andrew Bartlett wrote:

> On Fri, 2008-03-28 at 03:55 +0000, David L. Mills wrote:
>
>> Andrew,
>>
>> Yes, the key select is clever. The orignal NTP design anticipated
>> password/key ID change by providing possibly several keys with
>> respective key IDs. The client uses the active key ID until the server
>> switches to another now active key ID. The client notices this and
>> switches to that key ID.
>>
>> You bring up a most interesting point. My fear is a violent trainwreck
>> between the Autokey key space and what I have been told the MS-SNTP key
>> space. Because on Autokey pseudo-random key generation and hash chains,
>> shrinking the key ID space much would create crippling collisions. On
>> the other hand, I understand the RID space is in the order of 500
>
>
> Values would start at 500, and increase to around the number of users
> and computers in your domain/organisation.
>
>> , which
>> is far below the symmetric key pivot of 65535. If the MS-SNTP key ID
>> space could fit below the pivot, that problem would disappear
>> completely. On the other hand, MS-SNTP key space might work if the pivot
>> point were increased from 2^16 to 2^18.
>
>
> Remember that the high bit may or may not be set, and it is in little
> endian. This would seem to preclude any use of a pivot.
>
> What endian does the standard signing mech expect?
>
>> Here's a really serious showstopper. Is the gang sweating the runup to
>> the last call willing to wait while we shake out these issues? Assuming
>> this can be done relatively quickly, I would advise it be so. Here are a
>> couple of things that might make it easier.
>>
>> 1. Change the spec to allow the client to opt-out of the requirement to
>> construct a MAC. That would be indicated if the client message digest
>> was all zeros. This is a no-brainer and should have been anticipated.
>> This can be done in the current reference implemenation with two lines
>> of code.
>>
>> 2. Resolve whether to activate my suggestion of optional 32/64-bit key
>> IDs. WATCH OUT: We now do have the option of incorporating 160-bit
>> message digests (SHA_x). Activating 64-bit key IDs prohibits that
>> option. If we choose to reject 64-bit key IDs and embrace the 160-bit
>> option, that should be so stated in the spec.
>>
>> 3. Resolve the issues on how MS-SNTP and Autokey can cohabit the same
>> carcass; however, this must be done without requiring the server to
>> retain state.
>
>
> Perhaps I'm missing something, but surely if the client has set an
> all-zero checksum, then it's key ID is a MS-SNTP key, while if it has
> specified a checksum, then things fall back to whatever the RFC process
> specifies.
>
> If not, could this be done outside the standards space, on the basis
> that servers wishing to participate in both Microsoft's bastard signing
> scheme - useful *only* on an AD-like domain controller - and proper,
> internet standard NTP signing would be mutually exclusive?
>
> In any case, perhaps we are taking the wrong approach here. I think we
> need to validate actual, not spec, behaviours, and ensure that
> assumptions we are making are real. I think this might all make more
> sense with a patch, and I'll try and work on that soon.
>
> Andrew Bartlett
>