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

David L. Mills mills at udel.edu
Sun Apr 6 17:17:48 UTC 2008


Danny,

I'm baffled by your comments. The current NTPv4 spec says nothing about 
Autokey and makes no interpretation about the type field. The parser can 
and does step through the extension fields without knowing anything 
about the contents in order to find the MAC. The MAC can't be in an 
extension field without violating backwards compatibility with 
symmetric-key NTPv3 and NTPv4.

The current extension field design evolved from 1996 and was first 
formally proposed in 2000. It has been through two Autokey versions, 
both with the same extension field format. The point being that it is a 
little late to change it. The further point being that, without breaking 
backwards compatibility, it is easy to add new tenants of the extension 
fields. Break the version field into class/version nibbles. This 
requires no change to the existing Autokey implmentation, as it ignores 
other than class 0, version 2..

Dave

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



More information about the hackers mailing list