| Re: [chrony-dev] 'Bug/Implementation' fix for v3 NTP client using 'authentication' with key id == 0 |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
- To: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Subject: Re: [chrony-dev] 'Bug/Implementation' fix for v3 NTP client using 'authentication' with key id == 0
- From: Jan Vanhercke <jan.vanhercke@xxxxxxxx>
- Date: Thu, 7 May 2026 14:35:26 +0200
- Cc: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mimir.be; s=google; t=1778157328; x=1778762128; darn=chrony.tuxfamily.org; h=content-transfer-encoding:in-reply-to:organization:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=hfVX3SDzrb3/JkaA5Dm++OqpFjbLdnFYZeO8b+HyxSM=; b=QMbtDetTFrI8iQYnDjygMB7gN0+I60/GA8CrgX4WiLu1AcDypXjkrMHwrdOHeIU5U4 TNxDP+IVgMXaYdgoxd/JcAzpQU1n51RMf3dTu4GOBxjKb8H43r5gCLw7ITKeLX7O58Go 6/fg7yC3kk8yjhE/+v/n2ZwtjIsWABTFuJhnF4euOinOGWwUvkVAX9D69kK+BRYhoDsc 1/0VFz9Y2Wy1LaPZ5qgKxEYjvYYivMZe5S8S0sczymEjX/wAyklzd8Iiv6Zoo1sAxlkL B1SVmhUnXItXoUhcbMK/Kb5uFO8iMCX7XyxFWNFvw8kUBVMWAEatfyH7OrKX044K3tY0 1CpA==
- Organization: MiMiR bv
On 07/05/2026 13:08, Miroslav Lichvar wrote:
On Thu, May 07, 2026 at 11:42:02AM +0200, Jan Vanhercke wrote:
Since we switched from ntpd to chrony 4.6.1, some of our appliances could no
longer sync.
Can you share the name of the appliance?
It's a Jünger Audio appliance (https://www.junger-audio.com/)
After some debugging we discovered that these clients are using v3 NTP with
authentication, but using a key id == 0, although the RFC specifies that the
key id must be greater than 1.
To be clear, the NTP client is sending a request that has 20 zero bytes
appended after the transmit timestamp? And ntpd was responding with a
crypto NAK (4 extra zero bytes), which the client accepted, and it
accepts also plain responses (no extra bytes) from the patched
chronyd?
ntpd doesn't distinguish v3 from v4. It handles everything as v4 and
juts copies the version value from the request to the response.
I've recovered the packet capture from when we had the issue, and the
payload was indeed 20 zero bytes appended to the packet. Chrony did not
send a reply and silently dropped the packet, which is not what it is
supposed to do neither. But I didn't have the time (no pun intended) to
look into the root cause.
I could not find a clear stipulation of what must be done with a packet
having key id == 0. The pseudo seems to imply it must be calculated and the
hash verified, but since the key id should not exist, what should the output
of the hash then be?
Anyhow the appliances we use expect no authentication occur. Since we really
wanted to switch to chrony we implemented a patch that reverts to no
authentication when the keyid == 0 to cover this gray zone.
To me that sounds like a buggy implementation that should be patched to
send well-formatted NTP requests. Have you asked the vendor?
No sure if it is a buggy implementation. For me it is a border edge
situation. When I read the pseudo code of RFC 5905 at the bottom of page
81, there seems to be a 'fall-through' to allow processing in case the
key id == 0. It's a gray zone in my opinion. The spec always defines the
key to be 1 or higher, but never addresses the expected behaviour when
it is 0.
I've also found sources (like NIST
https://www.nist.gov/pml/time-and-frequency-division/time-services/nist-authenticated-ntp-service,
section troubleshooting advice, point 2), that state regarding
signatures: '... or set a key number of zero, which also signals
non-authenticated NTP'
My patch only works for packets of NTP v3 and earlier, so if accepted a
fix for v4 should be implemented too.
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.