[ntpwg] [ntp:hackers] MS-SNTP

[Andrew Bartlett]

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

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ntp.org/pipermail/ntpwg/attachments/20080327/aa47feea/attachment.bin