[ntpwg] Stronger symmetric NTP authentication

[David L. Mills]

Danny,

I repeat. Whatever is in OpenSSL, specifically the NID for each 
algorithm, is transparent and NTP could in principle support any of them.

Dave
Danny Mayer wrote:

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