Re: [Ntp] Experimental/Private EF area: was Re: Registries document

[Harlan Stenn <[e-mail]>]

On 8/1/2023 12:01 AM, Miroslav Lichvar wrote:
> On Mon, Jul 31, 2023 at 10:39:27PM -0700, Harlan Stenn wrote:
>> I don't understand what you are saying, Miroslav.
>>
>> Maybe I do, if you agree with the following (which is what I've been saying
>> for years):
>>
>> - the Reference implementation published Autokey code that used the V1 EF
>> format.
>> - RFC5906 describes the V2 EF format.
> 
> RFC5906 is an informational document. It says it describes the
> Autokey protocol implemented in the www.ntp.org's ntpd.

Yawn.  You and I have had this discussion before.

5906 was apparently downgraded from Standard to Informational because, I 
believe, some folks wanted to offer NTP without autokey, and wanted 
"extra ammunition" to make their point.

There is clearly content in 5906 that SHOULD have been in the Standard, 
but wasn't because, I believe, after 5 years of effort on 5905 and over 
3 years of effort on 5906 folks wanted to "make progress and get it out 
the door".

If 5906 would have been Standards track then even if somebody didn't 
choose to implement Autokey there would still be Standards track 
information about EF.  As there SHOULD have been.

> But there is
> an error in the description of the EF types and the registered values.

Not an error in the document.  A discrepancy between the code and the 
document.

> The code and version subfields are swapped. ntpd never had what is
> described in the RFC. Also it doesn't say anything about "V1/2 EF
> format" and I didn't see this mentioned anywhere before.
The RFCs came out in June of 2010.

The code first saw light of day (and use) in September of 1997.

The Autokey change from Type 1 to Type 2 came out in July of 2003.

draft-ietf-ntp-autokey-00 came out in September of 2007, partway thru 
the period where ntp-4.2.4 was in use.

I heard plenty from folks who said "don't break backward compatibility". 
  I heard *nothing* about "hey, maybe we should figure out how to make 
the EF code match 5906".

But, as I said, I'm going to be working on a document where the V1 EF is 
documented for historical purposes.

That's separate from the Type 1 and Type 2 Autokey stuff.

Perhaps more to your point, you haven't seen this "documented" because 
draft-stenn-ntp-extension-field was dropped from consideration by the WG 
at a meeting where I was not in attendance.

It seems disingenuous to me to claim that some committee members are now 
interested in work that "the committee" decided it no longer wanted.

>> - NTS uses the V2 EF format.
> 
> NTS uses the types it was assigned (per your suggestion IIRC). It
> doesn't care about the values. It would still work even if they were
> completely random.

Yes.  So what?

The values I chose are very efficient to process in an enterprise-class 
or "carrier grade" implementation.

That there are other ways to do it that are not suitable for those 
levels of quality, while true, does not make them "better".

>> - All of the other proposed new EFs use the V2 EF format.
> 
> Only Autokey cares about the code, version, response, error subfields
> in the type field.

I don't believe any current proposals use the error flag.

Checksum complement and NTS use the bottom byte as type, and the top 
byte as a combination of flags+code.  The checksum complement uses a 
flag bit that is no longer "active", but that's a non-issue.  Both of 
those proposals use what I call the "code".  It just so happens that the 
code for the checksum complement is 0.

I don't know what you are calling the "version".

All of the proposals I have submitted, for which we have working code, 
that will be released soon (now that I have no expectations of 
cooperative behavior from the IETF NTP WG) use these fields.  You can 
see more about them from my expired drafts, if you care.

As has long been documented, nobody is being forced to implement 
extension field stuff that they don't want to implement.

>> - There are no known other implementations of Autokey, using either
>>    V1 or V2 EF formats.
> 
> Right.
> 
>> - Nobody has said they plan to implement Autokey (V1 and/or V2).
> 
> Right.
> 
>> - The NTP Project will not be supporting simultaneous use of the V1
>>    and V2 EF formats between two NTP instances.
> 
> Ok.
> 
>> In a short while, the reference implementation will be releasing code that
>> supports the V1 and V2 EF formats.  At that time, there's a chance that we
>> will allow Autokey to be used over both V1 and V2 EF formats.
>> *If* we do this, we will support Autokey V2 EFs protected by new-style
>> authentication (including NTS and MAC-EF).
> 
> Why would you do that? Such a waste of your project's resources.

I'm not saying we'd do it for free.

There are apparently large organizations who, in spite of being told for 
a very long time that Autokey should not be used, still use Autokey 
because it gets them a TAI offset, and "it works just fine for them".

Yes, my extended-information-ef proposal will do the same thing, but 
they would have to re-tool for that.

> You
> need to tell your users to stop using Autokey. It's completely broken.
> It wasn't secure in 2000 and it's not secure now.

a) I don't recall anybody demonstrating that it was broken in 2000.  I 
do remember seeing demonstrations after 2010.  But does it matter?

b) Autokey's *authentication* is weak. But:

- if it's deployed on a sufficiently secure/isolated network where
   folks are satisfied with their monitoring and physical protection,
   and they've been aware of the risks for a VERY long time, what's
   the actual problem?

- Autokey packets (in the V2 EF format) can be protected by either
   private key or NTS.  Do you disagree that these will protect the
   Autokey payloads?

> A modern computer
> can crack the 32-bit key in less than a second. If you want to keep
> the Autokey support in ntpd for a while to not break compatibility
> with existing client configurations, that's fine,

No argument there, and see above about cases where I am told some 
significant players are using it, at least internally.

> but there is no good
> reason to be making any changes to it at this point.

We won't be doing it without good reason.  And good reasons include 
somebody saying "I want it and here is $ to make it happen."

Another possible good reason would be to show how some of the payload 
features or the interim use of Autokey can be securely used because the 
protecting MAC is not trivially crackable.

> Let's update the registries to include the ntpd Autokey EF types and
> move on.

Please keep the V1 EF table separate from the V2 EF table.

-- 
Harlan Stenn <[e-mail]>, part of
http://networktimefoundation.org - be a member!