| Re: [chrony-dev] chrony.keys extension relevance |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Wed, Jan 24, 2018 at 04:58:04PM +0100, FUSTE Emmanuel wrote:
> As there is still a long road before NTS, is there any rationale to not
> implement something like an optional by key ip list like in the ntpd
> ntp.keys format ?
> In the case of chrony, it could be a list of subnets of the same format
> as in the allow/deny directives.
In what cases it would be useful?
With ntpd as a client it's necessary to specify the IP address of the
server in the key file to prevent its own clients (which have a
different key) from performing a MITM attack on the server. With
chronyd as a client this is not necessary as it checks the key ID in
all responses it receives.
The extended key file makes some sense with emphemeral associations,
which have no peer directive in the config file where the key could be
specified. chronyd does not support ephemeral associations.
As a server, chronyd authenticates responses with any key the client
can authenticate the request with. If I give a client a key, does it
matter from which address it is sending requests authenticated with
that key?
--
Miroslav Lichvar
--
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.