[ntp:security] NOEPEER patch

Harlan Stenn stenn at nwtime.org
Fri Aug 3 18:51:32 UTC 2018


It’s a good change, I think. Instead of bailing early saying it’s good, we bail early when we know it’s bad, and only say it’s good at the very end, when no problems are found. 

Sent from my iPhone. Please excuse brevity and typos.

> On Aug 3, 2018, at 11:20 AM, juergen perlinger <juergen.perlinger at t-online.de> wrote:
> 
> Hello Harlan, hello Martin,
> 
>> On 08/03/2018 05:28 PM, Martin Burnicki wrote:
>> Harlan,
>> 
>> Harlan Stenn wrote:
>>> Before Pearly's change, the code was:
>>> 
>>>  if (   peer
>>>      && (peer->keyid > 0 || peer->flags & FLAG_SKEY))
>>>    return VALIDNAK;
>>> 
>>> and now it is:
>>> 
>>>  if (!peer || !peer->keyid || !(peer->flags & FLAG_SKEY)
>>>    return INVALIDNAK;
>>> 
>>> and I think we want:
>>> 
>>>  if (!peer || (!peer->keyid && !(peer->flags & FLAG_SKEY))
>>>    return INVALIDNAK;
>>> 
>>> or:
>>> 
>>>  if (!peer || !(peer->keyid || (peer->flags & FLAG_SKEY))
>>>    return INVALIDNAK;
>> 
>> This makes sense to me. Pearly's change has also changed the behavior.
> 
> Seems I messed it up somewhere in time. I'll check tomorrow when & why I
> made that change... right now it's too hot to think clearly...
> 
>> 
>> I've now changed this code section to
>> 
>>    /*
>>     * During the first few packets of the autokey dance there may
>>     * not (yet) be a keyid, but in this case FLAG_SKEY is set.
>>     * So the NAK is invalid if either there's no peer, or
>>     * if the keyid is 0 and FLAG_SKEY is not set.
>>     */
>>    if (!peer || (!peer->keyid && !(peer->flags & FLAG_SKEY))) {
>>        return INVALIDNAK;
>>    }
>> 
>> as you proposed, which restores the behavior of the original code.
>> 
>> I didn't find the time today to test all variations, but with this patch
>> 
>> - Peering works with a valid symmetric key.
>> 
>> - If an unknown key is used then "ntpq -c as" reports "auth bad" as
>> expected, but there are no nasty "Invalid-NAK" messages that were
>> previously sent to the syslog after each poll.
>> 
>> So I think this is a good solution. More tests to come.
>> 
>> 
>> Martin
>> 
> 
> 



More information about the security mailing list