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

[Greg Dowd]

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