[ntpwg] [ntp:hackers] Handling authentication extensions (wasMS-SNTP)
Greg Dowd
GDowd at symmetricom.com
Fri Apr 4 16:37:57 UTC 2008
Now I see. We need to change the minimum extension field length
definition in order to be compatible with the currently shipping version
of Autokey. I agree with that wholeheartedly. That was probably all
you had to say. Making it smaller based on the opinion that the there
will never be another hash algorithm update was a much weaker argument.
Let me ask my other question in another way. Do you support any other
usage of the extensions field in ntp than Autokey for interoperable
implementations? Are you willing to consider any changes whatsoever to
support alternative uses of the extension mechanism? While the
definition, going way back to the s/time days, has always defined the
extensions as generic tlv's, the way they are used currently, as well as
the way you talk about when/why/how extensions are sent, are much more
Autokey specific than extensions specific but you don't differentiate.
The main reason for the question is the rapidly closing window for the
ntpv4 protocol doc. While the Autokey doc describes the autokey
protocol, the ntpv4 doc describes the generic tlv mechanism. If we are
to have any hope of using extensions to extend the protocol further for
security, association, performance monitoring, etc., now is the time to
structure the type field definition to support that.
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: 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, April 03, 2008 8:43 PM
To: NTP Working Group
Subject: Re: [ntpwg] [ntp:hackers] Handling authentication extensions
(wasMS-SNTP)
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
_______________________________________________
ntpwg mailing list
ntpwg at lists.ntp.org
https://lists.ntp.org/mailman/listinfo/ntpwg
More information about the ntpwg
mailing list