Future directions

Hal Murray hmurray at megapathdsl.net
Sun Sep 15 03:54:10 UTC 2019


-* We intend to fully support Network Time Security and to be first or
-  second interop on that standard once it is finalized.  At that
-  point, older insecure authentication methods (MAC and MS-SNTP) may
-  be removed.
+* Now that we have full Network Time Security, a neasr-future
+  direction is to remove older insecure authentication methods (MAC
+  and MS-SNTP).

The old MAC mode in not insecure.  It's inconvenient to setup on a large scale 
since it requires manual intervention on the server for each new client.  It's 
a kludge since it doesn't use an extension.  But it's not insecure.

NIST supports it.

>From a code standpoint, it's not that ugly.  I think it should stay.


The MS-SNTP stuff is needed as a bridge to MS Active Directory.  I know next 
to nothing about MS.

It is a kludge in the sense that it calls out using TCP with associated waits 
that breaks the fundamental never-wait assumption of ntpd.  That's OK on a 
lightly loaded system.

I won't complain (much) if you remove it, but you will be cutting yourself off 
from some (potential?) MS users.  It's tangled up with Samba which I don't use.

from ntpd/ntp_signd.c
 * Dependency on NTP packet structure removed by ESR.
 * This code now only knows about the length of an NTP packet header,
 * not its content. Note that the signing technique never handled anything
 * but unextended and MACless packet headers, so it can't be used with NTS.

Using it with MAC or NTS doesn't make sense.  The MS end doesn't know about 
either.  The whole point of the MS-SNTP stuff is to support a type of 
authentication that MS does understand.

Has anybody tried using it with our code?  I wonder if it still works.


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list