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

[Doug Arnold <[e-mail]>]

Miroslav identified three issues that are under discussion:
- Does it make sense for PTP to have a public-key based
  authentication?

A big weakness of PTP is server impersonation.  So PTP needs a security mechanism that requires that a PTP node get authenticated before it can get keys.  Also the feedback I get from both equipment manufacturers and network operators is: no new key management mechanism.  So PTP security should be based on something already in common usage, such as TLS, or IPsec.

- Does it make sense for unicast PTP to have something different than
  the rest of PTP?

Unicast PTP is actually quite different from multicast PTP, or mixed multicast/unicast PTP.  Unicast PTP with negotiation (the usually way to do unicast PTP) has an additional message negotiation stage, intended to allow PTP servers to manage their capacity.  The negotiation mechanism turns PTP into a client-server paradigm, rather than a leader-follower paradigm like multicast or mixed multicast/unicast PTP.

- Does it make sense to reuse something from NTS4NTP?

All of the commercial time server companies make appliances that do both PTP and NTP.  So the more they can have in common the better.  Most customers that have PTP running, also have NTP running at the same time.  So it will be helpful for network operators to learn about the security if it is similar, even if it just the terminology, and concepts in the standard.

Doug

From: ntp <[e-mail]> on behalf of Miroslav Lichvar <[e-mail]>
Date: Thursday, June 3, 2021 at 3:32 AM
To: Heiko Gerstung <heiko.gerstung=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
On Wed, Jun 02, 2021 at 06:12:28PM +0200, Heiko Gerstung wrote:
> Well, I tried to describe how it compares to all the alternatives that you and others brought up. Please excuse my confusion, but I am not sure how to proceed from here. I was told numerous times in the past that if I wanted other people to discuss a proposal of mine, then I should come up with a draft. This is exactly what I did with NTS4UPTP.

I'm glad you wrote the draft and we can discuss it.

> But instead of discussing my proposal, people start to propose alternative approaches (by mentioning them in a sentence or two, most of the time claim that this alternative is either already available or requires only a very short and compact document to describe it and matches or exceeds the security gain of our proposal).

I think that's expected. People try to convince you their ideas are
better and you try to convince them they are not, or accept their
suggestions and rework your draft.

NTS4NTP took many years to form. IIRC it was redesigned three times
from scratch. As we seem to agree, PTP is nothing like the
client/server NTP mode that NTS4NTP protects and cannot be reused as
a whole. I hope you didn't expect this would go smoothly right with
the first submitted proposal.

I think there are basically three different issues discussed:
- Does it make sense for PTP to have a public-key based
  authentication?
- Does it make sense for unicast PTP to have something different than
  the rest of PTP?
- Does it make sense to reuse something from NTS4NTP?

> The first question was why not using MACsec or IPsec. I explained that it will not work because of the loss of the hardware timestamping capabilities.

That's ok, but it needs to be explained in the draft as those are
solutions mentioned in IEEE1588.

> * DTLS: Asymmetric cryptography would have to be required to be carried out by every PTP server separately for each client (even if this happens only once at the beginning to initialize the DTLS communication). This requires a major modification to the PTP software on the server side and is also requiring more processing power on each PTP instance

I didn't realize this was a requirement. I think with (D)TLS you can
move the session between servers to avoid the slow crypto. I hope
someone who actually understands DTLS will correct me if I'm wrong. A
new TLV could be introduced to tell the client to move a different
server and the client would try to resume the session there. An
advantage over your proposal is that it could do that on each unicast
renewal and not only when the cookie expires, so it could be more
dynamic.

> * DTLS: would require to protect delay responses and announce messages from the server (in the packet transmission phase)
> * NTS4UPTP: only requires to use the integrated PTP security mechanism in phase 3 for all message types

I don't see that as a disadvantage.

> Not sure if this is more like what you would like to see from me in regards to a comparison.

Yes, that's great and I'd like to see other people comment on those
points.

> At this point I would be open to change the name of the draft so that it does not contain "NTS" anymore, if that helps. It seems that quite a number of the authors do not like that we based our proposal on their work and would rather like unicast PTP to use something else as a key exchange protocol.

Having NTS in the name is not the main concern for me.

It's the use of NTS-KE and NTS cookies that doesn't make much sense to
me. It's possible I missed some important point. In NTS4NTP cookies
are meant to offload the server state to the client, so it can be
stateless, but in unicast PTP you already have to keep some
client-specific state, so why would you need to offload some part of
the state?

> I do not think that this is reasonable, it has been mentioned numerous times now that there are quite a number of users operating both NTP and PTP sync infrastructure in parallel and I am still convinced they appreciate to be able to set up one NTS-KE server infrastructure that handles both NTS4NTP and our proposal. And: ee wanted to use the latest and greatest key exchange protocol that has been designed by security experts and time sync specialists.

The key exchange comes from TLS. You don't need NTS-KE for that.
Sharing one port with NTP and PTP might have some advantages, but I
suspect it's more likely that people will want to use two different
implementations that cannot share the port.

--
Miroslav Lichvar

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp