Network Time Security (NTS)

1. Network Time Security (NTS) A short introduction to NTS in order to scrutinize its applicability for IEEE 1588 Dieter Sibold 2014-01-14

2. Overview • Motivation • Issues with existing authentication approaches in NTP • Vulnerabilities of autokey • Goals of NTS • Concepts of NTS • Message types • Protocol sequence • Conformity with TICTOC and IEEE 1588 security requirements D. Sibold, P1588 security subcommittee

3. Motivation • PTB is responsible for time dissemination within Germany. • Accomplished via radio transmitter (DCF77) and NTP) • Authentication is an increasing challenge for time dissemination via NTP • Demand for securely authenticated time source for a home based smart meter gateway • Measuring of energy consumption and • internal tariffing as basis for billing • Increasing number of requests for an authenticated (public) time service (legal or compliance reasons) D. Sibold, P1588 security subcommittee

4. Motivation // Issues with current security methods in NTP • RFC 1305: symmetric approach for authentication and integrity protection • Organizational effort (key exchange, …) • Compliance issues • RFC 5906: autokey as authentication and integrity protection for NTP based on asymmetric cryptography • Several vulnerabilities (S. Röttger, 2011) • Compatibility issues D. Sibold, P1588 security subcommittee

5. Motivation // Vulnerabilities of autokey MAC • Message Authentication Code • Server seed is only 32 bits long • Client can request a cookie and brute force the seed • The cookie is only 32 bits long • An adversary can capture a packet and brute force the cookie • Client Identity Check is based on the client’s IP address • An adversary can masquerade as the client and obtain the client’s cookie encrypted with his own public key. autokey cookie keyID Client & Server IP Client & Server IP NTP Packet serverseed • Authentication schemes • Challenge-Response schemes are not applied adequately. They are therefore non-effective. D. Sibold, P1588 security subcommittee

6. Objectives of NTS • Authenticity: NTS enables the client to authenticate its time server. • Integrity: NTS protects the integrity of time synchronization protocol packets via a message authentication code (MAC). • Confidentiality: NTS does not provide confidentiality • NTS shall provide End-to-Endsecurity • All operational modes of NTP shall be supported. • Operational modes of PTP should be supported as far as possible. • Hybrid mode: Both secure and insecure communication modes are possible for NTP servers and clients, respectively. • Compatibility: • Unsecured NTP associations shall not be affected. • An NTP server that does not support NTS shall not be affected by NTS authentication requests. D. Sibold, P1588 security subcommittee

7. Concept of NTS • Authentication • Certificate based authentication (self-signed or X.509) • Integrity • MAC based on a Keyed-Hashed Message Authentication Code (HMAC) • Unicast (Client-Server) mode: • For each client-server association exists an individual key called cookie, which is generated by the server and exchanged after verification of authenticity (the exchange is secured via asymmetric cryptography) • Broadcast / Multicast mode • Utilization of TESLA (RFC 4082) • MAC is generated with a key from one-way key chain. • Keys are used only once and disclosed according to a published schedule • After a key is disclosed the client verifies the corresponding packet a posteriori. D. Sibold, P1588 security subcommittee

8. Concept // Message types • NTS messages are embedded in NTP’s extension fields. • Association message: Exchange of addresses, signature algorithms and notification of the server’s supported hash algorithms • Certificate message: The client verifies the certificate of the server • Cookie message: Exchange of the cookie • Broadcast parameter exchange: The client request the parameter which are necessary for the TESLA protocol • Time request and response: The client attaches its hashed public key, a nonce and the chosen hash algorithm to the request. It receives the MAC and the nonce in an extension field of type “time response”. D. Sibold, P1588 security subcommittee

9. Concept // Message types • NTS messages are embedded in NTP’s extension fields. • Broadcast message: sent by the server. Includes the disclosed key of the previous disclosure interval and the MAC generated with the key of the current interval. • The client has to perform the following tests • Proof that the MAC is based on a key that is not yet disclosed • Verification of the buffered packets of the previous disclosure interval • (for more detail RFC 4082, TESLA) D. Sibold, P1588 security subcommittee

10. Concept // Protocol sequence // Unicast • Time Request contains • Hash algorithm h, • Hash of client‘s public key h(KC), • Nonce NC • Server action • Server re-calculates the cookie KCS • KCS= h(h(KC) || Seed) and MAC • MAC = HMAC(h; KCS,NC || Message) • The reply contains • Message, NC, MAC D. Sibold, P1588 security subcommittee

11. Concept // Protocol sequence // Broadcast/Multicast • Explanation of key and authentication check see NTS Internet-Draft or RFC 4082 D. Sibold, P1588 security subcommittee

12. Conformity with TICTOC and IEEE 1588 security requirements D. Sibold, P1588 security subcommittee

13. Conformity with TICTOC and IEEE 1588 security requirements D. Sibold, P1588 security subcommittee

14. Physikalisch-Technische Bundesanstalt Braunschweig und Berlin Bundesallee 100 38116 Braunschweig Dr. Dieter Sibold Telefon: +49 531 592-8420 E-Mail: dieter.sibold@ptb.de www.ptb.de Stand: 10/13