[ntp:security] NOEPEER patch
martin.burnicki at meinberg.de
Thu Aug 2 11:25:55 UTC 2018
I'm trying to find out more details on this.
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".
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 5281 9309-414
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de https://www.meinbergglobal.com
More information about the security