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

Matt BishopPresented by Alexander Gorman

Goal of PaperExamine the security requirements of the Network Time Protocol (version 2)Determine if version 2 meets requirementsSuggest Improvements

My GoalsDescribe version 2 of NTPAnalyze attacksImprovements

AttacksMasqueradeModificationReplayDoSDelay

AssumptionsMessages leave source uncorruptedNot altered on arrivalFocus on transmission

NTPNTP = Network Time ProtocolPrimary time serversSecondary time serversStratum NumberMeasure distance from primary to secondary time server

NTPABCTop level stratumLevel 2 stratumLevel 3 StratumPrimary

NTP RulesPrimary time servers synchronized by external systemSecondary time servers synchronized by:Primary time serverAnother secondary time server with lower stratum number

Association ModesNon-Server sync with NTP ServerClientWhat time is it?Send msgs to peersServerCreated when received client msgResponds with servers time, terminatesBroadcastSends periodic time messages

Association ModesTime Server sync with other Time ServersSymmetric activeBroadcast sync msgsSymmetric passiveIf sender strata > receiver, reply + terminateElse, sender syncs host and receiver responds with time msg of its own.

Note: Normally servers with high strata run in active mode

Smooth DataImprove accuracy

Algorithm 1Compute roundtrip delay and offsetTake sample from last 8 msgsChoose lowest delay and use associated offset as estimated clock offsetEstimate sample dispersion

Offset and Delayti-3titi-2ti-1Ci = ((ti-2 - ti-3) + (ti-1 ti)) / 2Di = (ti ti-3) + (ti-1 ti-2)

Selection of Source PeerAlgorithm 2Who should sync clock?Uses Algorithm 1 List is sorted and scanned repeatedlyClock dispersion relative to peer is computedHighest dispersion eliminatedOnly one source left

Receive and Packet ProceduresWhen a msg (packet) is received eitherError: packet discarded, association deletedPacket Procedure

Packet Proceduresif (time packet transmitted=time last received packet transmitted) thensanity := true;if (time peer received last packet from hosttime last message sent to peer) thensanity := true;(*update association variables in Figure 3*)if (peer clock not synchronized) or (peer clock not updated for 1 day) thensanity := true;if (not authenticated correctly) thensanity := true;if (peer not preconfigured) and (packets stratum>peers stratum) thensanity := 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 ProceduresCheckEliminate re-transmitted packetsPacket not transmitted at the same time as the last one received from that peerEnsure messages are received in orderThe last packet received from the local host was indeed the one the local host sent to the peerPeer clock is synchronized correctlyPacket is authenticated correctlyPacket is preconfigured correctly andPackets stratum level > peers stratum level FAIL

Packet ProcedureIf successfulResets internal variablesAdjusts local clock if necessaryPossibly select new peer as clock source

Security MechanismsDelay CompensationAccess ControlAuthentication

Delay CompensationCompensate for network delaysAlgorithm calculates roundtrip delay and clock offset relative to peerApplies statistical procedure to update clock (see book Network Time Protocol (Version 2) Specification and Implementation)

Access ControlAll hosts partitioned into 3 groupsTrustedAllowed to synchronize the local clockEither preconfigured or based on trusted ticket service (Kerberos)FriendlySent NTP msgs and timestamps when neededCannot change local clockOthersMessages from this group are ignored

AuthenticationCovers Authentication and integrityPacket in authenticated modeTransmittedNTP packet (except for authenticator) is checksummed using active peers keyKey depends on mode

Authenticationif peer.config = 0 thenif(authenticator in message data) thenpeer.authenable := 1elsepeer.authenable := 0;if peer.authenable =1 then beginpeer.authentic := 0;if (authenticator in message data) then beginpeer.keyid := packet.keyid;compute_mac(mac, peer.keyid, packet);if peer.keyid 0 and mac = packet.check thenpeer.authentic := 1;end;end;(*if peer.authenable is 0, authentication is not done;*)(*otherwise if peer.authentic is 0, the integrity of the *)(*packets contents are suspect*)

AuthenticationPacket ReceivedIf msg contains authentication infoIndex # of peers key reset to that in packetChecksum recomputed and compared to transmitted checksumIf checksums match check succeedsIf packet has no authentication infoCheck fails, routine exits

Analysis of SecurityAnalyze the following:Access ControlAuthentication

Access ControlRelies completely on an unauthenticated source address (in the absence of an integrity checking mechanism)Solution: routing infoIP record route

AuthenticationKey index can be alteredCheck is only 64bitsNo key distribution mechanism definedKeys used on a per host basisCould lead to a compromise of all hosts that peer synchronizes

AttacksGoalAttackEffectCountermeasure

MasqueradeGoalConvince timekeeper that attacker is authorized to synchronize itAttackSend a victim packets with source address of timekeeperEffectsIf host is knownNone if change is drasticDrift created if timestamps changed graduallyUnknown hostCompromise server by sending 8 uninterrupted messagesSend msgs claiming low stratum numberCountermeasureUse authenticationDo not allow non-preconfigured peer to become clock source

Message ModificationGoalAlter msgs from one timekeeper to another to cause incorrect synchronizationAttackAlter packets sent to victimDifferent types of attacks

Modification AttacksIntegrity the recipients clockpkt.rec, pkt.xmt, pkt.precisionChange round trip delay

Modification Attack

ModificationCountermeasuresUse Authentication!Stratum level used only if checks passAccess controls indicate if connection is trusted

ReplayGoalIntercept + resend NTP msgs to cause recipient to incorrectly resynchronizeDisable active associationAttackRecord msgs + replay them laterEffectsAlternate and replayReset local clock to earlier timeCounterReject any msg with a timestamp older last msg receivedCreate a special msg when clock needs to be changed backwardsRoute based

DelayGoalCause incorrect resynchronizationDisable active associationAttackArtificially increase the roundtrip delay of an associationEffectsDelay packets in samplePeer sending packets not sourceResults in having no source, DoSCounterRedundancy of clock sources

DoSGoalPrevent NTP msgs from one timekeeper to anotherAttackPrevent packets from clock sources from reaching an NTP hostEffectsForces NTP to run under its own clock, high drift!CounterRedundancy of clock sources

Combined AttackVery effectiveE.g. Deny a secondary server from all but one source, and delay packets from source To counter, deal with each component attack separately

SuggestionsInternal MechanismsAssume no underlying security mechanismAlways use AuthenticationKeys used per-path not per-hostBase Access Control on recorded routesChange variables after packet passes checksFurther restrict values of variablesIncrease sample sizeRequire special packet to set clock backwardsRedundancy, server should have many sources

SuggestionsExternalSecure transmissionRun into problems with this schemePublic-key checksum - Too slow!IP does not provide sufficient securityStrict source does not work!

ConclusionNTP has some weaknesses, but well designed

Remember, security analysts viewMay or may not impact goals of protocol

Questions?

Page 2Page 2Page 2End page 2 + 3Page 3Association is an instantiation of the protocol machinea stratum n server is at a higher stratum than a stratum n-1 server If a peer sends a "symmetric active" packet, it is willing to modify the NTP server's time Draw picture on top of page 5 for class?A measure, in seconds, of how scattered the time offsets have been from a given time server.slideRecord two packets from the peer then rapidly alternate and replay