Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

[Heiko Gerstung <[e-mail]>]

Hi WG,

 

I would agree that we should stay as close as possible to NTS4NTP here. I propose to focus on unicast first, as this is closer to the NTS4NTP use case and “easier” to protect than Multicast communication. 

 

Securing multicast NTP and PTP is for sure a different beast. As multicast is the prevalent mode of operation for PTP, I would expect that once we found a good solution for PTP in the future, we can adopt this for Multicast NTP as well. And vice versa, since Unicast is the prevalent modus operandi for NTP, we should re-use what has been already developed here for PTP. 

 

My proposal would be to use exactly the same NTS mechanisms for unicast PTP that we use for NTP, with one addition:

 
First step is, just like with NTS4NTP, to run the NTS-KE procedure between the NTS/PTP client and the NTS-KE server to allow the client to obtain a number of cookies.
Then, use those cookies when running the unicast message negotiation between the NTS/PTP client and the Unicast PTP grandmaster. 
 

As far as I can see, up until this point the mechanism can be very similar to NTS4NTP. We most probably need a different cookie format, but the rest should be OK. Once we did 1 + 2, the unicast master will start the PTP packet transmission to the authenticated (via the cookie) PTP client. The client will also start sending Delay Req packets and requires the GM to respond with unicast delay responses. 

 

During this packet transmission phase I propose to use the S2C to secure the packets from the GM to the client (ANNOUNCE, SYNC, DELAY_RESP) and the C2S key to secure the packets from the NTS/PTP client to the GM (i.e. DELAY_REQ). 

 

The question is how often we need to change the S2C and C2S keys to avoid that some MITM gets enough time to break the keys before they change. As far as I understood, those keys are part of the cookie and could change in every cookie. That would result in the NTS/PTP client to use a different key after every successful unicast negotiation, something that happens very frequently (and can be configured / chosen by the client). 

 

This way we could support higher packet rates without any problems as the cookie-secured communication would be limited to the unicast negotiation phase.

 

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

 

 

 

Von: ntp <[e-mail]> im Auftrag von "Langer, Martin" <[e-mail]>
Datum: Sonntag, 7. März 2021 um 18:06
An: Watson Ladd <[e-mail]>, NTP WG <[e-mail]>
Betreff: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

 

Hello Watson,

first of all thank you very much for the feedback. It is a challenge for me to design 

the protocol. NTS4PTP is much more complex than NTS4NTP because the requirements 

are very different. Tomorrow there will probably be an update of the draft which will 

include the missing chapters. Here once briefly my comments to your feedback:

1) ..."first concern is that this draft doesn't play nicely with NTS"...
The message/communication structure is indeed a problem. While with NTP we only 

have a generic request/response to the NTS-KE, with PTP I have to distinguish between 

different message types (e.g. unicast/multicast). While with NTS4NTP the communication 

between time server and NTS-KE is implementation specific, with NTS4PTP it has to be 

defined. This makes it more complex and currently collides with the "NTS Next Protocol 

Negotiatin" record. I am open to any suggestions.


2) ..."second concern is cryptographic"...
For keys, we need to distinguish between multicast and unicast. For multicast we use 

a group key. This has to be generated, distributed and managed accordingly by the 

NTS-KE. A derivation from the TLS session would therefore not be possible, since all 

participants need the same key. 

With unicast it would be possible, but it makes it more complicated. Theoretically a PTP 

client ('requester') can get up to 10 security associations per request, depending on the 

PTP profile. The transport of the security parameters to the grantor (e.g. PTP time server) 

is done via an encrypted ticket (similar to the cookie in NTP). The cookie solution as with 

NTP cannot be applied to PTP, because the message rate is much higher in PTP and the 

grantor is stateful. So tracking protection and parameter outsourcing are not needed. 

The keys all have a certain lifetime and have to be updated periodically. For NTS4PTP 

this is done by the NTS-KE. With NTS4NTP it is done by the time server. But I still see a 

problem with NTS4NTP: The MasterKey is rotated, S2C and C2S are not. This contradicts 

a bit the key freshness (if I am right).


But here's a question: in what way is it worse to generate a random number (CSPRNG) 

instead of deriving it from the TLS connection (TLS Key Exporter)?


3) ..."Group keys have weaker authentication"...
Yes, with a group key we have poor source authentication. To solve this we would need 

an approach with asymmetric cryptography (slow) or delayed key disclosure like TESLA 

(vulnerable and complex). I don't know of any better alternatives.


... anyway, thank you very much. Tuesday I'm unfortunately not at the IETF meeting due to an exam.

best regards,

Martin

 

-------------------

Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel.: [phone]
Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer

 

Von: ntp <[e-mail]> im Auftrag von Watson Ladd <[e-mail]>
Gesendet: Freitag, 5. März 2021 20:55:22
An: NTP WG
Betreff: [Ntp] Comments on draft-langer-ntp-nts-for-ptp 

 

Dear WG,

I recognize that this is a pretty early draft and so I'm going to
focus on the aspects that are outlined that I think may be
problematic, rather than nitpick the clear and well written, although
somewhat incomplete text.

My first concern is that this draft doesn't play nicely with NTS. NTS
doesn't have a hierarchical record structure defined, deliberately to
avoid a well-trod class of security and correctness issues. An NTS way
to do this would be to unmake the PTP key grant structure and send a
NTP Next Protocol Negotiation field directly, and use new noncritical
PTP server or group negotiation messages. Obviously it's a bit
complicated by the layering of PTP.

My second concern is cryptographic. Instead of deriving the key from
the TLS handshake, the server sets it. We didn't do this in NTS for
NTP for a reason. The way we do forced key rotations is by getting new
tickets.

Group keys have weaker authentication and security properties than a
tree of unicast associations.

I think this is an important draft that covers a real usecase, but
should try to break the flow of NTS a bit less. I hope these comments
are useful.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

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

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