[ntp:security] NOEPEER patch

Harlan Stenn stenn at nwtime.org
Thu Aug 2 11:10:20 UTC 2018


On 8/2/2018 3:35 AM, Martin Burnicki wrote:
> Harlan,
> 
> 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
torn-down.

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 <stenn at nwtime.org>
http://networktimefoundation.org - be a member!


More information about the security mailing list