NTP
Network Time Protocol
- 30 years old, 1980
- used by all computers on the internet to sync clocks currently in version 4
- client sends query for time update to all servers and gets responses
- then decides which server to take the response from, if any
- sends these requests at randomized/adaptively-selected intervals
- every client can act like a server
- client requires a number of self-consistent responses to update its clock (4 is sufficient)
T1 = origin timestamp T2 = receive timestamp T3 = transmit timestamp
T4 (not in packet) = destination timestamp
- delay = (T4-T1) - (T3-T2)
- offset = 1/2[(t2-t1)+(t3-t4)]
- delay = round trip time on the network, not including the remote ends processing time
- offset = difference between the local clock and a remote clock, after network delay is taken into account
- frequency = error rate of the local clock, aka drift
- jitter = root mean square differences between the offset
Modes of Operation:
- client/server: timing queries are solicited by clients from a set of servers
- broadcast/multicast: a set of clients listen to a server for timing information
- symmetric peering; peers exchange timing info
- interleaved: for more accurate timestamping
-
- UDP port: 123
- Poll: one round trip check of peer’s time
- Polling interval: interval limits 2^3-2^17 seconds (usual range is 1-17 minutes)
Why do we care about NTP?
-
Crypto needs accurate time: a certificate that has been expired can be set to valid if time is set back
-
If time can be set forward, then service can be denied by expiring certs
-
DNSSEC used to secure DNS requests signed with certificates that expire in range of months
-
Bitcoin blockchains have timestamps on the order of hours
Crypto in NTP?
- supports both symmetric and asymmetric crypto but rarely used
-
symmetric used MD5 hash with (key msg) - length extension, collisions, key distribution
- asymmetric uses the autokey protocol, badly broken
-
- only ~2.1% of all clients have all NTP associations authenticated
Non-crypto authentication:
- w/ origin timestamp
- T1 = now
- xmt = T1
- Check xmt == T1 in response
- xmt reset to 0
- can be attacked by spoofing packet with T1 = 0 in query, xmt == 0 == T1
- (Off Path zero-Origin attack)
- Client sends timestamp t3 with query, expects same timestamp t1 with response from server
- must be random so attacker cannot guess
- to fix:
- sleep for (0, 2^n)
- T1 = now
- xmt = T1
- Check xmt == T1 in response
- xmt reset to random 64-bit number
- secure against off-path attacker
- backwards compatible