[ntp:hackers] [ntpwg] Pending NTP WG Last Call on Autokey

David L. Mills mills at udel.edu
Sun May 11 22:58:14 UTC 2008


Todd,

My proposal has nothing to do with whether or not to adopt autokey, only 
how to forma a 16-bit field containing the opcode, version and possibly 
a type or class code. Danny's proposal involves a 17-bit field. My 
proposal was intended to provide compatibility with existing use and 
permit reuse of existing code in applications other than autokey.

If I were implementing something and had a white-hot hatred of autokey, 
I would rip out all the crypto code and keep the parser and existing 
protocol state machine (but not the states) and the interface code 
between the new mechanics and NTP mechanics. This is not a trivial glob 
of code.

Let me try something to help me understand the serious level of 
objections heard from Danny and Todd. In point of fact, the field 
definitions are in a set of macros easily changed and ifdeffed. So, 
starting from scratch tell me how to format that 16-bit field. Note both 
the opcode and version do not have to squander all eight bits and can be 
moved anywhere.

Todd, if there is something you have in mind that absolutely cannot be 
done with my proposal, please speak up.

Minor nit. USNO, NIST and NMC (Canada) use the reference model as-is, 
although NIST uses a different mechanism to call Boulder. NIST and NMC 
use symmetric key; USNO uses that and autokey.

Dave

TS Glassey wrote:

