[ntp:security] NOEPEER patch
stenn at nwtime.org
Thu Aug 2 11:31:51 UTC 2018
On 8/2/2018 4:25 AM, Martin Burnicki wrote:
> I'm trying to find out more details on this.
Very much appreciated, Martin!
This is another one of these intricate situations that I would like to
avoid. In this case, we clearly need the intricacy. And this is why if
we can avoid stuff like this (Windows boxes sending ACTIVE packets
instead of CLIENT packets by default, for example), i prefer to keep
It's 0430 here and I'm probably going to fall asleep soon.
> Harlan Stenn wrote:
>> On 8/2/2018 3:35 AM, Martin Burnicki wrote:
>>> I'm currently running tests with the updated ntp_proto.c file you provided.
>>> A strange observation I've made even with the original ntp_proto.c:
>>> If the local ntpd receives an "symmetric active" packet signed with an
>>> unknown/untrusted key, it sends a "symmetric **active**" packet with a
>>> crypto NAK back to the remote node.
>> Yes, it looks like it has done this for Years.
>>> Contrarily, if a "client" request with unknown key is received, a
>>> "server" reply is sent back, with a crypto NAK appended. So shouldn't
>>> ntpd send a "symmetric **passive**" response with crypto NAK in this case?
>>> This would make more sense to me.
>> It makes more sense to me, too, and my thoughts are we leave the legacy
>> behavior in place and change this in ntp-4.4.
>> I'm open to discussion about this.
>>> When the remote node that initially sent the "symmetric active" request
>>> receives the "symmetric **active**" response with crypto NAK then it
>>> also generates an error message that is IMO misleading in this case, e.g.
>>> Invalid-NAK error at 20
>>> This message is repeated after each symmetric active poll.
>>> This would mean that the **NAK** is invalid, but actually a valid crypto
>>> NAK was received in a response simply because an unknown key has been
>>> used in the request.
>> An invalid crypto-NAK means at least one of the following is true:
>> - The packet is not a SERVER, ACTIVE, or PASSIVE packet, or
>> - the keyID is not 0, or
>> - there is no peer association, or the peer doesn't use crypto,
>> or the peer is not using Autokey, or
>> - the packet has a 0rigin, or a zero myorg, or the peer origin
>> doesn't match myorg
>> So one of the above must be true. Apparently not the first 2 cases, so
>> the third and/or fourth cases must be true.
>> If the NAK is invalid, we should not pay attention to it. Believing an
>> invalid NAK is a DoS attack. This won't cause the packet to be
>> believed, but it will prevent an otherwise valid association from being
>> So if this is a valid NAK, we need to augment the tests above.
>> I'd rather not delay p12 for this. But I will if you think it's
>> important. Would you please open a bug report on this?
>>> Not sure under which other conditions this log message is generated, but
>>> I think we should first make sure that the response packet mode for this
>>> case is changed to "symmetric **passive**". An extra log message
>>> shouldn't be necessary since the "Auth not OK" should be visible in the
>>> ntpq billboard, but eventually a debug message could be generated instead.
>> Does changing the response from ACTIVE to PASSIVE make any difference here?
>> If we can identify exactly why the above list of tests are wrong in this
>> case, that will change this from an INVALIDNAK to a VALIDNAK.
>> But we have to do the right thing here.
>> I'm curious how this change will make a difference. The result will
>> still be that the association is being rejected because the MAC was "wrong".
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!
More information about the security