Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

[Daniel Franke <[e-mail]>]

(Resending to reply to the list)

I finally gave this draft a close read this morning. I have to oppose
adoption, on the grounds that it doesn't appear to achieve any of
NTS's goals.

It clearly doesn't attempt to achieve server statelessness. It doesn't
achieve client unlinkability either, since only one cookie is provided
and there's no mechanism for refreshing it without a new NTS-KE. The
case possibly could be made (but hasn't been) that these goals aren't
as important for PTP as they are for NTP, but after this I would still
object that calling a protocol "NTS" when it doesn't provide these
things is bad marketing for NTS4NTP.

The killer, though, is that the protocol fails to provide time
authentication to within any reasonable error bounds. The only secure
time exchange is the one that happens in phase 2 during the
DELAY_REQ/DELAY_RESP exchange. Transmissions during phase 3 are
vulnerable to delay attacks. Checking sequence numbers is not
sufficient mitigation against these. A MitM could forward packet N
when (and only when) the server sends packet 2N. All sequence number
checks would pass, but absent any other sanity checks the client's
clock would be slowed by a factor of two.

The NTS TLV is missing any field that corresponds to the Unique
Identifier EF from NTS4NTP. Without this, an attacker can drop or
reorder the server's messages and confuse the client as to what
request a response corresponds to. This is easy to fix, but absent a
fix, clients would have to mitigate this by making sure they only ever
have one request in flight at a time. Failure to promptly obtain a
response to any time-sensitive request such as DELAY_REQ would require
rerunning NTS-KE. Non-time-sensitive requests could simply be
retransmitted.

To salvage the security of this protocol, you could first fix the
Unique Identifier issue and then have the client send DELAY_REQ
messages at NTP-like intervals, rather than just once per handshake,
in order to regularly reëstablish tight error bounds that can be used
to sanity-check the phase 3 packets. This would achieve time security
about equal to what you get from the NTP/PTP hybrid I proposed last
month, but without privacy, without server statelessness, and with an
added requirement for support from the server rather than being able
to unilaterally implement it on the client side.

On Wed, May 26, 2021 at 4:31 AM Heiko Gerstung <heiko.gerstung=
> [e-mail]> wrote:
>
>> Dear fellow NTP working group members,
>>
>>
>>
>> I just submitted the latest revision of our NTS for Unicast PTP draft
>> (-02) which you can find here:
>>
>> https://datatracker.ietf.org/doc/draft-gerstung-nts4uptp/
>>
>>
>>
>>
>>
>> Based on our experience of more than 20 years (NTP) and 15 years of PTP
>> based network time synchronization for quite a large number of different
>> applications and industries, we believe that the proposed draft will
>> increase the number of potential use cases for unicast PTP by adding
>> serious and sound security mechanisms to this protocol. It will enable
>> users in a large variety of areas to transport highly accurate and reliable
>> time over wide area networks and hard to protect large-scale private
>> networks.
>>
>>
>>
>> Unicast PTP is a protocol that has been designed to be used in protected
>> network environments and requires additional protection to allow using it
>> in other types networks, i.e. the Internet or wide-area-networks where it
>> is impossible to ensure that no malicious actor with access to the network
>> can carry out various attacks. The proposed draft offers protection against
>> most of the possible attacks.
>>
>>
>>
>> The authors acknowledge that other variants of PTP, namely the multicast
>> and hybrid (i.e. unicast and multicast) forms, need to be protected as
>> well. However, those forms are rarely used over wide area networks and are
>> much more common in local area networks and protected network environments.
>> Securing multicast and hybrid PTP requires a more complex solution and our
>> expectation is that the proposed standard for securing unicast PTP will be
>> completed faster due to the fact that we built it on the work that already
>> went into RFC8915. The similarities in the key exchange phase of the
>> protocol also offer an efficient way to implement combined NTS4NTP and
>> NTS4UPTP key exchange service daemons and therefore helps to simplify
>> deploying secure time synchronization solutions that support NTP, PTP or
>> both in parallel.
>>
>>
>>
>> I therefore would like to formally request adoption of this draft by this
>> working group and kindly ask you to review the draft, and send your
>> questions, comments and general feedback to the WG and/or one of the
>> authors of this draft.
>>
>>
>>
>> Thank you and best regards,
>>
>>   Heiko
>>
>>
>>
>>
>>
>>
>> --
>>
>> Heiko Gerstung
>>
>> Managing Director
>>
>>
>>
>> MEINBERG® Funkuhren GmbH & Co. KG
>>
>> Lange Wand 9
>>
>> D-31812 Bad Pyrmont, Germany
>>
>> Phone: [phone]
>>
>> Fax: [phone]
>>
>>
>>
>> Amtsgericht Hannover 17HRA 100322
>>
>> Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre
>> Hartmann, Heiko Gerstung
>>
>>
>>
>> Email:
>>
>> [e-mail]
>>
>> Web:
>>
>> Deutsch https://www.meinberg.de
>>
>> English https://www.meinbergglobal.com
>>
>>
>>
>> Do not miss our Time Synchronization Blog:
>>
>> https://blog.meinbergglobal.com
>>
>>
>>
>> Connect via LinkedIn:
>>
>> https://www.linkedin.com/in/heikogerstung
>>
>>
>>
>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ntp
>>
>