How to use NTPv4 SHA Hex key on Cisco Equipment?

[Ronit Bhattacharjee]

We currently have our Cisco equipment synced to our NTP server using MD5 authentication, which works well. We have a directive from our cybersecurity team to upgrade to one of the SHA authentication mechanisms and facing a problem with that.

Now, both NTPD and ChronyD generate authentication keys, in hexadecimal form with 40 characters length, which is 20 bytes. Example : 8d6c9b1211c4e393d02b457c2507b7b7cc16c070

Cisco equipment (IOS-XE and IOS-XR) both accept keys up to 32 bytes in length, but they don't accept the 40 character hex key

If I trim the last 8 characters off the key (and make it 32 character, 16 bytes), it is accepted, but obviously NTP doesn't authenticate anymore. 

The only reason I think this may be happening is because the Cisco equipment accepts the key in text format and is considering the hex as text. 

To fix this, I tried converting the hex into ASCII, but it generates garbage characters.

Has anyone her experience using NTP authentication with SHA or above keys?

[marce1000]

  - It's probably a limitation on cisco devices : refs : 
       https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-12/configuration_guide/sys_mgmt/b_1712_sys_mgmt_9500_cg.pdf
      https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9400/software/release/17-9/configuration_guide/sys_mgmt/b_179_sys_mgmt_9400_cg.pdf
         >...The digest length is 128 bits and the key length is 1 to 32 bytes.

   M.

[Ronit Bhattacharjee]

Hello. I did note that. The 40 digit Hex key is 20 bytes only, so should be OK. The problem is, it is considering the 40 digit hex key as text, so 40 bytes instead of 20. 

The disconnect is between hex and text.

[marce1000]

     - I would advise to contact TAC for this requirement , 

 M.

[spire_154]

I do not know if you figured this out already, but I had this same issue with chrony and my cisco switches as well.  What I did to remedy this was to create my ntp key in text/ascii format then convert it to HEX.  So, I would create a 20 character/byte ASCII key that I would input into my cisco switch and then convert it to HEX which would give me a 40 character/byte HEX and input that as a key in chrony.

[Ronit Bhattacharjee]

Thanks, we did not figure it out, luckily the NTP part on the server was delayed, so we got more time. 

[Jens Albrecht]

The cause of the problem is the difference how NTP servers and Cisco devices handle these newer algorithms by default.

If you use NTPD/ChronyD to generate random keys, the result is a 40 hex characters long digest. The digest has a fixed length of 160-bit in case of SHA1, hence those 40 hex characters.

However, when you configure NTP authentication on Cisco devices you have to enter a variable length key and there is no way to enter the digest directly.

The solution is pretty simple.
You need to configure your NTP server with the key instead of using the digest.

I use ChronyD on Alma Linux 9.5 as an example.
First you need to modify /etc/chrony.keys and enter a new key:

20 SHA1 MyNTPSecretKey

Then restart the chronyd service.
The config on the Cisco devices might look like this:

ntp authentication-key 20 sha1 MyNTPSecretKey
ntp authenticate
ntp trusted-key 20
ntp source Vlan1
ntp server 192.168.178.94 key 20

Verification on the Cisco device:

Sw_01#sh ntp status
Clock is synchronized, stratum 4, reference is 192.168.178.94

Sw_01sh ntp assoc
  address         ref clock       st   when   poll reach  delay  offset   disp
*~192.168.178.94  192.168.178.1    3      0    128   377  1.919  -7.348  4.677

Verification on the NTP server:

[root@linux ~]$ chronyc clients
Hostname                      NTP   Drop Int IntL Last     Cmd   Drop Int  Last
===============================================================================
192.168.178.115                44      0   6   -    27       0      0   -     -
192.168.178.117                46      0   7   -    80       0      0   -     -
[root@linux ~]$ 

HTH!

[Ronit Bhattacharjee]

Thanks. This is quite helpful. We will keep this in mind when we try SHA again