{{toc}}

Rationale

In general I’m worried about unauthenticated NTP. There probably is a whole bunch of fingerprinting attacks an attacker could mount if it could pose as the NTP server and mess with the user’s time.

Also see Tails design documents about NTP and HTP.

Authenticated NTP

As of NTPv4 the Autokey protocol has been implemented which enables public key based authetication. According to the friendly people at #ntp@freenode, a gpg like authentication scheme (i.e. get the public key of the server, configure to use that server with that key, and that’s it) was implemented in 4.2.6 (latest stable) which fits our needs perfectly. It remains to research exactly how that works. Here are a few things to consider:

• We cannot use pool.ntp.org, which perhaps would be the optimal way to prevent fingerprinting of amnesia users. This is due to the fact that we need a key for each server we want, and far from all servers in the pool has autokey enabled. So we will have to use a fixed, predetermined and thus public set of servers since we need to ship their public keys with amnesia.
• For redundancy, more than one server need to be added. But how many? How much do we have to trust each server? How does the size of the set of servers affect fingerprinting and how does it relate to trust? Etc.
• We likely should contact the owners of all autokey-enabled servers and ask if they want to support our cause — we don’t want to [be like D-LINK.
• One outstanding problem is that very few open access (i.e. available to all) ntp servers support Autokey, and even fewer the particular gpg-like scheme since it require the latest stable ntp which has only been out since december 2009. Reasons for the low adoption of autokey in general might be that people don’t know or care about it, the extra complexity of configuration, difficulty of setting up ways to distribute keys to the clients (which is not part of the protocol — but with the new pgp like scheme this becomes easier for clients), and extra strain on the servers due to the added crypto operations needed.

=> Authenticated NTP is a long term goal for us, but not usable for the time being. Let’s (try to) use HTP in the meantime.

Update

NTP autokey … which fits our needs perfectly …

Or not. NTP autokey does not work behind NAT.

HTP

Our design document describes the implemented solution.

This item is now done.