A Security Analysis of Version 2 of the Network Time Protocol NTP Matt Bishop Presented by Alexander Gorman

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

My Goals  Describe version 2 of NTP  Analyze attacks  Improvements

Attacks  Masquerade  Modification  Replay  DoS  Delay

Assumptions  Messages leave source uncorrupted  Not altered on arrival  Focus on transmission

NTP  NTP = Network Time Protocol  Primary time servers  Secondary time servers  Stratum Number Measure distance from primary to secondary time serverMeasure distance from primary to secondary time server

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

NTP Rules  Primary time servers synchronized by external system  Secondary time servers synchronized by: Primary time serverPrimary time server Another secondary time server with lower stratum numberAnother secondary time server with lower stratum number

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

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

Smooth Data  Improve accuracy Algorithm 1 Compute roundtrip delay and offsetCompute roundtrip delay and offset Take sample from last 8 msgsTake sample from last 8 msgs Choose lowest delay and use associated offset as estimated clock offsetChoose lowest delay and use associated offset as estimated clock offset Estimate sample dispersionEstimate sample dispersion

Offset and Delay t i-3 titi t i-2 t i-1 C i = ((t i-2 - t i-3 ) + (t i-1 – t i )) / 2 D i = (t i – t i-3 ) + (t i-1 – t i-2 )

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

Receive and Packet Procedures  When a msg (packet) is received either Error: packet discarded, association deletedError: packet discarded, association deleted Packet ProcedurePacket Procedure

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*)

Packet Procedures  Check Eliminate re-transmitted packetsEliminate re-transmitted packets  Packet not transmitted at the same time as the last one received from that peer Ensure messages are received in orderEnsure 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 correctlyPeer clock is synchronized correctly Packet is authenticated correctlyPacket is authenticated correctly Packet is preconfigured correctly andPacket is preconfigured correctly and Packet’s stratum level > peer’s stratum level FAILPacket’s stratum level > peer’s stratum level FAIL

Packet Procedure  If successful Resets internal variablesResets internal variables Adjusts local clock if necessaryAdjusts local clock if necessary Possibly select new peer as clock sourcePossibly select new peer as clock source

Security Mechanisms  Delay Compensation  Access Control  Authentication

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) (see book Network Time Protocol (Version 2) Specification and Implementation)

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

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

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; (*if peer.authenable is 0, authentication is not done;*) (*otherwise if peer.authentic is 0, the integrity of the *) (*packet’s contents are suspect*)

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

Analysis of Security  Analyze the following: Access ControlAccess Control AuthenticationAuthentication

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

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

Attacks  Goal  Attack  Effect  Countermeasure

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 drasticNone if change is drastic Drift created if timestamps changed graduallyDrift created if timestamps changed gradually  Unknown host Compromise server by sending 8 uninterrupted messagesCompromise server by sending 8 uninterrupted messages Send msgs claiming low stratum numberSend msgs claiming low stratum number  Countermeasure  Use authentication  Do not allow non-preconfigured peer to become clock source

Message Modification  Goal Alter msgs from one timekeeper to another to cause incorrect synchronizationAlter msgs from one timekeeper to another to cause incorrect synchronization  Attack Alter packets sent to victimAlter packets sent to victim  Different types of attacks

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

Modification Attack pkt.versionDoS pkt.mode Disconnection of association pkt.stratum Lower stratum pkt.ppoll Affects polling interval pkt.distance Affects roundtrip delay, effect choice of clock source and frequency of polling pkt.dispersion Affects estimated dispersion

Modification  Countermeasures Use Authentication!Use Authentication! Stratum level used only if checks passStratum level used only if checks pass Access controls indicate if connection is trustedAccess controls indicate if connection is trusted

Replay  Goal Intercept + resend NTP msgs to cause recipient to incorrectly resynchronizeIntercept + resend NTP msgs to cause recipient to incorrectly resynchronize Disable active associationDisable active association  Attack Record msgs + replay them laterRecord msgs + replay them later  Effects Alternate and replayAlternate and replay Reset local clock to earlier timeReset local clock to earlier time  Counter Reject any msg with a timestamp older last msg receivedReject any msg with a timestamp older last msg received Create a special msg when clock needs to be changed backwardsCreate a special msg when clock needs to be changed backwards Route basedRoute based

Delay  Goal Cause incorrect resynchronizationCause incorrect resynchronization Disable active associationDisable active association  Attack Artificially increase the roundtrip delay of an associationArtificially increase the roundtrip delay of an association  Effects Delay packets in sampleDelay packets in sample Peer sending packets not sourcePeer sending packets not source Results in having no source, DoSResults in having no source, DoS  Counter Redundancy of clock sourcesRedundancy of clock sources

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

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

Suggestions  Internal Mechanisms Assume no underlying security mechanismAssume 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

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

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

Questions?