[ntpwg] MS-SNTP

[David L. Mills]

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

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.

5. On close inspection it is possible to increase the key ID from 32 to 
64 bits and still keep the extension field parser happy. It is even not 
too hard to have this be transparent to all except the library that 
handles the key management. Presumably, that library could use the two 
words in any way they wish and in principle the selection of each 
library could be on an association specific basis.

6. The only requirement, if more than one cryptographic library is 
involved, there has to be a way to determine which one. Presumably, if 
32-bit key IDs are used, the default is the current interpretation. If 
64-bit key IDs are used, at least some of the bits must be used to 
determine which one. This is most important fot a stateless server which 
has no clue other than the arriving packet.

7. A couple of suggestions on the library interface have been floated on 
the bugs list. If serious, they should be floated here. However, one of 
the things not evident in the suggestions is that some keys have a 
defined lifetime and must be automatically deleted when the lifetime has 
expired. What this seems to mean is a call, once per second or once per 
minute, to a library function.

Dave



3.

3.