Re: [Ntp] Antw: Re: Antw: [EXT] Re: Quick review of WGLC for status change for draft‑ietf‑ntp‑update‑registries

[Harlan Stenn <[e-mail]>]

On 8/9/2022 3:34 AM, Ulrich Windl wrote:
>>>> Harlan Stenn <[e-mail]> schrieb am 09.08.2022 um 11:11 in
> Nachricht
> <[e-mail]>:
>> On 8/9/2022 1:02 AM, Miroslav Lichvar wrote:
>>> On Mon, Aug 08, 2022 at 06:48:28PM ‑0700, Harlan Stenn wrote:
>>>> On 8/8/2022 5:58 AM, Miroslav Lichvar wrote:
>>>>> If you allow short extension fields, you will not be able to detect
>>>>> whether a request contains an unknown extension field or an Autokey
>>>>> MAC using an old cookie. The protocol may be able recover, but that's
>>>>> not how things should be done.
>>>>>
>>>>> Here is an example:
>>>>>
>>>>> 04 1b 00 14 cc e2 c8 47 71 95 79 64 c4 71 e8 72 7e bf fb cd
>>>>>
>>>>> Which of the two is it?
>>>>>
>>>>
>>>> More context, please.
>>>>
>>>> What is that set of bytes?
>>>
>>> It's the UDP data following the NTP header.
>>
>> I don't do this stuff in my head as well as I used to.
>>
>> Is there a symmetric key for keyID 1051?  If so, what hash algorithm was
>> used?
> 
> Should the parsing of the packet really depend on knowing what hash algorithm
> a specific key ID uses?

In general, no.

More below.

> It's quite likely that a server receives packets with a key it does not know.

If a packet is authenticated with a keyID the receiving system does not 
understand, then the receiving system CANNOT authenticate the packet. 
In this case, it's expected that the receiving system will drop the packet.

Do you disagree?

I asked about the algorithm that was used because it is possible for 
MACs to have different payload lengths.

The receiving system can see if the keyID is known, and if it is, the 
expected algorithm will dictate the length of the MAC payload.

If that payload length does not match, then the field in question cannot 
be a legacy MAC.
-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!