Testing Authenticated NTP Configurations

It's been a long time since I posted, I know. I've been busy both with actual work, and also working on a personal project that involves getting way better at old-school C programming. I've been following Casey Muratori and his Handmade Hero series for a couple of months now, and I've been really inspired to write more C.

More on what I've been working on as it develops.

Also, my friend and co-conspirator Wesley sent me a gift for accomplishing the "Serverfault 10k Challenge" in 2014:

This majestic creature embodies a never-ending thirst for knowledge and symbolizes the triumphs and tribulations of the sysadmin.  It's not a Microsoft MVP award...

... it's better.

Alright so the topic of today's post: Authenticated NTP.  NTP is one of the very oldest protocols on the internet, it has had very few vulnerabilities reported over its 30+ year lifespan, and is ubiquitous in virtually every computer network on the planet. (Because most computers are awful at keeping time.) There are many different versions of it and spinoffs from the reference implementation. People tend to find NTP a boring protocol, but it's one of my favorite internet protocols.  Most people just point their router at pool.ntp.org and never think about NTP again.

Until the day comes that you want to enable authentication in your NTP architecture. Authentication is the mechanism that allows a message recipient to verify that the response came from the intended sender and wasn't tampered with in transit. Within a Windows Active Directory domain, we already have this. Domain members use the Kerberos session keys they already have to create authenticated Windows Time messages with domain controllers.  But that means if you're not a member of the domain, you can't participate.

The administrator of an NTP server who wishes to send you authenticated NTP messages will probably send you an ntp.keys file, or at least a password for you to use. An example ntp.keys file looks like this:

# ntpkey_MD5key_ntp.domain.com.2825130701
# Thu Jan 15 20:00:01 2015
 1 MD5  JzF&f})0ocK1{H9	# MD5 key
 2 MD5  Dv(0v@W8vJ8%#*2	# MD5 key
 3 MD5  N(BzeyvYx$qzs5]	# MD5 key
 4 MD5  TVd2*DXtu-mewLs	# MD5 key
 5 MD5  F9UTa)8AQ9O9561	# MD5 key
 6 MD5  F9}{%$d9vs3Dpxb	# MD5 key
 7 MD5  D]Z*OOr56ukpiD6	# MD5 key
 8 MD5  TTr$OIR9+f74J28	# MD5 key
 9 MD5  EC3F9Zr%-3190&0	# MD5 key
10 MD5  Ndi5+]F^3x3Gdeb	# MD5 key
11 MD5  S+27&8(ba30qM@5	# MD5 key
12 MD5  CnO8)=CyG)QBj]}	# MD5 key
13 MD5  Em62oK!RXhw#y9_	# MD5 key
14 MD5  K-l(^UE@&T(Zj5B	# MD5 key
15 MD5  Gcff1nJb(CuF$*!	# MD5 key
16 MD5  W-*5^xbp3@v8br)	# MD5 key

There aren't any tools that ship with Windows that will help you test this stuff.  The Windows implementation of NTP ("Windows Time") is good enough to keep Windows working within the context of an AD domain, but it's not a full-featured reference NTP implementation.  So, I downloaded the Windows port of NTP from ntp.org. You can use the ntpdate program to query an NTP server using the shared secrets in your ntp.keys file to verify that authentication is successful:

C:\Users\Ryan>ntpdate.exe -b -d -k C:\Users\Ryan\ntp.keys -a 1 ntp.domain.com
...
transmit(70.144.88.104)
receive(70.144.88.104)
receive: authentication passed
transmit(70.144.88.104)
receive(70.144.88.104)
receive: authentication passed
...
server 70.144.88.104, port 123
stratum 2, precision -20, leap 00, trust 000
refid [70.144.88.104], delay 0.03090, dispersion 0.00066
transmitted 4, in filter 4
...
Authenticated NTP: Check. I'll probably write more about this topic in the future, but I have to perform some experiments first.