[ntpwg] Stronger symmetric NTP authentication

[Greg Dowd]

I'm not quite following this proposal. If the client gets to choose an
algorithm to associate with a particular digest size, how would the
server know which one was chosen.  The example of version is an invalid
case as version is transferred in the frame.  Where would NID be
transferred?  Also, is NID proprietary to OpenSSL?  If it human readable
for config file usage?  If these are issues, wouldn't we rather select
by ISO OID?  Not that I'm saying that is legible.

-----Original Message-----
From: ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org
[mailto:ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf Of
David L. Mills
Sent: Thursday, December 11, 2008 5:39 AM
To: ntpwg at lists.ntp.org
Subject: Re: [ntpwg] Stronger symmetric NTP authentication

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

_______________________________________________
ntpwg mailing list
ntpwg at lists.ntp.org
https://lists.ntp.org/mailman/listinfo/ntpwg