[ntp:security] [Bug 3043] Autokey association reset

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Mon May 23 09:33:07 UTC 2016


http://bugs.ntp.org/show_bug.cgi?id=3043

Harlan Stenn <stenn at ntp.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stenn at ntp.org

--- Comment #5 from Harlan Stenn <stenn at ntp.org> 2016-05-23 09:33:07 UTC ---
(In reply to comment #2)
> As I discussed with Harlan for some time, CRYPTO_NAK is a design bug. It is not
> authenticated and therefore totally untrustworthy. The only sane decision is to
> completely disregard any CRYPTO_NAK packages.
> 
> The same essentially holds for all packets where MAC authentication fails.
> These should be IMHO summarily ignored.
> 
> Checking the origin time stamp might avoid some attacks by creating a small
> time window (instead of one of unlimited size) but it is still possible for an
> attacker to send a forged CRYPTO_NAK soon enough (before the real server
> replies) to run a successful attack.
> 
> I'm admittedly not deep enough into this, but I have gathered the impression
> that ignoring packages with bad authentication and CRYPTO_NAKs in general is
> the only way to go. Just my 5c, though, and I want some more votes on that
> before I start to butcher the code.
> 
> This would essentially cure bug 3044 and bug 3045, too. I'm just not sure what
> it would break.

By definition, a crypto-nak cannot be reliably authenticated.  Its primary
purpose is to speed up a resynch in the case a key has expired.  The pros/cons
of the crypto-nak should certainly be discussed, however.

-- 
Configure bugmail: http://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