[Ntp] Antwort: NTS for PTP feedback

[[e-mail]]

Hi David,

Thanks for your interest and feedback. It's great to hear that another

implementation is coming. The current draft version-06 will be updated

in 2 weeks at the latest. Many small changes or corrections have been

made. However, there are still some issues that are not yet included or

specified in the draft.

Major issues
---------------
In section 2.1, the draft states: "THEN the server requests the
client's X.509 certificate (via TLS Certificate Request)" (emphasis
added), after data is already exchanged over the TLS session. Since
TLS 1.3 there is no longer any support for a renegotiation during a
TLS session, hence this seems to not be possible within the TLS spec.
Do you mean that before honoring the request the server should check
that the client authenticated with a valid certificate during the
initial handshake?

Yes, this sentence is incorrect and will be corrected. However, the procedure

is basically correct. When an NTS-KE server receives a request for the NTS-KE

protocol, it only sees after parsing the NTS message whether the request should

be for NTS-secured NTP (RFC8915) or NTS-secured PTP. No client authentication

is required for NTP, but it is required for PTP. Originally, post-handshake

authentication (PHA) was intended for this in TLSv1.3, which was designed for

just such a case. However, this makes the protocol process a bit more complex,

and OpenSSL still showed some bugs here.

The current solution is simpler: When an NTP/PTP client makes a request to the

NTS-KE server, the NTS-KE server requests a certificate. The TLS server simply

sends a CertificateRequest to the client during the TLS handshake. However, the

client is free to send a certificate, so there is no conflict with RFC8915. After

evaluating the NTS request, it is then possible to check whether the client has

been successfully authenticated or not.

Section 2.1.1 refers to "The group number", but this is neither
defined in the PTP specification, nor earlier in this document. What
is it? it seems to be very similar to the SPP defined in
IEEE1588-2019, why do we need it?

I have noted this. It will be emphasized in future draft versions.

The group number is a concatenation of PTP domain, SdoId, and an optional

user-defined value. This ensures that separate keys are used in a physical network

with multiple logical PTP networks. A logical PTP network thus represents a "group".

The group number ensures that PTP devices can only check/verify the PTP messages

of their own group. ...the term "group number" is not defined in IEEE 1588, only in my draft.

The 'optional user-defined value' allows to create further subgroups in a PTP network

(PTP domain + SdoId). If you only want to use the multicast approach, but still need

some PTP unicast connections that should be secured with a separate key, then this

is possible. This can also be used with transparent clocks to keep using correction fields).

The SPP in the PTP Authentication TLV does not really work because the field is way too

small. Almost all fields in the Authentication TLV have problems. These will have to be

discussed with IEEE 1588 or I will have to define my own PTP TLV.

The fields in section 3.2.11 are not aligned. This can be problematic
when implementing on platforms like ARM.

Yes, this is correct. I've thought about it a few times and decided against it so far

because I didn't see any significant drawback. Of course, I could use memory alignment

to align all values to DWORD length (4 octets). So a processor would read the values

faster at the expense of memory. However, we are talking about very few CPU clock cycles

here, which is not really significant from a performance point of view in this NTS phase.

I know that NTS has some fields aligned to 4 octets and that PTP and TLS do not. I also

don't see any difficulties from a byte order perspective (big endian/little endian).

What specific problems would there be with ARM?

Per 16.14.2 of IEEE1588-2019, the key management mechanism should
provide a sequenceID window, but the specification doesn't state how
this is provided.

This is correct. The draft does not yet include a section on replay protection. There are

several reasons for this. First, PTP messages have their own sequence number. However,

this is not under the control of NTS, and secondly, this sequence number is too small. At

a maximum message rate of 128 PTP messages per second, the PTP field would overflow

after 8m 32s. According to the PTP standard, the free field in the Authentication TLV must

not be used. We are still considering whether to adapt the PTP standard or use a separate

NTS TLV.

Sequence numbers are used for replay protection, although a decision has not yet been

made. You could implement it as in IPSec (RFC 6479) and use a SeqNoWindow, or you

could simplify it and reduce it to ascending numbers. The first approach makes the protocol

more complex again, but allows PTP messages to arrive in the incorrect order

(within the window) if they have not already been received. The second approach is much

simpler and does not require a window. You just have to make sure that there is no overflow.

Here we reset the SeqNo. after a key update.

From my point of view, it is not critical if NTS discards the PTP packets that arrive in the

wrong order, because PTP would also do this and this is extremely rare.

