[ntp:hackers] MS-SNTP

David L. Mills mills at udel.edu
Thu Mar 27 18:50:46 UTC 2008


Andrew,

Gawd, I have enough trouble with the IETF to go boil in some other 
standards ocean.

Somewhen on the bugs list I was told th key ID would be a hash of the 
RID with possibly the top bit stolen for the key selector. The key 
selector is used to select which of two preloaded keys to use and s 
small state machine used to remember the last selected by the server.

The authentication methods have been specified in all RFCs beginning 
with rfc 1305, but the actual protocol has not. Only in the NTPv4 spec 
has the protocol been specified, including the requirement that the 
client produce a message digest. The simple way forward without messing 
up Microsoft or for that matter any other SNTP client that might not 
expect to provide a MAC, is to make it optional. If the client does not 
provide a MAC, set the digest field to zero.

The other issue is how to farm the key ID space. If there is a drop in 
crypto library for both the existing key management and some other, 
selection of which one, and the key ID farm, could be based on 32/64-bit 
key ID and/or NTP version.

Dave

Andrew Bartlett wrote:

> On Thu, 2008-03-27 at 00:36 +0000, David L. Mills wrote:
>
>> Guys,
>>
>> I'm sending this to both hackers and the WG, but maybe it should go to
>> only one. Your preferences would be cherished.
>>
>> There has been a lot of discussion on NTP bugs about MS-SNTP,
>> Microsoft's extension to NTP for symmetric key cryptography, as well as
>> a generic model to rethink the reference implemention key management
>> services. I took a look at the MS_SNTP spec, which is even more dreary
>> than an IETF spec,
>
>
> BTW, if you want to force Microsoft to improve their spec, you can
> either make comment in their forums
> (http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=573&SiteID=1, 
> or you can join the Protocol Freedom Information Foundation 
> (www.protocolfreedom.org), and use the PFIF's contact with MS and it's 
> formal, enforceable, 'clarification request' process.
>
>> and came up with the following observations:
>>
>> 1. The intent in the NTPv4 specification is to use the NTPv3 defined
>> cryptographic provisions, but substitute MD5 for DES-CBC. The NTPv4 spec
>> explicitly calls out the protocol processing steps for both the server
>> and client. If an SNTP client implements authentication in some form, it
>> must be compatible with NTPv4.
>>
>> 2. The NTPv4 spec requires the client to generate the MAC, which the
>> server checks. This is consistent with symmetric modes and and makes a
>> cleaner spec. The MS-SNTP spec requires the client to supply only the
>> key ID and not to provide the MAC. An MS-SNTP client would provoke a
>> CRYPTO-NAK from an NTPv4 server and interpret this as an authentication
>> failure. It would be simple to add an enable/disable flag to require/not
>> require the client to generate a MAC. If not required, MS-SNTP clients
>> could use NTPv4 servers.
>>
>> 3. Another problem is that MS-SNTP and NTPv4 interpret the key ID field
>> in quite different ways. MS-SNTP constructs the key ID from a one-bit
>> key selector concatenated with a 31-bit private value based on domain
>> and machine identifiers. In general, this exhausts the key ID space.
>> However, Autokey uses a pivot point of 65535 and below for symetric keys
>> and above for public key IDs. Autokey generates pseudo-random key ID
>> streams by MD5 hashes including key IDs where the streams have no
>> collisions and hashes always greater than the pivot. Thus, the collision
>> probability is close to 2^32 - 2^16, which is negligible.
>
>
> I'm a bit unclear on this - I would expect that most (but not all) RIDs
> used by Microsoft clients would be in the range 0-65535, as they are
> generally allocated from a base of 500.
>
>> 4. It could be, as previously suggested, to provide a different pivot
>> point or another pivot point that would support some combination of
>> symmetric key, MS-SNTP key and Autokey, but the problem is that would
>> make the hash collisions much more frequent and still not provide
>> sufficient floor space for the MS-SNTP key ID.
>
>
> I never quite expected that deployments would enable both authentication
> mechanisms at once, but this seems like a reasonable way forward.
>
> Andrew Bartlett
>



More information about the hackers mailing list