As evolving security concerns have prevailed, the network time synchronization protocol community has been actively engaged in the development of improved security mechanisms for both the IEEE 1588 Precision Time Protocol (PTP) and the IETF Network Time Protocol (NTP). These activities have matured to the point where this year should see the finalization of the first new security mechanisms for time protocols in ten years. This paper provides an overview of the two solutions being developed, compares and contrasts those solutions, and discusses relevant use cases and deployment scenarios.

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

6. IEEE 1588 Security
6

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