[ntpwg] [ntp:hackers] Handling authentication extensions (was MS-SNTP)

[Brian Utterback]

Absolutely. This has been brought up numerous times before, but there 
was never a compelling reason to go back and change it. This has been 
due to a chicken and egg problem; there were no proposed extensions that 
did not require a MAC such that it made a change necessary, but this was 
usually because such proposed extensions were abandoned when the 
limitation was discovered.

Now is what could be our last chance to get this rationalized. Dave is 
willing to make the change, and if we don't do it now, we probably can 
never do it.

Danny Mayer wrote:
> Dave,
>
> The problem with all this is that extensions are not being set up 
> properly. The extension type field should tell you what type of 
> information is in the extension and the length should tell you how long 
> it is. There should be no other information in the extension type field.
> All other information is private to the extension and should be 
> incorporated into the body of the extension itself, including versioning 
> information. The MAC itself should be an extension field with a value in 
> the extension type field to identify it as a MAC extension. All this is 
> straightforward to do and does not require you to guess about the 
> extensions and the MAC. This is why the NTPv4 spec does not discuss 
> autokey, just how to specify and extension field to the NTP packet. The 
> autokey protocol should discuss the extension itself and the contents of 
> the extension and only specify one value to appear in the extension type 
> field.
>
> We are making it much harder than needed to make the NTP extensions 
> practical and it's not as if the packets are large even with extensions. 
> Even more than that it makes it easy to identify an extension and what 
> to do with it and makes it modular.
>
> If this breaks the current autokey extension layout, I'm sure we can 
> come up with something to allow migration with to above scheme possible.
>
> Danny
>
> David L. Mills wrote:
>   
>> Danny,
>>
>> I reviewed the secton on extension fields and found a wee error. The 
>> minimum extension field length is two words (8 octets), not four words, 
>> as it says in the spec. The reason for this is how the overall packet is 
>> parsed for backward compatibility. Right now the only customer with 
>> extension fields is Autokey, so a packet with extension fields always 
>> carries a MAC. The parser needs to know whether the next field is a MAC 
>> or an extension field. It goes like this:
>>
>> 1 word: crypto-NAK (no digest)
>> 3 words: DES-CBC MAC (64-bit digest)
>> 5 words: MD5 MAC (128-bit digest)
>> 6 words: SHA MAC (160-bit digest)
>> 2, 4 words: runt packet - format error
>> 7 words or more: eat the extension field, then go around again
>>
>> The crypto-NAK and DES-CBC don't ordinarily involve extension fields. 
>> So, the minimum extension field length is two words to avoid mixing up a 
>> MD5 MAC with a one-word extension field and a SHA MAC.
>>
>> RIght now the presence of some kind of authentication scheme is 
>> signalled by the presence of a MAC. If no such scheme were intended, the 
>> parser would find no words ramining after the parse and that works. 
>> However, to avoid confusion, the extension field could not have length 
>> matching the length of one of the MACs.
>>
>> Moving on, the coding of the extension field hearder is rather loose; 
>> the version number field could be split in two 4-bit nibbles 
>> type/version, for instance. In hindsight I should habe interchanged the 
>> version and opcode octets so the type/version octet comes first in true 
>> Internet spirit. However, I agree in the classic Internet spirit that, 
>> if an application doesn't understand the type/version/opcode, it ignores 
>> the field.
>>
>> I'm a little uneasy about a design that could include more than one 
>> scheme (Autokey/MS-SNTP?) in the packet and letting the server pick one 
>> or the other. There is something called a cryptotype defined in the 
>> current authentication options page which carefully calls out what 
>> combinations of options represent acceptable/good practice.
>>
>> For instance, a non-authenticated client can chime an authentcated 
>> server, but not the other way around. A IFF server in one secure group 
>> can be a client of a GQ server in another secure group and so on. I 
>> suppose the cryptotype table in the doucmentation could be augmented to 
>> handle cross-schemes between different orthodoxy's like NTP and MS-SNTP, 
>> but the mind boggles.
>>
>> Dave
>>
>> Danny Mayer wrote:
>>
>>     
>>> Dave,
>>>
>>> I'd like to make the following addition to the NTPv4 spec (and yes I 
>>> know it's late) but this is important in processing authentication. 
>>> I'm doing this for the case where there is more than one 
>>> authentication extension header.
>>>
>>> Proposed addition text:
>>>
>>> "When processing extensions to the NTP packet involving authentication 
>>> the ntp server and client MUST process them in the order listed in the 
>>> packet. If the authentication type, as defined in the field type of 
>>> the extension, is not recognized or supported its content is discarded 
>>> and the application moves on to the next authentication type until it 
>>> finds one that it does support. All subsequent authentication 
>>> extension types are then discarded. If no authentication type is found 
>>> the application proceeds based upon the policy of that server instance."
>>>
>>> The goal here is to allow a client to send multiple possible 
>>> authentication types (in order of preference) and the server will 
>>> choose the first one it finds that it supports.
>>>
>>> Does this all make sense?
>>>
>>> Danny
>>>
>>> David L. Mills wrote:
>>>
>>>       
>>>> Andrew,
>>>>
>>>> I hear you and don't want to leave Microsoft out in any case. As it 
>>>> stands, the MS-SNTP key ID scheme is incompatible with ordinary NTP 
>>>> users and the national laboratories. But, you have given me an idea.
>>>>
>>>> You say Samba is to simulate an AD controller, which means it would 
>>>> be a MS-SNTP server for that domain. I wouldn't thnk the Samba AD 
>>>> would ordinarily be a MS-SNTP client of another MS-SNTP server in 
>>>> that domaing, but that might happen. On the other hand, the Samba 4 
>>>> machine would very likely be a client of other NTP server(s). This is 
>>>> the case I am worried about. An even more perplexing case is when the 
>>>> Samba machine is a server for both NTP and MS-SNTP clients.
>>>>
>>>> For grins, I propose a configuration command to set the default 
>>>> server key ID scheme (ntp/mssntp/...) plus an association 
>>>> configuration option to set the default client key ID scheme. 
>>>> Exceptions can be handled by the restrict mechanism by using the 
>>>> restrict bits to override the default server scheme. I assume an AD 
>>>> will not have addresses scattered all over the place and relatively 
>>>> few address/mask pairs would be necessary. If on the other hand only 
>>>> a few NTP clients are used, the mask can apply to them.
>>>>
>>>> Does this work?
>>>>
>>>> Dave
>>>>         
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers
>