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

Fri Apr 4 03:42:36 UTC 2008

Greg,

The minimum extension field used by Autokey is two words now. The 
serious design intent is that extension fields are used only at startup 
or when something changes. Normally they are not used all and only the 
MAC appears.

It does not seem likely that anything beyond a 160-bit hash will become 
common anytime soon. It is important to observe that, even if a hash 
collision can be found relatively quickly, the likelihood that the 
result wouls be a valid NTP packet is vanishingly small. Frankly, I 
don't see a needto go beyond MD5.

The MAX_MAC_LEN has changed once since it was born circa 1984. This was 
when MD5 overtook DES as the only practical ITAR alternative. It might 
change should SHA-x come into practice and that's why the prvisions are 
there.

Dave

Greg Dowd wrote:

> On the issue of the minimum extension field, why shouldn't we leave the
> minimum at 16 octets? The MAX_MAC_LEN has been changing over time
> anyway. I didn't even realize it had been bumped to 6 for the SHA-1
> mac. Your suggestion would mean that no future hashing scheme could be
> concurrently supported. Leaving the definition the way it is currently
> written will leave a little room for the next digest protocol without
> immediately bumping into the minimum extension.
>
> On the extension field header, my hindsight says that we should
> allocated a type value of 1 (ONE) for Autokey v1, a value of 2 (TWO) for
> Autokey v2 and we would still have 65,533 entries left. Do you have any
> thoughts on how we can make some room available for other protocols
> (e.g., things like negotiating MS-NTP on symmetric link) in the future
> and remain backwards compatible?
>
> BTW, I like the idea of being able to offer multiple crypto options (a
> la SSL families) and letting the client choose the type. I understand
> that further system engineering may be required to understand the
> convolutions of the trust envelope under different scenarios.
>
>
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc.
> www.symmetricom.com
> "Everything should be made as simple as possible, but no simpler" Albert
> Einstein
>
> -----Original Message-----
> From: hackers-bounces+gdowd=symmetricom.com at lists.ntp.org
> [mailto:hackers-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf
> Of David L. Mills
> Sent: Thursday, April 03, 2008 4:48 PM
> To: ntpwg at lists.ntp.isc.org; hackers at ntp.org
> Subject: Re: [ntp:hackers] Handling authentication extensions (was
> MS-SNTP)
>
> 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

Greg Dowd wrote:

> On the issue of the minimum extension field, why shouldn't we leave the
> minimum at 16 octets? The MAX_MAC_LEN has been changing over time
> anyway. I didn't even realize it had been bumped to 6 for the SHA-1
> mac. Your suggestion would mean that no future hashing scheme could be
> concurrently supported. Leaving the definition the way it is currently
> written will leave a little room for the next digest protocol without
> immediately bumping into the minimum extension.
>
> On the extension field header, my hindsight says that we should
> allocated a type value of 1 (ONE) for Autokey v1, a value of 2 (TWO) for
> Autokey v2 and we would still have 65,533 entries left. Do you have any
> thoughts on how we can make some room available for other protocols
> (e.g., things like negotiating MS-NTP on symmetric link) in the future
> and remain backwards compatible?
>
> BTW, I like the idea of being able to offer multiple crypto options (a
> la SSL families) and letting the client choose the type. I understand
> that further system engineering may be required to understand the
> convolutions of the trust envelope under different scenarios.
>
>
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc.
> www.symmetricom.com
> "Everything should be made as simple as possible, but no simpler" Albert
> Einstein
>
> -----Original Message-----
> From: hackers-bounces+gdowd=symmetricom.com at lists.ntp.org
> [mailto:hackers-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf
> Of David L. Mills
> Sent: Thursday, April 03, 2008 4:48 PM
> To: ntpwg at lists.ntp.isc.org; hackers at ntp.org
> Subject: Re: [ntp:hackers] Handling authentication extensions (was
> MS-SNTP)
>
> 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