[ntpwg] Stronger symmetric NTP authentication

[David L. Mills]

Danny,

I don't understand your objection. There already is a different NID for 
each algorithm and a matching ASCII string defined in the OpenSSL 
library. In the scheme I proposed the operator selects NIDs for 16-octet 
or 20-octet digests or both. Normally the client would select one 
16-octet MD5 and one 20-octet SHA or whatever as defaults. The server 
would select either based on the client request digest size and reply 
with the same NID. This is the same paradigm as selecting the version 
number when replying to a client request.

The scheme I suggested is a natural extension, providing multiple NIDs 
when more than one NID for each digest size is available. Most operators 
not care to use it, but it would support a more complicated setup should 
some diversity remain in the digest proponent community.

Dave

Danny Mayer wrote:

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