New Security Mechanisms for Network Time Synchronization Protocols
2 likes1,547 views
The document discusses the necessity for enhanced security mechanisms in time synchronization protocols due to rising interconnectivity and vulnerabilities. It outlines current frameworks like IEEE 1588 and NTP, their existing flaws, and proposed security strategies including PTP integrated security, external transport security, and monitoring guidance. The document concludes with the next steps for finalizing specifications and improving best practices in securing time synchronization protocols.
New Security Mechanisms for Network Time Synchronization Protocols
- 1. Internet Society © 1992–2016 Karen O’Donoghue, Steffen Fries and Dieter Sibold ISPCS 2017, Monterey, CA New Security Mechanisms for Network Time Synchronization Protocols 1 September 2017 1
- 2. Agenda • Setting the stage… • Why Now? • Requirements • What currently exists? • IEEE 1588 • IETF NTP • Next steps and parting thoughts… 2
- 3. Why Security Now? • Security has not been a high priority of the time synchronization in the past… • What has changed... • Increasing interconnection and decentralization • Increasing evidence of the impact of inadequate security • Interdependency between security and time • Legal and Compliance requirements 3
- 4. Requirements for Time Synchronization Security 4
- 5. What currently exists? • IEEE 1588 Precision Time Protocol (PTP) • Annex K – Group source authentication, message integrity, and replay attack protection (defined as Experimental, flaws identified) • Network Time Protocol (NTP) • Pre-shared key scheme for server authentication in the core specification (scaling issues) • Autokey – Authentication of time servers using PKI (known flaws) 5
- 7. IEEE 1588 Security Approach • IEEE 1588 security will include a set of mechanisms and tools that can be used together or individually. • Individual mechanisms will be optional. • The specific mechanisms chosen will vary by application and environment. • Expect future profile development in this area • Caveat emptor!!! (This is still in DRAFT at this point!) 7
- 8. IEEE 1588 Security • The multi-pronged approach: • PTP Integrated Security Mechanisms (Prong A) • External Transport Security Mechanisms (Prong B) • Architecture Guidance (Prong C) • Monitoring and Management Guidance (Prong D) 8
- 9. Transport Trailer PTP PayloadPTP Header Transport Header 0 or more TLVs Security TLVS I C V Security Indication in the PTP Header to signal the support of a security TLV (re-using former Annex K field) Security TLV, structured to support different key management options Integrity Check Value (ICV) providing integrity protection for marked PTP packet area Utilized common header information: - sourcePortIdentity - sequenceNo PTP Integrated Security Mechanism (Prong A) • TLV definition and processing rules (normative but optional) • Information on example key management schemes (informative) • Future specification of specific key management schemes in IETF
- 10. PTP Integrated Security Mechanism (Prong A): PTP Security TLV 10 SPP secParam Indicator disclosedKey (optional) Security Parameter Pointer ICV Key Identifier or Current Key Time Interval depending on verification scheme Disclosed key from prior period (optional) LengthtlvType TLV Type TLV Length Information RES ICV based on algorithm OID Sequence number sequenceNo (optional) keyID Security Parameter Indicator Reserved (optional)
- 11. Key Management (therein lies the rub…) • Static key distribution by some form of out of band mechanism • Good for getting started but not a long term solution • Instant key sharing (GDOI) • Delayed key sharing (TESLA) 11
- 12. PTP Instance A SUBSCRIBE – A authenticates and applies for membership in specific group PTP Instance B Group PUBLISH – After successful authentication of A, the KDC sends the specific group parameters for the SA to A PTP Data Exchange secured using Key with Key-ID for calculating the ICV in the securityTLV SUBSCRIBE – B authenticates and applies for membership in specific group PUBLISH – After successful authentication of B, the KDC sends the specific group parameters for the SA to B Key Distribution Center (KDC) •pre-configured PTP Instance access list •generates data stream related (group) keys •May by co-located witn a PTP Instance Instant key sharing using GDOI
- 13. Delayed key sharing using TESLA 13 PTP Instance Master PTP PTP Message (X361 used for ICV) Secret Start Value: X0 Hash-Chain-Anchor: X364 Validation Code: X1 … X363 X0 X1 X2 … X361 X362 X363 X364 Start Day 363 Day 362 Day 3 Day 2 Day 1 Hash- Value Chain-Anchor X0 is the Secret Start Value X1 = Hash(X0) X2 = Hash(X1) … X364 = Hash(X363) are the Validation Codes X364 is the Hash-Chain-Anchor signed by the Master Clock Release X361 Distribute X.364Verify signature of X.364, Store X.364 for later verifications of calidation codes ... Verifies if X.363 = h(X.364) Yeas: Stores X.363 Verify stored packets Store packet
- 14. External Transport Security Mechanisms (Prong B) • MACSec • Based on IEEE 802.1AE Media Access Control (MAC) Security • Integrity protection between two IEEE 802 ports • Key management is manual or based on MACsec Key Agreement (MKA) specified in IEEE 802.1X-2010. • IPSec • Base architecture defined in IETF RFC 4301 • Node authentication and key exchange defined in RFC 7296 • Integrity checking and encryption of data defined in RFC 4303 14
- 15. Architecture Guidance (Prong C) • Redundancy • Redundant timing systems • Redundant PTP grandmasters • Redundant paths 15 Monitoring and Management Guidance (Prong D) • Definition of parameters in IEEE 1588 data sets that can be monitored to detect security problems • A recommendation to not use unsecure management protocols including IEEE 1588 native management … and Best Practices!
- 16. NTP Security 16
- 17. Network Time Protocol Security Problems… • Sources of recent NTP security issues • Flaws in configuration and implementation (BCP) • Weaknesses in the protocol (protocol tweaks/clarifications) • Lack of an adequate security mechanism (NTS) 17
- 18. Network Time Security (NTS) provides… • NTS for NTP: draft-ietf-ntp-using-nts-for-ntp • Integrity for NTP packets (not confidentiality) • Unlinkability (once an NTS session has been established and if the client uses data minimization techniques) • Request-Response consistency (for avoiding replay attacks) • Authentication of servers • Authorization of clients (optionally) • Support for client-server, symmetric peer, and control modes (broadcast mode not currently supported) • Caveat emptor!!! (This is not published (done) yet… ) 18
- 19. (D)TLS for NTP Security Ø NTS-encapsulated NTPv4 § NTP over DTLS: DTLS handshake followed by NTP encapsulated as DTLS § Most suitable for symmetric and control modes Ø NTS Key Establishment protocol (NTS-KE) § TLS to establish key material and negotiate some additional protocol options Ø NTS extensions for NTPv4 § A collection of NTP extension fields for cryptographically securing NTPv4 using key material previously negotiated using NTS-KE. § Suitable for client/server mode 19
- 20. NTP Extension Fields to support NTS • NTS Unique-Identifier extension: • A 32-octet random value which serves as nonce and protects the client against replay attacks. • NTS Cookie extension: • Information that enables the server upon receipt to re-calculate keys. The server therefore does not have to keep per-client state. This EF is opaque to the client. • NTS Cookie Placeholder extension: • Sent whenever the client wishes to receive a new cookie. The server has to send an NTS Cookie extension for each received NTS Cookie Placeholder extension. This EF enables NTS to fulfill the unlinkability requirement. • NTS Authenticator and Encrypted Extensions extension: • Contains the ICV which is computed over the NTP header and any preceding EF. It is calculated by applying the Authenticated Encryption with Associated Data approach. 20
- 21. So, where are we with NTS? In working group last call – active discussion on mailing list… • 1 – 27 August : 28 messages (~1 message per day) • Since 27 August: 81 messages (~20 messages per day)
- 22. NTP Best Practices • There are a number of best practices that when applied to systems can improve their security posture. • Proposed BCP: draft-ietf-ntp-bcp 22
- 23. Updated MAC for NTP 23 • Speaking of algorithm agility… • Proposed Standard: Message Authentication Code for the Network Time Protocol • Replaces MD5 with AES-CMAC
- 24. NTP Client Data Minimization 24 • Remove unnecessary client information • Improve resilience against spoofing
- 25. Next steps and parting thoughts… 25
- 26. Next Steps • NTS • Finalize NTS for NTP specification • Publish BCP • Publish MAC update • Clean up protocol issues • Data minimization • Extension field clarifications • REFID updates • IEEE 1588 • Complete proposal for next revision of IEEE 1588 • Continue specification of key management options 26
- 27. Final remarks • Why has this been so hard? • When will we be done? • Hopefully these two solutions will eventually be somewhat aligned to help facilitate development, deployment, and operation! • Contact me if you are interested in helping: • Karen O’Donoghue, odonoghue@isoc.org 27
- 28. Acknowledgements and Thanks… Co-authors: Steffen Fries and Dieter Sibold IEEE 1588 Contributors: Steffen Fries, Dieter Sibold, Tal Mizrahi, Jeff Dunn, Doug Arnold, Stefano Ruffini, John Eidson, Opher Ronen, Silvana Rodriques, Bill Dickerson, Mikael Johansson, … NTP Contributors: Harlan Stenn, David Mills, Denis Reilly, Danny Mayer, Sharon Goldberg, Aanchal Malhotra, Daniel Franke, Rich Salz, Miroslav Lichvar, Dieter Sibold, Kristof Teichel, Russ Housley, … … and many more that I have neglected to mention here… … it really does take a village… 28
- 29. Thank you. Visit us at www.internetsociety.org Follow us @internetsociety Galerie Jean-Malbuisson 15, CH-1204 Geneva, Switzerland. +41 22 807 1444 1775 Wiehle Avenue, Suite 201, Reston, VA 20190-5108 USA. +1 703 439 2120 Karen O’Donoghue Research Analyst odonoghue@isoc.org 29
- 30. Backup Slides 30
- 31. RFC 7384: Threats • Manipulation of time synchronization packets, • Masquerading as a legitimate participant in the time synchronization protocol, • Replay of legitimate packets, • Tricking nodes into believing time from the wrong master, • Intercepting and removing valid synchronization packets, • Delaying legitimate time synchronization packets on the network, • Denial of service attacks on the network at layer 2 and layer 3, • Denial of service by overloading the cryptographic processing components, • Denial of service by overloading the time synchronization protocol, • Corruption of the time source used by the grand master, • Protocol design and implementation vulnerabilities, and • Using the time synchronization protocol for broader network surveillance and fingerprinting types of activities. 31
- 32. RFC 7384: Requirements • Authentication and authorization of a clock’s identity, • Integrity of the time synchronization protocol messages, • Prevention of various spoofing techniques, • Protection against Denial of Service (availability), • Protection against packet replay, • Timely refreshing of cryptographic keys, • Support for both unicast and multicast security associations, • Minimal impact on synchronization performance, • Confidentiality of the data in the time synchronization messages, • Protection against packet delay and interception, and • Operation in a mixed secure and non-secure environment. 32