r4 - 2013-12-13 - 14:44:19 - DereckHurtubiseYou are here: NTP >  Dev Web > AuthenticationIssuesAndSuggestions
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p10 was released on 21 March 2017. It addresses 6 medium- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Authentication Issues and Suggestions

Related Topics:

Digest Methods

For an in-depth discussion of this, see MACDigestMethods.

MAC field

The MAC (Message Authentication Code) is ...

For an in-depth discussion of this, see MACFieldAlternatives.

OpenSSL Versions

What versions of OpenSSL should we support?

  • How far back should we go? -- HarlanStenn - 13 Dec 2013
  • Since OpenSSL 1.0.1e (latest stable, site seen at Dec 13 2013) is backwards compatible I'd opt for that version. -- DereckHurtubise - 13 Dec 2013



I've had some conversations with Harlan and I'll post the main issues we have here in a short summarized form.

- First NIDs:

It wasn't clear where we could find the nids belonging to particular cryptographic algorithms. All nids are defined in the following header file is OpenSSL : openssl/crypto/objects/obj_dat.h Than search for the algorithm you need. I believe they are contained within enumerations. There are several, containing the exact same defines, just ordered differently.

- Short names in OpenSSL :

The list of shortnames gathered by typing ? in the openssl program is outdated. Some shortnames don't exist and a lot aren't even mentioned. For example, rmd160 should be the short name of RIPEMD160. But there is no short name for RIPEMD160 anywhere in OpenSSL . SHA256 is not even mentioned in the whole list! Only SHA and SHA1. SHA is SHA-0 by the way and you definitely don't want to use that. Going by the list of NIDs found in the header file referred to above is the best way to go in my opinion.

Issues with the current implementation of NTP:

- Digest type by client's/peer's preference:

The RFC 5906 mentions that the digest type is by client's preference. The source code doesn't support that. Instead, the 'crypto_nid' variable in ntp_crypto.c is used. This is a global variable set by either the command line or the config file. If not set, it is hard-coded to md5. This effectively enforces all peers to use the digest type set by the Trusted Root server, instead of the by client/peer preference.

- MAC field:

The MAC field is locked at MAX_MAC_LEN, which is maximum SHA1 (20 bytes + 4 bytes keyid). Switching to a longer digest type, like SHA256, causes the server/client to ignore the packet entirely. One would think the code would cull the digest to 20 bytes, but the code appends the full digest (32 bytes if SHA256) to the message. We need to find a scalable solution based on the preference of the peer. I suggest fetching the digest length by nid (or EVP_MD*) from the OpenSSL Library and check if the incomming digest length equals the expected digest length from that particular peer.

- ASSOC exchange:

One problem is figuring out the digest type the peer uses on first-contact. The type of digest used by the peer is contained in the ASSOC message, but the packet is checked/verified before the message is ever read.

- CERT exchange:

This works as advertised and is fine at the moment. But ntp-keygen has a severe bug I think. Trying to create a DSA based certificate on a clean directory fails every time, as it expects an RSA based key pair. NIST/FIPS is about to drop RSA in favor for DSA and ECDSA, so this should be fixed at some point.

- IDENT exchange:

All schemes (except MV?) enforce the bighash() routine. This routine enforces an md5 digest. This should be the peer specific digest type I think.

- COOK exchange:

Is forced to use RSA keys, instead of by peer preference.

- autokey generation ( session_key() ):

This is based on the crypto_nid variable. This should be the peer's digest type.

- Conclusion:

A lot of the code enforces a by Trusted Root server policy, instead of a by peer's preference. This is contrary to what the RFC mentions I think. -- DereckHurtubise - 13 Dec 2013

- One more thing I find strange. When creating a certificate with ntp_keygen, the public exponent of an RSA keypair is hard-coded to 3. Shouldn't this per commandline option? What if I want 17 or 33? This should at least be a commandline option in my humble opinion. -- DereckHurtubise - 13 Dec 2013

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r4 < r3 < r2 < r1 | More topic actions
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback