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

>>> Benjamin Kaduk <kaduk@mit.edu> schrieb am 27.08.2020 um 18:59 in Nachricht
<20200827165937.GQ16914@kduck.mit.edu>:

[...]
> General crypto best practice is to only use a given key for a single usage
> and with a single algorithm, so my expectation is that the algorithm would
> be assigned/negotiated at the same time that the key and key‑ID are.

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.

Looking up the specs I found

"   Key Identifier (keyid): 32-bit unsigned integer used by the client
   and server to designate a secret 128-bit MD5 key." (page 23)

"   Message Digest (digest): 128-bit MD5 hash computed over the key
   followed by the NTP packet header and extensions fields (but not the
   Key Identifier or Message Digest fields)." (page 23)

"   keyid: Symmetric key ID for the 128-bit MD5 key used to generate and
   verify the MAC.  The client and server or peer can use different
   values, but they must map to the same key." (page 32)

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."

All the code in the spec just seems to care about MD5.

Regards,
Ulrich

> 
> ‑Ben
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 