Exceptions are request/response messages where random numbers are used in the request

messages and returned in the response messages (as in NTS-for-NTP with the UID).

...This part will be added in future draft versions.

General remarks
-------------------------
Draft allocates concrete numbers in ranges not reserved for
experimental or private use, rather than waiting for IANA assignment.
I would suggest removing the concrete values for now, suggesting
experimental use numbers for draft implementations.

Yes, this will follow at the latest when the document becomes an official WG document.

Draft repeats the same subject multiple times and is in general quite
all over the place.

Some text needs to be updated and some shortened. This is due to the growth of

the document. I understand that the draft is still too complex, especially for first-time

readers. This will be further improved in subsequent releases.

General language use around the "messages" is unclear. What is a
message, what is a record structure in this context?

It is actually not easy to separate this language, as there are "NTS messages for the

PTP protocol" and "NTS-secured PTP messages". An NTS message is not a single data

structure with fixed fields, but a combination of records. Records are similar to TLVs

(type-length-value) and can appear in any order in the message (...except for the

'End of Message' record).

There also seems a lot of repetition of structures and information
already standardised in other specifications. I would suggest mostly
removing this and refering to the relevant specifications. In
particular, I would avoid including full tables of identifiers defined
accross multiple standards.

Some of the text parts in chapter 3 have already been shortened, and of course they

need to be optimized continuously. I assume that the repetitions refer to NTS-for-NTP.

This is not easy. Many structures are derived from this RFC, since my draft is intended

to add the PTP protocol to the existing NTS. In many structures and contents some

rules are different between NTP and PTP, and of course I have to emphasize them.

But I will see which parts of the text can be excluded in future versions. In the

upcoming version I will not be able to take this into account yet.

thank you very much and have a nice weekend.

kind regards,

Martin

__________________________________________
Dr.-Ing. Martin Langer
Physikalisch-Technische Bundesanstalt (PTB)
Working Group 4.42 "Dissemination of Time"
Bundesallee 100,
38116 Braunschweig (Germany)
Tel.: [phone]
E-Mail: [e-mail]
__________________________________________

-----"ntp" <[e-mail]> schrieb: -----

>An: "NTP WG" <[e-mail]>
>Von: "David Venhoek" <[e-mail]>
>Gesendet von: "ntp" <[e-mail]>
>Datum: 01.02.2024 15:46
>Betreff: [Ntp] NTS for PTP feedback
>
>Hi All,
>
>I've worked through the nts for ptp draft today in preparation for
>also making a proof of concept implementation in statime. Below a
>number of comments on the current draft. Note that my focus currently
>was on multicast only, so I haven't looked in detail yet at the
>unicast-specific parts.
>
>Kind regards,
>David Venhoek
>
>Major issues
>---------------
>In section 2.1, the draft states: "THEN the server requests the
>client's X.509 certificate (via TLS Certificate Request)" (emphasis
>added), after data is already exchanged over the TLS session. Since
>TLS 1.3 there is no longer any support for a renegotiation during a
>TLS session, hence this seems to not be possible within the TLS spec.
>Do you mean that before honoring the request the server should check
>that the client authenticated with a valid certificate during the
>initial handshake?
>
>Section 2.1.1 refers to "The group number", but this is neither
>defined in the PTP specification, nor earlier in this document. What
>is it? it seems to be very similar to the SPP defined in
>IEEE1588-2019, why do we need it?
>
>The fields in section 3.2.11 are not aligned. This can be problematic
>when implementing on platforms like ARM.
>
>Per 16.14.2 of IEEE1588-2019, the key management mechanism should
>provide a sequenceID window, but the specification doesn't state how
>this is provided.
>
>General remarks
>-------------------------
>Draft allocates concrete numbers in ranges not reserved for
>experimental or private use, rather than waiting for IANA assignment.
>I would suggest removing the concrete values for now, suggesting
>experimental use numbers for draft implementations.
>
>Draft repeats the same subject multiple times and is in general quite
>all over the place.
>
>General language use around the "messages" is unclear. What is a
>message, what is a record structure in this context?
>
>There also seems a lot of repetition of structures and information
>already standardised in other specifications. I would suggest mostly
>removing this and refering to the relevant specifications. In
>particular, I would avoid including full tables of identifiers
>defined
>accross multiple standards.
>
>_______________________________________________
>ntp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ntp" target="_blank" rel="noopener noreferrer nofollow">https://www.ietf.org/mailman/listinfo/ntp
>