> AutoKEY is not the only auth mechanism that NTP should support - I am 
> in favor of a more open interface model of which AutoKEY is one of 
> several auth mechanism's put in place, but AutoKEY is broken by design 
> - it doesn't scale and has a limited number of possible cached keys 
> such that broad-distribution models with this NTP is not possible.
>
> On the other hand there is OpenNTP as well - and NIST's NTP which both 
> don't follow this track either.
>
> Dave - I respect you immensely but this isnt about you or your NTP 
> anymore - its one of the key problems with people's like Danny's 
> abusive commentary too. It shows how little the physicists in this WG 
> understand evidence models or what testimonial's are like.
>
> The reality is that this NTP is broken... and it isnt getting any 
> better IMHO - just more difficult to fix.
>
> Todd Glassey
>
> ----- Original Message ----- From: "David L. Mills" <mills at udel.edu>
> To: "NTP Working Group" <ntpwg at lists.ntp.org>
> Sent: Saturday, May 10, 2008 8:33 PM
> Subject: Re: [ntpwg] Pending NTP WG Last Call on Autokey
>
>
>> Danny,
>>
>> Don't fool with the length field. This goes cross puposes with other
>> protocols such as IP and UDP. We are not going to see hundreds or even
>> dozens of extension field types in NTP. What you suggest creates a
>> ghetto for Autokey and does not provide a framework for
>> type/version/opcode encoding. No proposal is complete without that
>> encoding. The solution I proposed is completely adequate for whatever
>> purpose extension fields might be used for; the implied generality is
>> not worth the obscurity and incompatible model it creates.
>>
>> Dave
>>
>> Danny Mayer wrote:
>>
>>> Dave,
>>>
>>> Absolutely not. We need to do this now before there are too many
>>> implementations in the field. Do it now and get it over with.
>>>
>>> Danny
>>> David L. Mills wrote:
>>>
>>>> Danny,
>>>>
>>>> We are having a violent disagreement. The disagreement will continue
>>>> with enthusiasm. Stay out of the length field. Leave things as they
>>>> are and get this damn puppy out the door. When a new appliation
>>>> surfaces for the extension fields, consider a revised format and junk
>>>> the existing format.
>>>>
>>>> Dave
>>>>
>>>> Danny Mayer wrote:
>>>>
>>>>> Dave,
>>>>>
>>>>> I'm not buying it. I don't give a hoot about prior art. I'm trying
>>>>> to fix the original problem of your overloading the type field with
>>>>> private  codes. This is a workaround to allow the old usage to
>>>>> continue to work while the code is upgraded to the correct usage and
>>>>> to allow interoperation between the old and the new. The old will be
>>>>> obsoleted after several releases.
>>>>>
>>>>> Danny
>>>>> David L. Mills wrote:
>>>>>
>>>>>> Danny,
>>>>>>
>>>>>> No sell. There are numeous examples of prior art in the use of a
>>>>>> 16-bit length field in IP and UDP. I do not think it clean at all
>>>>>> to poach on the length field. In any case, it doesn't really make
>>>>>> much difference. What you see is what you get unless you have a
>>>>>> specific proposal for a competitive protocol. Right now I don't
>>>>>> hear anything.
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>> Danny Mayer wrote:
>>>>>>
>>>>>>> Dave,
>>>>>>>
>>>>>>>
>>>>>>> You misunderstand me. I'm proposing that autokey complies as well.
>>>>>>> conformance bit set to 1 indicates that you are conforming to the
>>>>>>> protocol while conformance bit 0 (which it would have to be in
>>>>>>> order to be the top bit of the length field) would mean the old
>>>>>>> format and would be non-compliant with the autokey protocol and
>>>>>>> the NTPv4 spec. The old autokey usage of the field type would go
>>>>>>> away.
>>>>>>>
>>>>>>>
>>>>>>> I'll send you the layout at little layer.
>>>>>>>
>>>>>>>
>>>>>>> Danny
>>>>>>>
>>>>>>>
>>>>>>> David L. Mills wrote:
>>>>>>>
>>>>>>>> Dannt,
>>>>>>>>
>>>>>>>>
>>>>>>>> Each of us has proposed stealing bits from the length field or
>>>>>>>> the code fields. I find stealing from the length field inelegant,
>>>>>>>> while you might find theft of code bits crude. Your proposal
>>>>>>>> cleaves Autokey from any other and does not necessarily provide
>>>>>>>> for multiple others. I prefer my proposal.
>>>>>>>>
>>>>>>>>
>>>>>>>> Dave
>>>>>>>>
>>>>>>>>
>>>>>>>> Danny Mayer wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Dave,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My proposal that I sent out quite a long time ago was to steal a
>>>>>>>>> bit from the length field and set it to 1 for the updated
>>>>>>>>> protocol so that the particulars of the autokey protocol remains
>>>>>>>>> private inside the header extension itself and keeps it outside
>>>>>>>>> the field type. That way the servers (including those of NIST,
>>>>>>>>> USNO, etc.) can continue to work with both versions (the old and
>>>>>>>>> the new). The old clients (servers) will continue to work.
>>>>>>>>> Taking away one bit from the length field reduces the maximum
>>>>>>>>> extension length from 65535 to 32767 which I don't think we will
>>>>>>>>> ever need or can use.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It's this lack of privacy of this data that causes
>>>>>>>>> interoperability problems between Autokey and Microsoft's
>>>>>>>>> MS-SNTP protocols, otherwise this issue would never have arisen.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Danny
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> David L. Mills wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Danny,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I hear no proposals about extension fields other than my last
>>>>>>>>>> proposed rewrite of that section. There really is no wiggle
>>>>>>>>>> room other than deprecating Autokey in its present form and
>>>>>>>>>> reformatting the headers. I am not opposed to that in
>>>>>>>>>> principle, but others, specificlly USNO, have not been heard 
>>>>>>>>>> from.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Dave
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>>
>>>>>>>> ntpwg mailing list
>>>>>>>>
>>>>>>>> ntpwg at lists.ntp.org
>>>>>>>>
>>>>>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>>>>>>
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> ntpwg mailing list
>>>>>> ntpwg at lists.ntp.org
>>>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>>>>
>>>>
>>>> _______________________________________________
>>>> ntpwg mailing list
>>>> ntpwg at lists.ntp.org
>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>>
>>>
>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg 
>
>



More information about the hackers mailing list