Build an authenticated NTP hierarchy from a GPS source

Cisco IOSWorking

R1 takes time from the GPS appliance TIME1 with one key and serves it to the rest of the network with a second key. R2 and SW1 accept time only from R1 and only when it is authenticated. R1 lets only TIME1 set its clock and only internal addresses ask it for time.

Item	Value
TIME1	10.0.0.123, stratum 1, MD5 key 1 = `Gps-Feed-Key-01`
Internal key	MD5 key 2 = `Int-Time-Key-02`
R1 loopback	10.255.0.1
R2 loopback	10.255.0.2
SW1 loopback	10.255.0.11
Internal address space	10.0.0.0/8

Routing between all loopbacks and TIME1 is already in place.

Tasks

Sync R1 to TIME1 with key 1, sourcing NTP from Loopback0.
Make R1 accept time only from TIME1 and serve time only to 10.0.0.0/8.
Sync R2 and SW1 to R1 with key 2, refusing any unauthenticated source.
Timestamp logs in UTC with milliseconds and keep the hardware clock updated.
Verify the stratum chain (1, 2, 3) and that the associations are authenticated.

Solution

1R1 keys and upstream serverR1

R1 on Cisco IOS

ntp authentication-key 1 md5 Gps-Feed-Key-01
ntp authentication-key 2 md5 Int-Time-Key-02
ntp authenticate
ntp trusted-key 1
ntp trusted-key 2
ntp source Loopback0
ntp server 10.0.0.123 key 1
ntp update-calendar
service timestamps log datetime msec show-timezone

R1 needs key 2 defined so it can answer R2 and SW1's authenticated requests. ntp authenticate is safe here only because TIME1 uses a key; with an unkeyed upstream, R1 would stop syncing.

2R1 access controlR1
R1 on Cisco IOS
```
access-list 10 permit 10.0.0.123
access-list 20 permit 10.0.0.0 0.255.255.255
ntp access-group peer 10
ntp access-group serve-only 20
```
IOS checks the groups from least to most restrictive (peer, serve, serve-only, query-only) and applies the first match, so TIME1 matches peer even though it is also inside 10.0.0.0/8. Anything not permitted by a group is refused.

3R2 as an authenticated clientR2

R2 on Cisco IOS

ntp authentication-key 2 md5 Int-Time-Key-02
ntp authenticate
ntp trusted-key 2
ntp source Loopback0
ntp server 10.255.0.1 key 2
ntp update-calendar
service timestamps log datetime msec show-timezone

4SW1 as an authenticated clientSW1

SW1 on Cisco IOS

ntp authentication-key 2 md5 Int-Time-Key-02
ntp authenticate
ntp trusted-key 2
ntp source Loopback0
ntp server 10.255.0.1 key 2
service timestamps log datetime msec show-timezone

In production give every client at least two internal servers, ideally four. One is used here to keep the lab short.

Verify

R1 output

R1# show ntp associations
  address         ref clock       st   when   poll reach  delay  offset   disp
*~10.0.0.123      .GPS.            1     38     64   377  0.412   0.087  0.952
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

TIME1 is the system peer (*), stratum 1, reference GPS, and the last eight polls were answered (377).

R2 output

R2# show ntp associations
  address         ref clock       st   when   poll reach  delay  offset   disp
*~10.255.0.1      10.0.0.123       2     12     64   377  1.204  -0.311  1.889
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

R2 syncs to R1, which is stratum 2. The ref clock column shows R1's own source, TIME1.

R2 output

R2# show ntp status | include Clock
Clock is synchronized, stratum 3, reference is 10.255.0.1

R2 is one hop below R1, so stratum 3.

R2 output

R2# show ntp associations detail | include configured
10.255.0.1 configured, ipv4, authenticated, our_master, sane, valid, stratum 2

The word authenticated proves key 2 matched on both sides.

Mistakes people make

Forgetting ntp trusted-key. The key exists, the server is configured with it, and the client never syncs.
Different key strings or key numbers on the two ends. Both the number and the string must match.
Turning on ntp authenticate on a router whose upstream servers have no keys, such as public pool servers.
Leaving TIME1 out of the peer access group: once any NTP access group exists, R1 refuses time from it.
Sourcing NTP from a loopback the server cannot route back to.

On other platforms

A Junos device as a client of R1.

Junos

set system ntp authentication-key 2 type md5 value "Int-Time-Key-02"
set system ntp trusted-key 2
set system ntp server 10.255.0.1 key 2
set system ntp source-address 10.255.0.21

A Linux server running chrony as a client of R1. The key file holds the same MD5 key.

Linux

# /etc/chrony/chrony.keys
2 MD5 ASCII:Int-Time-Key-02

# /etc/chrony/chrony.conf
keyfile /etc/chrony/chrony.keys
server 10.255.0.1 iburst key 2

Say it in the interview

"Each layer authenticates the layer above it. R1 trusts only TIME1 with key 1 and serves the network with key 2, and the access groups make sure only TIME1 can set R1's clock. Clients need the key, ntp authenticate, the trusted key and the server line with the key. I verify with the stratum chain and the authenticated flag in the association detail."

Book 9.3 Infrastructure Applications