r1 - 2014-01-31 - 15:24:15 - DereckHurtubiseYou are here: NTP >  Sandbox Web > TWikiUsers > DereckHurtubise > DereckHurtubiseSandbox
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.8p12 was released on 14 August 2018. It addresses 1 low-/medium-severity security issue in ntpd, 1 low-severity security issue in ntpq and ntpdc, and provides 27 non-security bugfixes and 4 other improvements over 4.2.8p11.

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.
This is some notes I keep for reference purposes.

Autokey:
randomize cookie per client by hashing the server seed with the client's public key and store the 32_MSB.
This gives at least some protection against a masquerade attack.

NTS:
NTS draft:
http://tools.ietf.org/html/draft-ietf-ntp-network-time-security-01

My opinions on the draft:
- Association message is only there for the client to check if the server supports the crypto schemes it wants to use (hash algorithms and encryption/decryption scheme)

- The cookie exchange is to restrictive.
- First: It is not clear which RSA encryption scheme is going to be used and with what parameters.
This should be flexible and might want to be given by the client in the form of an ASN Object Identifier
with the appropriate parameters the server needs for encryption if any.

- Second: I don't want to be dependent on RSA encryption. I want to be able to choose between asymmetric and symmetric encryption.
To this end I suggest, if RSA encryption is not wanted (because the asymmetric key given by the client is not RSA, but for example DSA)
then a symmetric cryptography solution must be available.
I suggest using Diffie-Hellman (with or without EC) for key agreement.
Then encrypt with at least AES-128 with CBC.
This can be done in just one exchange, if the client immediately supplies the server with its DH pub key part.
The server calculates the DH secret, encrypts the cookie with AES and then sends this together with its own DH pub key part to the client.
The client then proceeds to calculate the DH secret and used this to decrypt the cookie with AES.
The cookie must be signed with the server's private key which is paired in the certificate the server supplied the client with for authentication purposes.

Note that the cookie is 128 bits.
Why not make this a variable amount with as minimum 128 bits and a server defined maximum.
This information can be exchanged in the association exchange.
The server does have to save the cookie bit strength per peer if we do this.
But this keeps the cookie bit strength somewhat flexible per client preference.


- Time Request:
This might have an optional signature attached before digest.
The digest also includes the signature.
This could ensure that the client knows for certain that the message comes from the server.

What to do for the association up to the cookie exchange with hashes?
Should we just supply a hash at the end of every extension?
The association message can provide the hash algorithm to use for its request and for any subsequent exchanges.

OpenSSL crypto stuff:
An online book which is helpful in figuring out the OpenSSL API:
http://it-ebooks.info/read/263/

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: 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-2019 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