Re: [Ntp] NTS Pools

[[e-mail]]

Hello Dieter,

yes, you are right. :)
Thanks for your clarification.

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]
__________________________________________



Von:    "\"Dr. Dieter Sibold\"" <[e-mail]>
An:     [e-mail]
Kopie:  "David Venhoek" <[e-mail]>, "NTP WG" <[e-mail]>, 
[e-mail], [e-mail], "Rainer Bermbach" 
<[e-mail]>
Datum:  22.02.2024 16:44
Betreff:        Re: [Ntp] NTS Pools



Hi Martin,

thanks for your thought an NTS protected NTP pools.

Please find comments below.

On 22 Feb 2024, at 15:39, martin.langer=[e-mail] wrote:

> Hi David,
>
> I was talking with Krisof Teichel, Dieter Sibold and Rainer Bermbach 
about how we should handle NTS secured NTP pools. It's not easy as there 
are different perspectives on the purpose, use cases and security 
considerations. In general, I think I can provide support from the PTB 
side, even though I have very little time for it at the moment. 
(...NTS4PTP is very time consuming)
>
> I also spent a lot of time thinking about this and discussed the 
possibilities intensively with Rainer Bermbach. The main results are 
described in my recently published dissertation [
https://leopard.tu-braunschweig.de/servlets/MCRFileNodeServlet/dbbs_derivate_00053439/Diss_Langer_Martin.pdf
, Chapter 4.2]. I would like to give you a brief overview here. First of 
all: NTS4PTP already solves this problem for PTP and provides an NTS 
subprotocol that can also be used for NTP (more details below).
>
>
>
> My personal goal
> -----------------------------------
> From my point of view, I would like to see the communication between the 
NTS-KE server and the NTS capable NTP server defined. Especially in large 
local networks, a central NTS-KE server could be set up which, similar to 
the NTP pool, assigns the known NTP servers to the requesting clients. 
This way an admin can connect any number of NTP servers to the NTS-KE 
server without having to reconfigure any NTP client.
>
> However, I would NOT want to change public NTP pools, as this is not 
absolutely necessary to provide NTS-secured NTP. Depending on the 
implementation approach, there are different advantages/disadvantages and 
challenges (see below).
>
>
>
> Use Case and Security Considerations
> --------------------------------------------------------------------
> The biggest question is who wants to use NTS-secured NTP pools and what 
security promises should be fulfilled. If someone wants "secure time or 
secure time synchronization", then NTS-secured NTP pools do not provide 
it. Although NTS secures the communication between the NTP client and NTP 
server, it does not provide any indication as to whether the time server 
itself is trustworthy. So it makes a difference whether I intentionally 
add 1, 2 or 3 NTS-capable time servers in the NTP configuration, or 
whether I hand over control and let some be assigned to me at random. 
...you should at least always keep this in mind.
>From my point of view we carefully should differentiate between secured 
time synchronisation and trustworthy time sources. So my claim would be: 
Usage of NTS for NTP pools would indeed increase security of time 
exchanges. However, the question of trust in the member of the NTP pools 
remains unsolved. I don?t think that this can be solved by enhancing NTS. 
I would suppose that the question of trust is to be solved independently 
from NTS. In many respects that?s similar to HTTPS, where you need TLS to 
secure exchange of information and a PKI to establish trust in the Web 
server.


>
>
> NTS pool solution approach 1: The simplest variant: ...do nothing.
> 
---------------------------------------------------------------------------
> You could simply provide the NTP pools with NTS-capable NTP servers. 
When a client receives different IP addresses for NTP servers, it can 
simply check via TCP port 4460 if an NTS-KE server is present. If so, it 
will perform the key establishment protocol for the corresponding NTP 
server. This is also more secure, since no central NTS-KE server is 
involved in the key negotiation. ...NTP pools could possibly be modified 
to signal which NTP servers are capable of NTS, or a client could 
explicitly ask for NTS capable NTP servers. The only disadvantage is that 
the client has to perform several TLS handshakes... but this should be 
acceptable.
>
>
> NTS pool solution approach 2: central NTS-KE server
> --------------------------------------------------------------------
> This method gives the NTS-KE server the ability to assign NTP servers 
and also to implement other services such as load control. NTS for NTP 
already provides mechanisms for port and IP negotiation. However, there 
are a number of challenges to be addressed.
>
>
> 1: Time server registration
> ------------------------------------------------------
> The communication between the NTS-KE server and the NTP server has to be 
defined. Since the NTS-KE protocol does not include message type 
detection, another NTS subprotocol is required. I have done this in 
NTS4PTP, which can also be easily extended for NTP.
>
> 2: Authorization
> ---------------------------------
> In short, the question of who can register with a central NTS-KE server 
and who issues the certificates. If this is not a question, then of course 
anyone can provide an NTS-secured NTP server. ...this goes back to the 
question of trust in the time server.
>
> 3. cookie format
> ---------------------------------
> If the NTS-KE server generates cookies, the cookie format has to be 
defined. The cookie format described in RFC8915 is currently recommended. 
Deviations are therefore allowed. Although all known NTS implementations 
follow this format, they all differ in field length and byte order and are 
therefore not compatible!
>
> 4. nonce collisions / key recovery
> ---------------------------------------------------
> If the NTS-KE server and the NTP server are separated, it must be 
ensured that both sides do not accidentally use the same key with the same 
nonce, otherwise a key recovery is possible. Either the nonce generation 
has to be regulated or we need 2 master keys.
>
> 5. miscellaneous
> --------------------------------------------
> Then there are many more questions:
> - Keeping the TLS channel open for multiple requests (you solved this 
with the keep-alive record; I solved it without a record based on timeouts 
and 'close_notify')
> - Heartbeat messages for NTP servers
> - Registration revocation mechanisms for NTP servers
> - possibly data synchronization between NTS-KE servers (for resilience)
> - ...
>
>
> ..so just my thoughts
>
> have a nice day.
>
> kind regards,
> Martin
>
>
>
> PS: there is an error in my thesis (chapter 4.2.5): we have no Source 
PortIdentity in NTP ..so ignore it ;)
>
>
> __________________________________________
> 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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp