[ntpwg] Stronger symmetric NTP authentication

[Danny Mayer]

David L. Mills wrote:
> Brian,
> 
> The new interleaved modes aren't in the specification either. However, 
> servers and clients automatically back out of these modes if the server 
> or client is not equipped for them. So, the operation is completely 
> transparent. The current development version supporting these modes is 
> on all our public and private servers and clients. Yes, it is in the web 
> document collection and further described in the white paper on the NTP 
> Project Page.
> 
> A similar thing can be done for 20-octet digests. The original plan for 
> this was formulated several years ago. The parsing rules  provide for 
> 8-octet (DES), 16-octet (MD5) and 20-octet (SHA) digests. This does not 
> change the specification other than to require extension fields to have 
> a minimum of two 32-bit words with 16-octet digests. A simple extension 
> field test would even detect an extension field of only one word.
> 
> The parsing rules detect the digest as a function of the number of words 
> following the NTP payload including extension fields):
> 
> 0    none (no extension fields)
> 1   crypto-NAK
> 2   invalid
> 3   DES (no extension fields)
> 4   invalid
> 5   MD5 minimum extension field two words)
> 6   SHA (minimum extension field one word)
> 7 or more  extension field
> 
> For all extension fields now defined the minimum extension field length 
> is two words.

This won't work since each digest algorithm will give a different digest
output and you should not assume that the length is sufficient to tell
you the difference. You actually need different id's for each digest
algorithm.

Danny
> 
> The interoperability and configuration rules are proposed as follows:
> 
> A host is configured to support specified algorithms for both 16- and 
> 20-octet digests. This includes all algorithms supported by the OpenSSL 
> library with the expected defaults. A new configuration command
> 
> digest <NID> ...
> 
> Where NID is consistent with OpenSSL NIDs used in the crypto command. 
> There can be one NID or several in a circular list. The digest size is 
> implicit in the NID. The client and symmetric peer maintains a pointer 
> to the current NID. When a digest arrives, the first NID with matching 
> digest size is used for subsequent packets. In case of crypto NAK, the 
> next NID on the list is used, whether that be 16 or 20 octets. In 
> principle, the list could be populated with all OpenSSL digest NIDs and 
> a caller with any of them would clank around until a matching pair was 
> found.
> 
> Operation with a stateless server with lots of clients would be somewhat 
> messy with a mixture of clients using different NIDs. Normally there 
> would be one NID for 16-octet digests and another for 20-octet digests. 
> The server would select either depending on the client request and use 
> the same one for the server reply.
> 
> Note the digest size determines the size of the key material prepended 
> by the keyed-MD5 operation defined by the RFC. So far as I know, a 
> similar operation has not been defined for digests other than MD5, but 
> the extension is obvious.
> 
> Dave