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

[David L. Mills]

Greg,

I have tried to be flexible and accomitative in the venture and and am 
willing to change the rules. Do you have a conflict with that? Say your 
proposals.

Dave


Greg Dowd wrote:

> That's an interesting concept but not consistent with either the code
> (ntp_proto.c), the protocol draft (section 7.5) or your book (Section
> 9.3). The definition of the extensions has always included the caveat
> that a MAC is required if extensions are present. The overhead of
> calculating a MAC on a modern processor (even an embedded one) is not
> that onerous. Why change the definition now? Do you see a need for
> future extensions that could not support a MAC. If you think we should
> change the definition, we would also need to update the general section.
> I've included the ntpv4 protocol draft definition for your review.
>
> 7.5. NTP Extension Field Format
>
> In NTPv4 one or more extension fields can be inserted after the
> header and before the MAC, which is always present when an extension
> field is present. Other than defining the field format, this
> document makes no use of the field contents. An extension field
> contains a request or response message in the format shown in
> Figure 14.
>
>
>
> 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: Friday, April 04, 2008 12:06 PM
> To: NTP Working Group
> Subject: Re: [ntpwg] [ntp:hackers] Handling authentication
> extensions(wasMS-SNTP)
>
> Greg,
>
> Autokey is not the issue and TLVs have always been the intent. The
> problem is the optional MAC. For backward compatibililty it has to work
> with and without the MAC and with and without extension fields. Without
> a MAC the length of the last field must be seven or more words. In this
> case the parser eats all the fields and finds nothing left. With a MAC
> the length of the last field must be two or more words. In either case
> the lenght of all but the last field can be one or more words. That may
> sound spooky, but campatibility constraints rule it so.
>
> Dave
>
> Greg Dowd wrote:
>
>> 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
>>
>> snip!
>
>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg