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

[David L. Mills]

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
>