Re: [Ntp] NTPv5 draft

[Dieter Sibold <[e-mail]>]

On 1 Dec 2020, at 9:12, Miroslav Lichvar wrote:

> On Mon, Nov 30, 2020 at 08:12:06PM +0100, Dieter Sibold wrote:
>> 1. Security
>>
>> The protocol as proposed is missing a security approach. There are no
>> mechanisms described to provide authentication, integrity protection 
>> and
>> maybe encryption.
>
> The draft describes a MAC extension field, using the AES-CMAC
> (RFC8573). It also allows all NTPv4 extension field to be used in
> NTPv5, making it compatible with the NTS specification.

Yes, but this pre-shared key approach is not useable outside a closed 
group where the manual key management is feasible. In general you need 
to have an integrated key management like NTS.

>
>> I very much agree with Jame’s proposed draft that a new
>> version of NTP must provide these mechanisms by default.  Sure, you 
>> can add
>> NTS to protect the NTPv5 packets. But in this case protection is 
>> always an
>> optional add-on whereas it needs to be an inherent part of the basic
>> protocol. To achieve this the NTS approach certainly can be 
>> transferred to
>> the basic v5 protocol and packet format.
>
> You mean to require all NTP packets to be authenticated? I don't like
> that idea. The improvements in NTPv5 are orthogonal to authentication.
> NTPv5 is not supposed to be more secure. An NTP client that doesn't
> want to implement the complexity of NTS shouldn't be restricted to
> NTPv4.
>

Yes, I would propose that by default each NTP packet has to be 
authenticated. Not using security should be an active decision! I 
don’t think that security and increased time sync performance have to 
be orthogonal. The 2-step approach could provide better time sync 
performance and security.


>> 2. Interleave and 2-Step
>>
>> I agree with Doug to decide with approach to provide with NTPv5. 
>> Providing
>> both 2-Step and Interleave may increase complexity unnecessarily.
>> Personally, I find that the 2-step approach with the follow-up 
>> message is
>> more concise. And since the first message only need to be very small 
>> (it
>> just needs to contain the information to ensure correlation with the 
>> follow
>> up) the waste of network bandwidth is very small.
>
> If we must to support only one of them, I think it should be the
> interleaved mode.
>
> - It fits better software server implementations, which is what the
>   vast majority of NTP servers seems to be.
> - It is simpler to implement on clients. It doesn't require timeouts
>   for follow-up messages and handling of reordered packets.
> - It is inherently resilient to amplification. No risk of an
>   implementation having a bug in its cookie generation, or leaking
>   key, which would allow attacks.
>
>> 3. Traceability
>>
>> It would make sense that the v5-packets optionally provide 
>> information about
>> the uncertainty of the timestamps taken. These formally for 
>> establishing
>> traceability.
>
> Isn't that the NTP root delay and dispersion? Together they provide an
> estimate of the maximum error in the receive and transmit timestamp.

Uncertainty and maximum error are different. The uncertainty interval 
will always be smaller or equal to the max. error.

>
>> Additionally, in order to maintain traceability during the
>> time period in which leap smearing is applied the client needs to 
>> obtain the
>> necessary information to calculate the offset between UTC and smeared 
>> time.
>> This also is mandatory to maintain traceability.
>
> The smearing offset is provided in the Timescale Offset field.

Thanks.

>
> -- 
> Miroslav Lichvar