[ntpwg] Stronger symmetric NTP authentication

[Danny Mayer]

David L. Mills wrote:
> 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.
> 

What I mean is that the ID's need to be specific algorithm identifiers,
that's all. SHA-1 comes in different flavors and strengths, for example.
The protocol just needs to understand what the specific algorithm is. I
have no problem with the rest.

Danny

> 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
>>>    
>>>
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg
> 
>