Cisco’s NTP authentication is b0rked

 | 25 Jul 2006 11:35

Master:
ntp authentication-key 14 md5 ladida
ntp authenticate (see comment below)
ntp source Loopback0
ntp master
ntp server source FastEthernet0/0
ntp trusted-key 14 (see comment below)

Client:
ntp authentication-key 14 md5 ladida
ntp authenticate
ntp source Loopback0
! ntp trusted-key 14 (only required when not specifying a key on the line below)
ntp server key 14

Debug on the client:

21:05:03: NTP: rcv packet from 134.14.1.1 to 134.14.7.7 on Loopback0:
21:05:03: leap 0, mode 4, version 3, stratum 2, ppoll 64

21:05:03: Authentication key 0
21:05:03: NTP: packet from 134.14.1.1 failed validity tests 10
21:05:03: Authentication failed
21:06:06: NTP: xmit packet to 134.14.1.1:
21:06:06: leap 3, mode 3, version 3, stratum 0, ppoll 64

21:06:06: Authentication key 14

The Client does send authenticated packets but the Master doesn’t. Mind you configuring a ‘peer’ is symmetric (same stratum) and ‘server’ is asymmetric (ntp stratum hierarchy). Apparently Cisco knows about it for years but it’s too low a priority to fix it, so don’t bother running to TAC with this…

Even configuring peers so one can set the key on the master doesn’t help. The authentication error disappears but no association forms.

5 Responses to “Cisco’s NTP authentication is b0rked”

Frank wrote a comment on 9 Feb 2008

Your ignorance is only superseded by your arrogance. You are misinformed and simultaneously believe you are more intelligent than the engineers that work for Cisco. Quite laughable I must say.

If you had bothered to enter the following two commands into the device acting as the NTP server (i.e. master) it would have worked just fine:

ntp authenticate
ntp trusted-key 14

How do you expect NTP authentication to work if it is not even enabled on the master? If you had actually called TAC they would have quickly pointed out the missing commands.

Djerk wrote a comment on 11 Feb 2008

Well, I can’t deny neither ignorance nor arrogance. Though the latter is something I’d rather be rid of than the first. The more I learn the more I realise how little I know, somehow this doesn’t always translate into a humble approach. I stand corrected on that account, thank you Frank. I’ll add your suggested lines to the post but feel compelled to add the following as well:

During the bootcamp I followed we ran into issues with NTP and authentication. It worked and then one by one all of us ran into issues where authentication would fail and the NTP peering broke. Our tutor confirmed that this was quite common and was known to Cisco. This post was intended to highlight that, it seems I failed at that. So once I get access to some equipment to test this on I’ll have to finalise this post and either stand completely corrected or prove the point I was trying to make.

My current personal take/recollection is that I probably did use the suggested lines when testing, though removed them in an attempt to reconfigure things trying to get NTP authentication to work again. What ever I did, I either did not do my research propperly or I posted too hastilly. As I’m for open communication I do not intend to hide my mistakes as we all make those. I’d rather humble myself and thank Frank for his correction.

To be comtinued…

djerk.nl » Humbling experience sent a pingback on 11 Feb 2008

[…] just been taught a lesson in humility and authorship. My post about Cisco’s NTP authentication implementation received a comment from a certain Frank. I’ve added my comment and need to […]

Ivan Pepelnjak wrote a comment on 11 Feb 2008

Here are working configs for NTP client and NTP server.
================================
hostname Server
!
ntp logging
ntp authentication-key 2 md5 071C244F5C0C0D 7
ntp clock-period 17179887
ntp master 10
!
! Upstream non-authenticating NTP server
ntp server 192.168.200.193
================================
hostname Client
!
ntp logging
ntp authentication-key 2 md5 071C244F5C0C0D 7
ntp authenticate
ntp trusted-key 2
ntp server 10.0.0.1 key 2 prefer
================================

I’ll write an in-depth NTP-related article for the IP Corner and will let you know when it’s posted. If you send me an e-mail (use “Send message to Ivan” in my bio page), I’ll send you a preview copy.

bryan wrote a comment on 18 Feb 2008

I have tested NTP a lot lately and hope I can shed some light on what I think is helpful or just really strange. Basically it mirrors Ivan in the last post. This is what I have and it works:

master:

ntp authentication-key 420 md5 cisco
ntp master 3

client

ntp authentication-key 420 md5 cisco
ntp trusted-key 420
ntp authenticate
ntp server 192.168.100.2 key 420

I don’t need “ntp authenticate” or “ntp trusted-key” on the master.

Packet captures show that the master and client are both sending hashes.
Debug shows client and master both send key 420.
Client is synced.

If I change either of the keys (master or client) authentication fails.
This would seem to be proof of authentication.

If I remove the “ntp trusted-key 420” from the client it fails.

If I remove “ntp authenticate” from client it still works. Go figure…
If I remove “ntp authenticate” from client and change the key it fails. Go figure…

I really think all you needed was “ntp trusted-key 14” on your client.
That should have worked…maybe when you get time you can try it again…