RFC 8573: Why Trust in Time Matters for Your Network

The vast majority of network time exchanges within a network are either entirely unsecured, so they’re subject to distinct forgery attacks (essentially just IP spoofing of a Stratum1 source), and also UDP based (udp/123), which means they’re connectionless in nature. But it also means they’re essentially bi-directional exchanges, without any validation.

So much of what we do within networks (for security, automation, and trust) is based on a trust in timestamps and the veracity of time itself. Yet they’re often sourced from a completely untrusted time source within an IP network. And shockingly, that trust is extremely fragile even when attempts have been made to strengthen it. This is because many applications and network devices will reach out to unvetted and completely non-validated time sources existing on the open Internet.

The inherent risks in time

A great example the risks your network faces every day due is illustrated via TacoTaco, an ongoing project about attacks on TACACS+ protocol. You can check it out at https://github.com/GrrrDog/TacoTaco. One is a demonstrated attack on TACACS+ with MD5 brute force reversal and collection and insertion of PSK. MD5 is easily brute force reversible (a simple network extraction through arp spoofing) and suddenly you have the PSK used to authenticate NTPv4 within the entire network. A simple spoof later and your SIEM now thinks it 1970, which will make log correlation and forensic validation a fun experience.

If you think it stops there, you’re probably wrong. Most of the routing protocols all use the same MD5 comparison scheme. This just happens to be one example of TACACS+, which also uses MD5 – same as RADIUS, same as NTPv4, same as BGP, EIGRP and OSPF. If you doubt me, look no further than crackstation.net that has a simple comparison table of known results, including MD5 and SHA1 hashes, plus a 190GB, 15-billion-entry lookup table. And project-rainbowcrack.com, that contains Terabytes of pre-calculated MD5 Rainbow Tables.

So after a little research, we see that anyone with a small amount of money and a few dense GPUs, can do it on their own in trivial amounts of time. But with the combined submissions of large databases, it’s simply a comparison lookup which could take no longer than the click of a submission as shown above.

Does 5906 (Autokey) fix the problem?

RFC 5906, also known as AutoKey, tried to establish a security scheme for NTPv4. But we’ve seen very mixed implementations of it within the industry and a fair amount of compatibility problems, not to mention security issues. And the enduring challenge is that the validation functions used are still based on weak algorithms that have been officially deprecated by NIST, specifically MD5 and SHA-1. Historically, there have been some options for use of SHA-1 over time, but NIST has now officially deprecated the use of SHA-1 and almost all control plane implementations use MD5 as the defacto algorithm today.

NIST SHA-1 Guidance

Federal agencies should discontinue use of SHA-1 for generating digital signatures, generating time stamps and for other applications that require collision resistance. I suggest you take a look at https://csrc.nist.gov/Projects/Hash-Functions/NIST-Policy-on-Hash-Functions to learn more about that.

What is RFC 7822?

We also need to mention RFC 7822 that refined the options for NTPv4 extensions. It still ended up being less than 256 bits in length (192 bits or 24 octets to be precise) which means that adoption of RFC7822 and a move towards stronger hash algorithms for a MAC such as SHA256 or SHA384 would still create an inherent MAC field incompatibility within the existing protocol structure. As a result, there would have to be a new NTPv5 protocol, or perhaps NTPv4 Extended++ RFC, with a 32 octet MAC field equating to 256 bits to minimally accommodate a SHA256 hash output.

Benefits of RFC 4493

Luckily there’s RFC 4493, that defines the AES-CMAC standard. It’s a 16 octet output (128 bit) and that magically means it’s automatically bit field compatible to the original MD5 output string (also 128 bits in length) within the NTPv4 MAC field. A MAC is a processed output of a known pre-shared secret key. This output can be processed a number of ways, and in the previous standards, use of MD5 was used to produce a hashed output. In the case of RFC4493, the 128-bit NTPv4 MAC field can use a cryptographically processed output using AES-128 as the block cipher. This is how you get a direct bit field compatibility between MD5 and AES-CMAC. I’d suggest reviewing the algorithm specifications for current FIPS-approved and NIST-recommended block cipher modes, known as NIST AES Block Cipher Algorithm Validation, at https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/CAVP-TESTING-BLOCK-CIPHER-MODES#CMAC.

Why RFC 8573 is our go-forward solution

Currently, there are several open source implementations of NTPv4 – RFC 8573 code available. They make it pretty easy to both support existing MD5 operations – which is critical – as well as to also use the option for AES-CMAC as the replacement. Examples of available RFC 8573 code can be found at https://gitlab.com/NTPsec/ntpsec.

Going forward, dual MD5 & AES operations will be important since migration of devices may take a considerable period of time as manufacturers build compatible software images for their products. If you do an all or nothing approach, you’ll potentially maroon all of the MD5 capable supplicant devices out there, which is why the Time Servers (NTP services) will have to support both methods for some period of time.

So keep an eye out for RFC 8573. Products will start supporting RFC 8573 – AES-CMAC soon and you’d do well to start considering migration options to better secure one of the most important control plane protocols within your network.

The access control list >> deny udp any any eq 123 is something that should be implemented at the edge of every network. That is, of course, a simple thing to say and super hard thing to actually implement because as soon as you do, all kinds of devices will start having problems in the network. So I would highly recommend that you use some form of NetFlow monitoring to establish exactly how NTP traffic flows within the network today and where it is going. Get a handle on it, and work to end the flood of outbound traffic that is almost certainly leaving your network every day due to untrusted time sources.

Also, consider a policy route option or transparent redirection to a time proxy server within the DMZ. This would allow both inspection of NTP, and quite possibly some level of trust establishment by sending all unsecured udp/123 requests to your Time Proxy rather than to the originally intended time source on the Internet. Just be aware that this doesn’t necessarily work if they’re using MD5 hashing because you won’t know what the pre-shared key used is.

So exactly who is doing untamed NTP on your network?

By now, you’re probably curious who is doing untamed NTP on your network. If you are (and I’m sure you are), try the Poor Mans NetFlow Logging process below.

• Step 1: Get on your router, make a new access-list.
  • On an egress interface pointed towards the Internet, add an outbound ACL to the interface (rarely ever used).
• Step 2: access-list 199 permit udp any any eq ntp log
  • access-list 199 permit ip any any
  • interface GigabitEthernet0/1 (your egress interface)
  • ip access-group 199 out
  • (DO NOT FORGET to add permit ip any any at the end – if you don’t there is an implicit deny and all packets will get dropped (except_udp/123) on that interface)

The router will immediately start logging any outbound NTP packets from that interface.

show access-lists will show you exactly how many matches have occurred.

Extended IP access list 199

10 permit udp any any eq ntp log (23 matches)

20 permit ip any any (42710 matches)

In the syslog output you will see a detailed record of the matches and know exactly who is sending NTP out of your network and to what destination. You can start the hunt from there and begin weeding out the time bandits within your own network.