[ntp:questions] Re: hacking NTP autokey with / without IFF

David L. Mills mills at udel.edu
Mon Jan 10 04:13:54 UTC 2005


The NTP project page has an extended discussion on identity scemes and 
security compartments. I do admit it gets rather tricky for multiple 
compartments and multi-level forests. There are some diagrams there that 
may make it more clear.

Make it harder. R becomes a middleman between S and C and tries to 
convince C it has the identity key. But, that key has been encrypted by 
the trusted host using a secret key provided by C. It could be of course 
that C does something stupid, like decrypt the key and reveal it to R. 
Clearly, it is not in C's interest to do something stupid like that, but 
the same sort of assumption holds on the private component of the 
public/private key pair.

Note that in those identity schems that are zero-knowledge that the key 
itself is never revealed and that the blinding schemes are used only 
once. In addition, the MV scheme, while practical for only a small 
number of servers and clients, is revocable.


manel_torralba at mail.com wrote:
> Hi all,
> I am trying to understand correctly the autokey NTP security schemas.
> Could somebody verify if the following scenarios are right, and if
> wrong, why ?
> Basically , let´s suppose there is a simple scenario with S as the
> single ntp server and C as the "interesting" ntp client, say, a
> Certificate Authority in a PKI. And we have our fiend R, a rogue server
> whose goal is to get C´s client wrong.
> Scenario 1: S and C use Autokey but no IFF (or any other identity
> schema)
> - R kills S and takes over its IP (or some similar scenario without
> killing S, but via manipulation of an intermediate router).
> - R makes sure it has S´s hostname and generates the ntp-keygen -T
> parameters.
> - C synchronizes with R. C´s time is hacked.
> Scenario 2: S and C use Autokey + IFF.
> - R steals the IFF group key. He can steal it from any of S´s clients
> or from S itself.
> - R installs the IFF group key.
> - Rest of the steps as above (killing of S, etc..)
> Please note that I am not evaluating how good or bad this is as a
> security model... I am only trying to make sure I understood it
> correctly (or maybe not, but where am I mistaken?).
> Thanks everyone in advance,
> Manel T.-

More information about the questions mailing list