[Ntp] Antw: Re: Antw: [EXT] Re: Benjamin Kaduk's Discuss on draft-ietf-ntp-mode-6-cmds-09: (with DISCUSS and COMMENT)

[Ulrich Windl <[e-mail]>]

>>> Hal Murray <[e-mail]> schrieb am 29.08.2020 um 10:46 in
Nachricht <[e-mail]>:

> [e-mail]‑regensburg.de said:
>> While many decisions in the past were made to keep up backwards
>> compatibility, the encryption type is set up indirectly vie the ntp.keys
>> file. However (AFAIR) the file is not part of the NTP specification, so
for
>> the on‑wire protocol there's no change to get the encryption type. One
might
>> guess, however.
> 
>> Probably this was an omission after the only encryption type (DES) had
been
>> extended to allow MD5 also (in NTPv3 AFAIR). The later on it was still
>> forgotten. 
> 
> No, it's not an omission.  There is no need for the encryption type to be on

> 
> the wire.  The admins for the client and server agree on the type while they

> 
> are agreeing on the key and keyid.

Well, if there's only one algorithm, you don't need to specify it, but if
there are multiple, it would be quite helpful. It's not needed, maynbe, but the
code tried to guess from the packet sizes what type of algorithm it might be.
DES vs. MD5 vs. SHA-a may be easy, but the more algorithms are allowed, the
trickier it becomes...

Original comment from NTP source:
        /*
         * Parse the extension field if present. We figure out whether
         * an extension field is present by measuring the MAC size. If
         * the number of words following the packet header is 0, no MAC
         * is present and the packet is not authenticated. If 1, the
         * packet is a crypto-NAK; if 3, the packet is authenticated
         * with DES; if 5, the packet is authenticated with MD5; if 6,
         * the packet is authenticated with SHA. If 2 or * 4, the packet
         * is a runt and discarded forthwith. If greater than 6, an
         * extension field is present, so we subtract the length of the
         * field and go around again.
         */

> 
> The backwards compatibility was just good luck.
> 
> 
>> Actually I don't understand the part: "The client and server or peer can
use
>> different values, but they must map to the same key." 
> 
> I think it's a bug.
> 
> 
> ‑‑ 
> These are my opinions.  I hate spam.