[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
> - 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
> - 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