[ntp:security] NOEPEER patch

Martin Burnicki martin.burnicki at meinberg.de
Mon Jul 30 12:52:17 UTC 2018


Harlan,

Harlan Stenn wrote:
> Martin,
> 
> Pearly and I have been chatting about this for the past hour.

We've also run some tests here in the mean time. See below.

> Here's the thing:
> 
> We get an AM_NEWPASS situation.  This is one of several cases.
> 
> 1) it's a broken Windows client.  We want to respond to these.
> 
> 2) it's not a broken Windows client.  We want to drop these if NOEPEER
> is set.  We want to spin up an ephemeral association otherwise.
> 
> The problem is that for the Windows case, we just call fast_xmit() to
> send the response without spinning up an association.
> 
> For the non-windows case, we want to either drop the packet without
> responding (if NOEPEER is set), or spin up an association.
> 
> We cannot first respond with a fast_xmit() and then decide if we want to
> spin up an association or not.
> 
> We have to be able to know if the incoming request is from a broken
> windows client or not.
> 
> Do you know how we can do that?
> 
> Similarly, it would be helpful to know if we can respond to these broken
> windows clients with a mode 4 (Server) response instead of a mode 2
> (Passive) response, just to try and let the client know what's going on.
> 
> I'd hate to be debugging why one side thinks it's doing a (passive)
> symmetric association when the other (ntpd) side is just responding with
> symmetric passive packets without actually bringing up an association.
> 
> Can't this problem also be solved with the ntp.keys file, where the
> LANtime server would have a 4th argument of an IP address (possibly
> localhost) so that you would not need to use NOEPEER on local networks?
> 
> Does the LANtime create ephemeral associations from Windows clients?

No, actually it doesn't, even if the NOEPEER keyword isn't specified.

The original problem was that an ephemeral association was mobilized on
the local node if the remote node used a valid symmetric key, but the
remote node wasn't explicitly configured. This should be prevented by
the NOEPEER keyword.

I've put some pseudo code together describing the program flow that I
think is appropriate:

  // A symmetric Packet has been received.

  if ( !auth_used ) //packet has signature
  {
    // Should we eventually accept it
    // as ephemeral peer anyway?
    // Probably not.
    goto send_reply;
  }

  // Packet has a signature.

  if ( !auth_ok )  // signature not valid
  {
    // We never accept it.
    send_crypto_nack();
    goto done;
  }

  // Aut is used and OK.

  if ( remote_peer_is_configured )
  {
    // This is a standard peer association.
    assoc_type = standard;

    // No need to check NOEPEER flag.
    goto create_assoc;
  }

  // This is an ephemeral peer.
  assoc_type = ephemeral;

  // Check NOEPEER flag if we accept it.
  if ( noepeer_flag )
  {
    // We don't accept ephemeral peers.
    goto send_reply;
  }

create_assoc:
  // We get here only if we accept a standard
  // or ephemeral peer association for this
  // remote node.
  create_assoc_if_required( assoc_type );

send_reply:
  // Send a reply with or without signature,
  // depending on whether the request had
  // a signature. We don't get here if a
  // signature was used, but not valid.
  send_reply_msg();

done:  // That's it!


So as a summary:

- A reply (symmetric passive in case of a symmetric active request) is
sent in any case, except that we send a crypto NAK if the request had an
invalid signature.

- A peer association is mobilized only if auth is used and OK, and
-- if the NOEPEER keyword has *not* been specified
-- or the remote peer has explicitly been specified as peer.


We have verified here that Windows clients that send unauthenticated
symmetric active requests are happy if they receive an unauthenticated
symmetric passive reply from the server.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

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
Training: https://www.meinberg.academy



More information about the security mailing list