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 2:21 AM, Ulrich Windl wrote:
>>>> Harlan Stenn <[e-mail]> schrieb am 29.08.2020 um 11:47 in Nachricht
> <[e-mail]>:
>> On 8/29/2020 1:46 AM, Hal Murray wrote:
>>>
>>> [e-mail] said:
>>>> 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. 
>>>
>>> No, it's not an omission.  There is no need for the encryption type to be on 
>>
>>> the wire.  The admins for the client and server agree on the type while they 
>>
>>> are agreeing on the key and keyid.
>>
>> It's not an omission, and that the encryption type is not part of the
>> on-wire protocol is a clear feature.
>>
>>> The backwards compatibility was just good luck.
>>
>> I don't understand.  Backward compatibility?  Good luck?
>>
>> The NTP MAC is the stuff after the base packet and any EFs.
>>
>> It is comprised of a 32-bit (4 octet) keyid and a digest payload.
>>
>> This digest payload can be a number of different sizes.  RFC5905 talks
>> about the size needed for an MD5 digest.  Other digests and other digest
>> sizes are perfectly acceptable.
>>
>>>> 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." 
>>>
>>> I think it's a bug.
>>
>> 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?

I'm not saying anything about it, because that would be taking a stand
on behavior outside the scope of an informational specification.

You and I seem to be the minority of people who believe this document
should be a full-on Standards document that tackles these issues, however.

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