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

[Heiko Gerstung <[e-mail]>]

[resent to the list, I had a 50% chance to reply to the correct message – thank you for nothing, Murphy ;-)]

 

Daniel,

 

> From: Daniel Franke <[e-mail]>
> Date: Wednesday, 26. May 2021 15:12

 

> 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.

 

Thank you very much for taking the time, much appreciated. I am not 100% sure where I can find the stated list of goals of NTS.

 

The list of objectives as stated in RFC8915, Section 1.1 lists a number of objectives and yes, not all of them are met, but this is because they do not make sense or are not desired for unicast PTP. Objectives like Identity, Authentication, Replay prevention, Request-response consistency, Non-amplification and Scalability are covered in the proposed draft. This means that out of 9 stated goals, the draft addresses 6. Your statement that the draft does not appear to achieve *any* of NTS’s goals is therefore not correct IMHO. 


> 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.

 

You are correct, these goals are not important for PTP. The protocol itself prevents server statelessness, unlike NTP it is a subscription based protocol which means that a client has to establish contracts with a server and the server must keep a state for each contract. A requirement for client unlinkability could definitely come up. It may be satisfied by the fact that if a client changes its IP address, it has to re-establish a new contract with the server. In order to do so after an IP address change, the client has to re-run phase 1 and get a new cookie. As IP address changes typically do not happen very often, this might be acceptable for some applications. 

> 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. 

This statement seems to indicate that you did not yet understand how unicast PTP works. 

 

There is no exchange of time information or delay measurements etc. in phase 2, this phase is solely performed to establish contracts between the client and the server. A client typically requests  announce messages (carrying state information of the server) first. When it detects that the state of the server is acceptable, the client establishes two additional contracts, one for sync messages (time transfer from server to client) and one for delay responses (delay measurement from client to server), i.e. in a typical scenario, a client has 3 active contracts (for announce, sync and delay_responses). In phase 3 the server sends sync and announce messages and responds to delay_requests with delay_responses. 

 

All those message are secured using the keys established in phase 1, I therefore do not understand why you claim that the protocol fails to provide time authentication. 

 

> 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.

 

This is confusing, as you are an author of RFC8915 which correctly and clearly explains in Section 8..6 that delay attacks cannot be prevented by cryptographic means. The MAXDIST approach might work for some applications, but I do not think that this is applicable for  unicast PTP use cases. 

> 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. 

 

An attacker that is capable of dropping messages can always drop them, the Unique Identifier EF from NTS4NTP cannot prevent that. 

As the NTS TLV is only used in phase 2, it is not a problem and the expected behavior for the client to negotiate one contract after the other, and depending on the requested duration, this is only required once every couple of minutes for example. The mechanism of the server including a nonce in the message that the client has to use in its next message ensures that a reordering of messages in any direction will not be successful.  

 

> 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.

See above for an explanation of the phases (delay_req only happens in phase 3, the NTS_TLV is only used in phase 2) and please see the explanation in our draft how we avoid replay attacks. 

 

In Section 7.1 we outline that the sequenceId has to be increasing in two consecutive messages of the same type, i.e. two delay responses. If a message arrives with a lower sequenceId than in the previous message, it will be ignored and does not trigger a phase 1 rerun. That means a retransmission of a packet in phase 3 will simply be ignored by the client. 


> 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.

 

Again, Daniel you seem to have misunderstood how PTP and the proposed draft is working. It is not uncommon that PTP clients will receive 128 sync messages per second and perform 128 delay  measurements (i.e. a delay_req and delay_resp exchange) per second. 

 

Best Regards,

  Heiko