NTP Authentication (Cisco’s Implementation)

NTP Authentication was introduced in NTP Version 3 with RFC1305.  The reason I placed “Cisco’s Implementation” in parenthesis is due to the fact that RFC did not specify the hashing algorithm that was to be used to compute the hash that is used to verify the NTP message.  Microsoft does not provide authentication using MD5 in the same manner that Cisco does.  In this article, I would like to show two things.  First, I will show how an authenticated NTP Client/Server relationship differs in configuration from a non authenticated client server relationship.  Second, I will provide a look at the packet captures and illustrate how to easily identify Authenticated NTP versus NTP that lacks authentication.

 

For demonstration purposes, I have set up a lab with three routers.  The first router, named Master, is configured to be a stratum 3 NTP Source.  It has also been configured in a way that will allow it to respond to NTP.  Additionally, I have configured an NTP client that is not requiring authenticated time sources.  The final router, AuthClient, requires authenticated NTP time sources.

Router Master Configuration Steps:

#Just to make things easy for me

clock timezone EST -5

clock summer-time EDT recurring

#clock must be set for ntp logic to sync as master

clock set 14:09:00 Dec 28 2008

#ntp commands

#configure a key to use when auth is requested

ntp authentication-key 1 md5 cisco

#set this router to use internal clock as Stratum 3 NTP Source

ntp master 3 

Router NonAuthClient Configuration Steps:

#Just to make things easy for me

clock timezone EST -5

clock summer-time EDT recurring

 

#ntp commands

#set this router to use 10.1.1.1 as an NTP Server

ntp server 10.1.1.1

Router AuthClient Configuration Steps:

#Just to make things easy for me

clock timezone EST -5

clock summer-time EDT recurring

#ntp commands

#configure a key for use with authentication

ntp authentication-key 1 md5 cisco

#set this router to trust NTP messages authenticated with key 1

ntp trusted-key 1

#require NTP sources to be authenticated

ntp authenticate

#use 10.2.1.1 as NTP server and use key 1 when sending/receiving messages from this server

ntp server 10.2.1.1 key 1

Recommended Commands for Verification:

debug ntp packet—This command will allow you to quickly identify if traffic is flowing to and from in the NTP Relationships.

debug ntp authentication—This command will allow you to see when an NTP is being accessed

show ntp status—General command showing the general status of NTP

show ntp associations—command showing the summary view of all NTP relationships originating with the router

show ntp associations detail—command showing detailed information about the relationship between the router and other time sources.  This includes the status, as well as if the messages are authenticated (look for the keyword “authenticated” in the first line of output).

Additonal Confituration Notes

One caveat I have found with NTP in a lab scenario is if you make changes to the clock on the NTP Master, you will likely lose the syncronization between it and the clients.  To quickly resolve this, you can remove the “ntp server” on the client and re add it.  This should force it to re-synchronize fairly quickly.

 

Now that we have a general idea of the configuration, I would like to take a quick look at this from the standpoint of the wire.  I have captured communication for both the non-authenticated and the authenticated NTP relationships.

 

Non Authenticated NTP Capture
Authenticate NTP Capture

 

If you open these in Wireshark, you will quickly see the difference.  In the capture that contains authenticated NTP messages, you will find a field for Key ID and a field for Message Authentication Code.  This is the MD5 digest that is used to validate the rest of the message and ensure it is valid.  Below you will find two images.  The first one is that of an authenticated NTP message.  The second one is that of an NTP message that is not authenticated, although it may be perfectly valid.

NTP seems to be one of those things that we just do.  We never really put a lot of time into understanding its inner workings.  At its core, NTP is a fairly simple protocol that can be easily understood with a bit of trial and error and possibly access to a packet sniffer.  NTP authentication is typically implemented as a Message Authentication Code which is basically an MD5 digest of the NTP message.  This allows the endpoints to determine if the messages are valid using a key that has been predetermined and configured.  The configuration is simple, but can be a little bit confusing the first time due to some options and descriptions that are presented when you begin the configuration.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.