[ntp:security] [Bug 2936] Skeleton Key: Missing key check allows impersonation between authenticated peers

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Wed Oct 28 05:52:14 UTC 2015


Juergen Perlinger <perlinger at ntp.org> changed:

           What    |Removed                     |Added
                 CC|                            |perlinger at ntp.org

--- Comment #3 from Juergen Perlinger <perlinger at ntp.org> 2015-10-28 05:52:14 UTC ---
Danny and Harlan, you have both a point there.

'Hijacking' a key that is used for another peer is only possible if a key is
already compromised.

Hijacking after authentication can be prevented by keeping the (auto-)key in
the peer structure once a peer authenticated itself with it. Packets that need
cryptographic authentication are validated against this key and ignored
otherwise. (This must be of course 'forgotten' when the peer association

Alas, this does not prevent *establishing* a peer connection from a rogue peer
under false identity. To prevent *this*, we need an association between IP
addresses and the allowed keys for an address, and such does not exist yet.

The first issue should not be too hard to tackle, but it doesn't get us very
far without solving the second one.

The options we have here is either another key format that includes addresses
associated with the key (which is IMHO a massive compatibility problem) or an
additional config file that provides that associations. The additional config
data takes a bit more effort to maintain, but it might be more secure and
provide a better migration path.

An additional step could 'quarantine' key material that has been found to be
used in fraudulent ways, e.g. by moving it into another directory (so it cannot
be used again) and dropping the autokey from the key store.

Am I missing something vital here, or would implementing these 3 steps solve
the issue?

Configure bugmail: https://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the security mailing list