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

[Harlan Stenn <[e-mail]>]

On 8/31/2020 3:24 AM, Miroslav Lichvar wrote:
> On Mon, Aug 31, 2020 at 11:21:20AM +0200, Ulrich Windl wrote:
>>>>> Harlan Stenn <[e-mail]> schrieb am 29.08.2020 um 11:47 in Nachricht
>>> I don't know anybody who is using one keyid for authenticating from A to
>>> B, and a different keyid for authenticating from B to A.  But there's no
>>> reason that should not be permitted.  I don't even believe there should
>>> be a requirement that this case MUST map to the same key.
>>
>> However as not even the reference implementation supports it (AFAIK) (and I guess nobody else), so why make that statement.
>> Are you saying for "server server1 key 123" server1 is receiving queries authenticated with key 123, but is allowed to send replies using any different key, and that response is OK? That would mean if one key is disclosed, an attacker could send bogus responses using that key, right?
> 
> Yes, that is a security issue if an NTP client accepts responses
> authenticated with a key that it uses to authenticate responses to its
> own clients as the clients can perform a MITM attack on the server.
> IIRC with the ntp.org implementation you need to specify IP addresses
> in the key file to enforce that, which might be difficult to do if the
> clients are allowed the change their address. Other implementations
> require the responses to be authenticated with the key specified on
> the "server" line and I think that should be recommended in the NTP
> specification.

I certainly wasn't suggesting anything like that.

I was simply trying to point out that A->B could use any arbitrary keyID
to authenticate those packets, as long as A and B agreed on the keyID,
algorithm, and key, and B->A could also use an arbitrary keyID,
algorithm, and key as long as there was an agreement on that.

I'm not aware of anybody who is doing this now.

There are other possibilities as well.

But this is beyond the scope of the mode 6 documents.

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!