[ntpwg] [ntp:hackers] MS-SNTP

[TS Glassey]

Dave
after your nasty response I decided to send a thank's note to you personally 
and then respond to the list. Try not to get too upset but your responses 
here sound like a whiney 3 year old.

More retort's below...

----- Original Message ----- 
From: "David L. Mills" <mills at udel.edu>
To: <ntpwg at lists.ntp.isc.org>; <hackers at ntp.org>
Sent: Saturday, March 29, 2008 10:48 AM
Subject: Re: [ntpwg] [ntp:hackers] MS-SNTP


> Andrew,
>
> The problem is a stateless server used by clients including Microsoft
> and non-Microsoft key management.

Yes but what is the problem with that? - David  as you said it (SNTP) was 
intented for sychronization of end-node devices or devices where there was 
no need for the type of logging or data capture models that NTP supports. 
But because that was your original intent, doesnt mean that other's cannot 
use it in the form's that Microsoft has.

If Microsoft wants to use a NTP formatted packet specification to move data 
and that interface meets the SNTP interface requirement's per the portions 
of the spec that say "This all must be implemented to meet the NTP or SNTP 
interface specifications", then they can do that - and David - that is the 
fault of that "License for Use" that you made NTP available under...

Oops -   guess you have to blame yourself for this fiasco.

> The only information available to
> distinguish between the various flavors is the NTP packet itself, in
> particular the key ID.

If Microsoft's implementation is intentionally constrained so that it works 
differently than your "best case" model, then that is their choice. The NTP 
protocol and its license says nothing about how its to be used or how much 
of it must be implemented. by folks using it.

The fix for this is that NTPv4 should address (or perhaps the v5 release) 
should address the creation of a serious set of "practice's Interfaces" 
which support NTPv4 full, SNTPv4. That is

    1)     A set of minimum compliance interface requirement's and process 
steps for

                A)    Unauthenticated SNTP to NTP Setting Events
                B)    Unauthenticated NTP to NTP Setting and Peering Event's
                C)    Authenticated SNTP to NTP Setting Event's
                D)    Authenticated NTP to NTP Setting and Peering Event's
                E)    Payload Time-stamp generation ala Glassey/McNeil 
extension's

    2)    A set of basic characterization of NTP/IP performance metrics in 
loaded environment's. The Benchmarks to produce the loading to support this 
analysis are totally available.  This will create a benchmark itself for 
what Appliance Type and Computer Type NTP Services should produce in the 
form of number of setting's per second/minute and jitter/drift control's for 
those platforms.




> 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.

So what? - this means that we need to install the Meinberg NTP Service where 
we want to bridge across those time-synch models and practices. Let 
Microsoft do whatever they want...

> 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.

So what ???- it obviously wasnt important to Microsoft - why do you think 
that is by the way?

> 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.

Only if the full controls on the protocol are met. The fact that the 
Microsoft port doesnt meet those functionalities proves that this isnt 
necessary. All it does is breaks the NTP reference system, but is that a 
real problem in time-keeping?

> In fact, provisions for this are not hard to
> do, but the NTPv4 spec would have to say exactly how to deal with it.

No kidding - I have been saying this for years now - about how what the NTP 
process actually needs are real-world use models and practices but I was 
blow off the list for suggesting that this reality was in fact something 
interesting... That said, what NTP really needs is protocol definitions that 
are easilly implemented as a process. That is to say, a software 
specification for the protocol and its use practices and these MUST have a 
set of bassic performance characteristics.

>
> 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.


And they could do this easily if there was a good practice model


> 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
>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg