RE: [chrony-users] RE: Can we deny non-NTS client? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
- To: "chrony-users@xxxxxxxxxxxxxxxxxxxx" <chrony-users@xxxxxxxxxxxxxxxxxxxx>
- Subject: RE: [chrony-users] RE: Can we deny non-NTS client?
- From: "Akihiko.Izumi@xxxxxxxx" <Akihiko.Izumi@xxxxxxxx>
- Date: Mon, 16 Jan 2023 04:41:49 +0000
- Accept-language: ja-JP, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sony.com; dmarc=pass action=none header.from=sony.com; dkim=pass header.d=sony.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OguANHTyhCTSYe1a7LhZueIV7k4yUd//YFHfrJ0/j0A=; b=GY/p0FWfTSXjNLubLBjcjhhkIrVwnKO+L9x8ntT8hlxzSC9VHuVA4UKAvpaLOZTJ2T+/OaZZrA6I+JJdfXVmjNl6um6IVUnYzcHZm/nUDmpAtvsVTXbqLWC1kn+e941jvjcEpeY7o5qNDReGCxsNTHWv+SnoqO8nRHiDsjSnAz2Wypgn1jK6gBuL/cfwM5O9Fy+Ka3L0D1klZD3M8C5JEAXVhNs5ze9//bnCT/aW70+KeXwkAXpW3d94njbdAq0MBKw/1t4Yfbc83HFEngSGKLsGgS2XKd54heNRuX3obB8TmBUbf6aC914d4fPFC2hSKsXZ12tZwvU5+qJ6wfmUbg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kdW5LU7mFFdzRIfPqD6/DFNQ+8xISPkqnsPe56ZhUIOEv9oNzPlxvPEIhInz3WB/my7+13wWPyQqhPGbu6iJbQbqbno4GEteQ4pJkxuhcK060Z5B02NeXk8IDmHcprqQKeikw0CtASVhK1hlAte9FvRFPVobhhFRklWvzXQ0Vebs6AzQ6YXo0AW8HVaG77XtGbdsuYoGt88G1rG9DXCVdJx63Hmti4a89q+fgfDCHKUXphPz7U36NDB8p1nsB+iZqUrfqyrx/9swfHK+RO+bzyHyfLEyRYGwVqY22+NeKRd2XzTh4rG5f3QrodHHfH9p/p3isjEaQBfslYSDGQQ0Vg==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sony.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=S1; bh=OguANHTyhCTSYe1a7LhZueIV7k4yUd//YFHfrJ0/j0A=; b=pJ/z475yWGWXNvycQYc3p6Wvo9TkmXhqUC6Ju5OBLeV+9yldu/fSu2eOjjxsso/UvU4O zo1S2Hjoi7HoEDS0d2ra1xZveTQ20JTXXHGU+6Flk+k8FG4LWxIqWWZrqryYpynEzrX4 K0a7apB8tHxmjkZX1Apv8uxdv15D1y7WW92gs/uYYBZ1VbQBrpQnFJHSOxh3RcUPqrpu QucLm0NHs8el2ROQOA8c/dmbgMC5We3Ms0pZA3X64oiJ6v//QVHAi03eYZB4d0r0WzS/ 9d348FcUbSYqjswA5tdO8HM/HSt4jpleZ/zBR4MHitvesD55N7EDRD6V+P4hSDVrtHAt rA==
- Thread-index: AdkToT3TsRUSiNm2TZKwhNLLOQ9yigAASOTQADBde6ACiyUrAAFkJ10wAAGxZgAATslKkAAP6iiAAO+esKA=
- Thread-topic: [chrony-users] RE: Can we deny non-NTS client?
> The response is sent only if it's not longer than the request. In the source code it's in the transmit_packet() function in ntp_core.c:
I looked the transmit_packet() function and it seems to be called at sending every NTP request/response.
I feel that's good and safe implementation. Thank you.
> > RFC8915 describes "8.7. NTS Stripping". Isn't is applicable to Chrony?
> chronyd as an NTP client configured with the "nts" option ignores unauthenticated responses.
When chronyd failed NTS-KE handshake (ex. mis-configuration of certificate), does chronyd fallback to plain NTP (or not)?
(If it is true, I afraid dedicated NTS server/client may use plain NTP unintentionally.)
Best Regards,
-----Original Message-----
From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
Sent: Wednesday, January 11, 2023 6:54 PM
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [chrony-users] RE: Can we deny non-NTS client?
On Wed, Jan 11, 2023 at 02:31:11AM +0000, Akihiko.Izumi@xxxxxxxx wrote:
> Thank you for clarifying my question. I learned a lot.
>
> > it would not be sent as there is an additional check made before transmission comparing the length of the request and response.
>
> What comparison is done between the length of the request and response?
The response is sent only if it's not longer than the request. In the source code it's in the transmit_packet() function in ntp_core.c:
if (request_info && request_info->length < info.length) {
DEBUG_LOG("Response longer than request req_len=%d res_len=%d",
request_info->length, info.length);
return 0;
}
> > If the NTP server didn't respond to unauthenticated NTP requests, it couldn't respond with NTS NAK to indicate the client it has expired cookies.
>
> I understand.
> I think sending NTS NAK is necessary for mis-authenticated NTP packets, but not necessary for plain NTP packets.
> Is my understanding correct?
Right. NTS NAK is sent only if the request contains the NTS-specific extension fields and the authenticator is not valid (most likely due to the client using an old cookie, which the server can no longer decrypt).
>
> I have another question.
> RFC8915 describes "8.7. NTS Stripping". Isn't is applicable to Chrony?
chronyd as an NTP client configured with the "nts" option ignores unauthenticated responses. An NTS NAK is accepted only if no valid authenticated response is received in the polling interval, i.e. an off-path attacker cannot trigger a new NTS-KE session unless there is a packet loss between the server and client, or the server cannot respond to all requests (e.g. due to rate limiting).
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.