Lesson Contents
This packet capture contains an NTP client request and a server response with NTP authentication enabled. Two Cisco routers share an MD5 key, and you can see exactly what authentication adds to an NTP packet: a 4-byte Key ID and a 16-byte message authentication code (MAC) at the end. Nothing is encrypted, but a router without the right key can no longer feed you a fake time.
It’s also a good capture for learning the NTP header itself: client and server modes, stratum, the four timestamps, and a confusing “Kiss-o’-Death” label that Wireshark shows for an unsynchronized client. The Cisco NTP lesson covers the configuration, NTPv4 explains the protocol itself, and troubleshooting NTP helps when a client refuses to sync, for example because of a key mismatch. More captures are in the Packet Capture Library.
Want to open this capture in Wireshark yourself? The pcap file is free with a NetworkLessons account. Your free account also unlocks all our free lessons and every capture in the Packet Capture Library.
Create a free account to download the pcap
Already have an account? Log in and the download button appears here.
Capture overview
| File | ntp-authentication-enabled.pcapng |
| Packets | 2 (client request, server response) |
| Protocol | NTPv4 (RFC 5905), symmetric key authentication with MD5 |
| Transport | UDP 123 → 123 |
| Devices | Cisco IOS: client 192.168.1.2, server 192.168.1.1 |
| Wireshark filter | ntp or ntp.keyid for authenticated packets only |
Packet walkthrough
Client request (packet 1)
Frame 1: 110 bytes on wire (880 bits), 110 bytes captured (880 bits)
Internet Protocol Version 4, Src: 192.168.1.2, Dst: 192.168.1.1
User Datagram Protocol, Src Port: 123, Dst Port: 123
Length: 76
Network Time Protocol (NTP Version 4, client)
Flags: 0xe3, Leap Indicator: unknown (clock unsynchronized), Version number: NTP Version 4, Mode: client
11.. .... = Leap Indicator: unknown (clock unsynchronized) (3)
..10 0... = Version number: NTP Version 4 (4)
.... .011 = Mode: client (3)
Peer Clock Stratum: unspecified or invalid (0)
Peer Polling Interval: 6 (64 seconds)
Peer Clock Precision: -13 (0.000122070 seconds)
Root Delay: 0.000000 seconds
Root Dispersion: 0.000000 seconds
Reference ID: Unidentified Kiss-o'-Death message 'NULL'
Reference Timestamp: Jun 12, 2018 13:44:48.368698309 UTC
Origin Timestamp: NULL
Receive Timestamp: NULL
Transmit Timestamp: Jun 12, 2018 13:44:58.362690406 UTC
Key ID: 00000001
Message Authentication Code: bf5846594f5551ad3b3bad39020b0575- Mode 3 (client): a client asking a server for time. The server answers with mode 4. Other modes are 1/2 (symmetric active/passive, used with
ntp peer) and 5 (broadcast). - Leap Indicator 3 and stratum 0: the client’s clock isn’t synchronized (yet), so it advertises “unknown” and an invalid stratum.
- “Kiss-o’-Death ‘NULL'”: this isn’t a real Kiss-o’-Death. With stratum 0, Wireshark interprets the Reference ID as an ASCII KoD code, and an empty Reference ID shows up as ‘NULL’. A real KoD comes from a server with a code like RATE or DENY.
- Origin and Receive Timestamp NULL: the client hasn’t received a valid response from this server yet, so it has nothing to fill in.
- Transmit Timestamp: when the client sent the request. The server copies this value into the Origin Timestamp of its response.
- Key ID 1: the number of the shared key the client used. Both routers must have the same key number with the same secret, and the key must be trusted.
- Message Authentication Code: a 16-byte MD5 digest of the secret key and the NTP packet. The receiver calculates the same digest with its copy of the key. If the two don’t match, it drops the packet. The secret itself is never sent.
Server response (packet 2)
Network Time Protocol (NTP Version 4, server)
Flags: 0x24, Leap Indicator: no warning, Version number: NTP Version 4, Mode: server
00.. .... = Leap Indicator: no warning (0)
..10 0... = Version number: NTP Version 4 (4)
.... .100 = Mode: server (4)
Peer Clock Stratum: secondary reference (8)
Peer Polling Interval: 6 (64 seconds)
Peer Clock Precision: -13 (0.000122070 seconds)
Root Delay: 0.000000 seconds
Root Dispersion: 0.000565 seconds
Reference ID: 127.127.1.1
Reference Timestamp: Jun 12, 2018 13:44:51.748399011 UTC
Origin Timestamp: Jun 12, 2018 13:44:58.362690406 UTC
Receive Timestamp: Jun 12, 2018 13:44:58.423855505 UTC
Transmit Timestamp: Jun 12, 2018 13:44:58.424806050 UTC
Key ID: 00000001
Message Authentication Code: e0e1956ae91f23a24104195af86e02bc- Stratum 8, Reference ID 127.127.1.1: the server uses its own local clock as the reference. That’s what you get on Cisco IOS with
ntp master, which defaults to stratum 8. A server that syncs from an upstream NTP server shows that server’s IP address here instead. - The four timestamps: Origin (T1, the client’s transmit time copied back), Receive (T2, when the server received the request) and Transmit (T3, when the server sent the response). The client adds T4 when the response arrives. With these four values the client calculates the round-trip delay and its clock offset. This also protects against replays: the client only accepts a response whose Origin Timestamp matches its own request.
- Key ID 1 and a different MAC: the server signs its response with the same key. The MAC is different because the packet content is different.
Authenticated vs. unauthenticated
The same exchange without authentication is available as a second pcap, with the same free account.
The frames are 90 bytes without authentication and 110 bytes with it. The 20 extra bytes are the 4-byte Key ID and the 16-byte MD5 digest. Everything else in the packet stays in clear text. NTP authentication proves who sent the packet and that nobody changed it. It doesn’t encrypt anything.
These are the Cisco IOS commands that produce this kind of exchange. On the server:
ntp authentication-key 1 md5 <secret>
ntp authenticate
ntp trusted-key 1
ntp masterOn the client:
ntp authentication-key 1 md5 <secret>
ntp authenticate
ntp trusted-key 1
ntp server 192.168.1.1 key 1