A Security Analysis of Version 2 of the Network Time Protocol NTP Matt Bishop

1. A Security Analysis of Version 2 of the Network Time Protocol NTPMatt Bishop Presented by Alexander Gorman

2. Goal of Paper • Examine the security requirements of the Network Time Protocol (version 2) • Determine if version 2 meets requirements • Suggest Improvements

3. My Goals • Describe version 2 of NTP • Analyze attacks • Improvements

4. Attacks • Masquerade • Modification • Replay • DoS • Delay

5. Assumptions • Messages leave source uncorrupted • Not altered on arrival • Focus on transmission

6. NTP • NTP = Network Time Protocol • Primary time servers • Secondary time servers • Stratum Number • Measure distance from primary to secondary time server

7. NTP Top level stratum Primary Level 2 stratum B A Level 3 Stratum C

8. NTP Rules • Primary time servers synchronized by external system • Secondary time servers synchronized by: • Primary time server • Another secondary time server with lower stratum number

9. Association Modes Non-Server sync with NTP Server • Client • What time is it? • Send msgs to peers • Server • Created when received client msg • Responds with server’s time, terminates • Broadcast • Sends periodic time messages

10. Association Modes Time Server sync with other Time Servers • Symmetric active • Broadcast sync msgs • Symmetric passive • If sender strata > receiver, reply + terminate • Else, sender syncs host and receiver responds with time msg of its own. Note: Normally servers with high strata run in active mode

11. Smooth Data • Improve accuracy Algorithm 1 • Compute roundtrip delay and offset • Take sample from last 8 msgs • Choose lowest delay and use associated offset as estimated clock offset • Estimate sample dispersion

12. Offset and Delay ti-3 ti-2 Local Server Remote Server ti-1 ti Ci = ((ti-2 - ti-3) + (ti-1 – ti)) / 2 Di = (ti – ti-3) + (ti-1 – ti-2)

13. Selection of Source Peer • Algorithm 2 • Who should sync clock? • Uses Algorithm 1 • List is sorted and scanned repeatedly • Clock dispersion relative to peer is computed • Highest dispersion eliminated • Only one source left

14. Receive and Packet Procedures • When a msg (packet) is received either • Error: packet discarded, association deleted • Packet Procedure

15. Packet Procedures if (time packet transmitted=time last received packet transmitted) then sanity := true; if (time peer received last packet from host<>time last message sent to peer) then sanity := true; (*update association variables in Figure 3*) if (peer clock not synchronized) or (peer clock not updated for 1 day) then sanity := true; if (not authenticated correctly) then sanity := true; if (peer not preconfigured) and (packet’s stratum>peer’s stratum) then sanity := true; if sanity then (*discard message and exit*) if (packet originate timestamp= 0) or (time last message received by peer= 0) then (*exit; note sanity flag not set*) (*compute delay, offset, corrections, update local clock*)

16. Packet Procedures • Check • Eliminate re-transmitted packets • Packet not transmitted at the same time as the last one received from that peer • Ensure messages are received in order • The last packet received from the local host was indeed the one the local host sent to the peer • Peer clock is synchronized correctly • Packet is authenticated correctly • Packet is preconfigured correctly and • Packet’s stratum level > peer’s stratum level FAIL

17. Packet Procedure • If successful • Resets internal variables • Adjusts local clock if necessary • Possibly select new peer as clock source

18. Security Mechanisms • Delay Compensation • Access Control • Authentication

19. Delay Compensation • Compensate for network delays • Algorithm calculates roundtrip delay and clock offset relative to peer • Applies statistical procedure to update clock (see book Network Time Protocol (Version 2) Specification and Implementation)

20. Access Control • All hosts partitioned into 3 groups • Trusted • Allowed to synchronize the local clock • Either preconfigured or based on trusted ticket service (Kerberos) • Friendly • Sent NTP msgs and timestamps when needed • Cannot change local clock • Others • Messages from this group are ignored

21. Authentication • Covers Authentication and integrity • Packet in authenticated mode • Transmitted • NTP packet (except for authenticator) is checksummed using active peer’s key • Key depends on mode

22. Authentication if peer.config = 0 then if(authenticator in message data) then peer.authenable := 1 else peer.authenable := 0; if peer.authenable =1 then begin peer.authentic := 0; if (authenticator in message data) then begin peer.keyid := packet.keyid; compute_mac(mac, peer.keyid, packet); if peer.keyid <> 0 and mac = packet.check then peer.authentic := 1; end; end; (*if peer.authenable is 0, authentication is not done;*) (*otherwise if peer.authentic is 0, the integrity of the *) (*packet’s contents are suspect*)

23. Authentication • Packet Received • If msg contains authentication info • Index # of peer’s key reset to that in packet • Checksum recomputed and compared to transmitted checksum • If checksums match check succeeds • If packet has no authentication info • Check fails, routine exits

24. Analysis of Security • Analyze the following: • Access Control • Authentication

25. Access Control • Relies completely on an unauthenticated source address (in the absence of an integrity checking mechanism) • Solution: routing info • IP record route

26. Authentication • Key index can be altered • Check is only 64bits • No key distribution mechanism defined • Keys used on a per host basis • Could lead to a compromise of all hosts that peer synchronizes

27. Attacks • Goal • Attack • Effect • Countermeasure

28. Masquerade • Goal • Convince timekeeper that attacker is authorized to synchronize it • Attack • Send a victim packets with source address of timekeeper • Effects • If host is known • None if change is drastic • Drift created if timestamps changed gradually • Unknown host • Compromise server by sending 8 uninterrupted messages • Send msgs claiming low stratum number • Countermeasure • Use authentication • Do not allow non-preconfigured peer to become clock source

29. Message Modification • Goal • Alter msgs from one timekeeper to another to cause incorrect synchronization • Attack • Alter packets sent to victim • Different types of attacks

30. Modification Attacks • Integrity the recipient’s clock • pkt.rec, pkt.xmt, pkt.precision • Change round trip delay

31. Modification Attack

32. Modification • Countermeasures • Use Authentication! • Stratum level used only if checks pass • Access controls indicate if connection is trusted

33. Replay • Goal • Intercept + resend NTP msgs to cause recipient to incorrectly resynchronize • Disable active association • Attack • Record msgs + replay them later • Effects • Alternate and replay • Reset local clock to earlier time • Counter • Reject any msg with a timestamp older last msg received • Create a special msg when clock needs to be changed backwards • Route based

34. Delay • Goal • Cause incorrect resynchronization • Disable active association • Attack • Artificially increase the roundtrip delay of an association • Effects • Delay packets in sample • Peer sending packets not source • Results in having no source, DoS • Counter • Redundancy of clock sources

35. DoS • Goal • Prevent NTP msgs from one timekeeper to another • Attack • Prevent packets from clock sources from reaching an NTP host • Effects • Forces NTP to run under its own clock, high drift! • Counter • Redundancy of clock sources

36. Combined Attack • Very effective • E.g. Deny a secondary server from all but one source, and delay packets from source • To counter, deal with each component attack separately

37. Suggestions • Internal Mechanisms • Assume no underlying security mechanism • Always use Authentication • Keys used per-path not per-host • Base Access Control on recorded routes • Change variables after packet passes checks • Further restrict values of variables • Increase sample size • Require special packet to set clock backwards • Redundancy, server should have many sources

38. Suggestions • External • Secure transmission • Run into problems with this scheme • Public-key checksum - Too slow! • IP does not provide sufficient security • Strict source does not work!

39. Conclusion • NTP has some weaknesses, but well designed • Remember, security analyst’s view • May or may not impact goals of protocol

40. Questions?