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

David L. Mills mills at udel.edu
Fri Apr 4 19:05:31 UTC 2008


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!




More information about the ntpwg mailing list