Subject: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp

From: Sharon Goldberg <[email-masked]>
Date: Thu, 31 Aug 2017 13:13:52 -0400

Review of NTS.

First of all, I wanted to congratulate Daniel, Dieter, and Kristof on the
great progress made with this draft. This is great work, and much improved
since the last WGLC for NTS.

My comments, in linear order after reading through the draft that was in
GitHub 4 hours ago, are below.

https://github.com/dfoxfranke/nts/commit/5835e584cff6b224335
0fd6e8cd8cb3808d58c5d

This is a fairly detailed review, that raises several issues.  That said, I
still don't have a complete understanding of how the client-server NTS
protocol works or of its security properties, and would like to give it
another read after the authors have edited the draft to clarify some of the
issues I read below.

Thanks,
Sharon

****

Section 1.1: The unlinkablilty objective, as written, is misleading. NTS
only promises to not leak more linkability information that what is already
being leaked by NTP.   As written that reader could assume that NTS
promises to fully guarantee unlinkability, which is false, since NTP could
make the session linkable.  It's not sufficient to bury this point in the
security considerations section, so this should be reworded.

****

Section 1.2:  Says:

    However, client-server mode also has more
   relaxed security needs, because only the client requires replay
   protection: it is harmless for servers to process replayed packets.

This is false.

It can be harmful for a server to process replayed packets if that server
keeps client state in order to perform rate limiting with a KoD.
Specifically, an adversary can replay client packets at high rate to the
server, in order to trigger rate-limint restrictions at the server and
cause the server to send a "RATE" KoD to the client. Once the client
receives this KoD, it will slow down or even stop its communications with
the server.  In other words, this is a DoS attack.

This is CVE-2015-7705 which we called the "priming the pump"  attack in our
NDSS'15 paper:

https://eprint.iacr.org/2015/1020.pdf

Thus, I suggest that the draft include some language targeted at servers
that do perform rate limiting with the KoD.  Those servers MAY take
advantage of NTS's replay protection to stop the Priming the Pump attack.
In other words, these servers MAY track the client's unique identifiers and
making sure that they are not reused, as a way of preventing the priming
the pump attack. I am suggesting the use of MAY because this can be
resource intensive for the server.  (But, a data structure like a bloom
filter could be used to minimize the overhead at the server of checking
uniqueness of "unique identifiers").

I also suggest adding some text to the security considerations, explaining
that when the server uses (1) rate limiting with the KoD but (2) does not
use NTS's replay protections, then the server is vulnerable to the Priming
the Pump attack of CVE-2015-7705.

****

Page 5: "As previously stated, DTLS-encapsulated NTPv4 is trivial.  The
   communicating parties establish a DTLS session and then exchange
   arbitrary NTP packets as DTLS Application Data."

Nit: It's probably best to avoid judgement calls ("trivial") here.

****

Section 4: Regarding security of the control mode:

   For control mode (6), the party sending queries should be the DTLS
   client and the party responding to the queries should be the DTLS
   server.

I think we are missing an opportunity here to secure the control mode, and
I'm not convinced that DTLS is the right approach.

I would like to see this draft specify some way for servers to require
client authentication before answering control queries.

Why are we not considering the use of SSH? It makes much more sense to have
the machine that sends the control query authenticate itself to the
responding machine. That way, arbitrary attackers cannot just query the
server and learn sensitive information about its state (or even modify its
state using a write command).

If we do think we are gaining something by securing the control mode with
DTLS, the draft should spell out exactly what this security property is.

****

Section 4. The description of symmetric mode operation is underspecified. I
read it several times and I don't understand how it works.  The draft says:

   For symmetric operation between an active (mode 1) and passive (mode
   2) peer, the active peer should be the DTLS client and the passive
   peer should be the DTLS server.

   For symmetric operation between two active (mode 1) peers, both
   parties should attempt to initiate a DTLS session with their peer.
   If one handshake fails and the other succeeds, the successfully-
   established session should be used for traffic in both directions.
   If both handshakes succeed, either session may be used and packets
   should receive identical disposition regardless of which of the two
   sessions they arrived over.  Inactive sessions may be timed out but
   the redundant session should not be proactively closed.

I don't understand how two DLTS associations are used at the same time,
given that symmetric mode uses a single request-response ladder for both
peers to derive the time.

I also don't understand the last sentence quoted above.  What does
proactively mean? Under what conditions should you actually close the
session?

Miroslav made this comment already, and I know that Daniel is current
updating this text (have not seen this update yet) but I wanted to support
Miroslav's concerns.

****

Section 5:

Nit:

    Immediately following a successful handshake, the
   client SHALL send a single request (as Application Data encapsulated
   in the TLS-protected channel), then the server SHALL send a single
   response followed by a TLS "Close notify" alert and then discard the
   channel state.

Maybe change this "MUST discard the channel state" (or SHOULD)?   In order
to minimize the attack surface of someone compromising the server and then
using the old channel state that is sitting around in order to launch
attacks.

That said, if there is a good reason to keep the channel state, maybe the
draft should specify what that reasoning is. (I'm struggling to understand
why anyone would want to keep the channel state around.)

******

Section 5:

As a point of presentation: I had trouble getting a high level view of the
protocol from reading Section 5.  Some issues confused me that I think
should be defined up front.  In other words, I think Section 5 should start
with some prose (even a new subsection) that gives a detailed overview of
the protocol.

Pointing out some specific confusions of mine.

- There are several "numbers" defined in this document, and it is hard for
the reader to disambiguate between them. Specifically, there is the "Next
Protocol number" and the "Field Type" and the "Record Number". The start of
Section 5 should start by telling the reader what are the different
"fields" and "types", and each of their purposes.  I also suggest providing
references to the relevant IANA Considerations in Section 8.

- This section would benefit by showing a ladder presenting the sequence of
communications and message types that go back and forth during a typical
NTS exchange.

- I'm not clear if the C, record type, and body length fields depicted in
Figure 1 need to be authenticated by the AEAD authenticator.  Maybe this
should be spelled out more clearly.

****

Nowhere in the document do a see an explicit statement about when the
client is allowed to start taking time from an NTS-secured server.  I think
the draft should spell this out, at the very minimum with a SHOULD
requirement, and possibly even a MUST.  To do this, it would help to have a
ladder that shows the protocol flow, and spells out in what point in the
flow the client can start taking time.

****

Error codes:

I'm worried about the error messages defined in Section 5.1.3 and warning
in 5.1.4. Specifically I am worried that they could be used a attack vector
for DoSing the client.

My worry comes because, unless I misunderstood the draft, it looks like the
client can act on an unauthenticated error code.  That is, the client will
tear down an NTS association upon receipt of the error message (error code
1).

I worry that an off-path attacker can use this to maliciously cause the
client to tear down an association (by injecting a bogus error packet to
the client).  One way to prevent this is to force the client to validated
the unique identifier extension on the error packet. However, I cannot tell
from the draft whether or not the client is required to do this.

If the intention of the draft is *not* to prevent this attack, then it
should be spelled out in the security considerations section. If the draft
is preventing this attack, then this shoudl be explained more clearly.

A similar issue is whether an on-path attacker (that can eavesdrop and
inject packets but not drop or modify packets, (note: this is the threat
model for the great firewall of china)) can inject error messages.  This
sort of attacker, that does not have the power to drop packets, can still
inject error messages in order to tear down NTS connections.  And, since
this attacker can eavesdrop, the unique identifier field will not thwart
this attack.

If the intention of the draft is not to prevent this attack, then this
should be spelled out in the security considerations section.

Alternatively, if I misunderstood the draft, then the draft should be
edited to clear up my misunderstanding. That is, there should be an
explicit statement in Section 5.1.4 and 5.1.3 about whether or not the
client can act on an unauthenticated error message, and whether or not the
unique id field of the error message needs to be validated.

****

A similar issue on error messages:

Why does NTS have both error messages, but also uses the NTS NAK in a kiss
of death packet?

My preference is for a simpler protocol that has only 1 type of error
message.  Why doesn't just one type suffice?  If there is a reason to have
two types of error messages, then the draft should more clearly explain the
use case for each type.

Note also that as written, per page 17, the NTS NAK can be exploited by the
on-path attacker (that can eavesdrop and inject packets but not drop or
modify packets) in order to DoS the client, as I described above.  Thus, at
the very least, the security considerations of this draft should
acknowledge this attack.

*****

Nit: Section 5.1.4, I raised this point earlier when I talked about the
need for an overview of the protocol and a ladder at the start of Section
5. To reiterate.

I don't understand what it means to "proceed to the Next Protocol".

****

5.1.5  says:

    Server implementations of NTS extension fields for NTPv4 (Section 6)
   MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifier 15).
   That is, if the client includes AEAD_AES_SIV_CMAC_256 in its AEAD
   Algorithm Negotiation record, and the server accepts Protocol ID 0
   (NTPv4); in its NTS Next Protocol Negotiation record, then the
   server's AEAD Algorithm Negotiation record MUST NOT be empty.

Question: Does this mode of operation include any restrictions on how many
messages can be encrypted and authenticated?  If so, this draft should
respect this restriction and require rekeying after that number of
message.  If not, this draft should point to the place in RFC5297 where it
says that there is no such restriction, or point out that the restriction
is sufficiently high that we can never expect to exceed it.

(NOTE: I did not have time, while preparing this review, to understand this
 AEAD_AES_SIV_CMAC_256 mode of operation, so I am raising this question for
Daniel to answer.)

Also, does the fact that RFC5297 is informational, while this draft is
standards track, create any issues for us?

*****

5.1.6  Cookies.

Earlier on this list there was discussion on whether or not the draft
should specify normative requirements on cookies.  Personally, I support
that view that we should place normative requirements on cookies, because
an insecure cookie implementation would break the security of the whole
protocol.

That said, what is a show stopper in my opinion, is a lack of specification
in the draft of what properties are required from the cookie.  At the very
least, we want to make sure that the cookie does not leak the C2S and S2C
keys to an observer (or a man in the middle).

If I have misunderstood, and this confidentiality is provided because the
cookie is encrypted (as a MUST) by the AEAD scheme, then the draft should
make this point more clear in section 5.1.6.

Also, is there a requirement that cookies be different across different
clients? That each cookie used by a client is unique?  At the very least
these requirements should be spelled out as a MUST somewhere.  If SHOULD is
used, then a discussion of the risks of not adhering to these requirements
should be provided.

If this is somewhere in the draft already, and I missed then, then
apologies. But this text should be referenced in Section 5.1.6.

******

Section 6.3

I like this section a lot but suggest the text below be edited from:

   The Unique Identifier extension field has a Field Type of [[TBD2]].
   When the extension field is included in a client packet (mode 3), its
   body SHALL consist of a string of octets generated uniformly at
   random.  The string SHOULD be 32 octets long.

to "The string MUST be at least 32 octets long."

***

Section 6, final comment.  I read this section a few time, but I still
don't have a great picture in my head of how this protocol works and how it
acheives its security goals. I would like to give it another read once it
is updated to address my comments.

*****

I did not review Section 8 in detail.

****

Section 9:

Section 9.1: I like this section very much.

But it would help to also have some discussion about how NTS prevents the
control mode from being exploited for DoS, since this is the main vector
that NTP DoS amplification attacks exploit.  That said, I don't think this
draft goes far enough regarding the security of the control mode, as I
mentioned in an earlier comment.

Section 9.2:  Verification of Server Certificates:

I also like this section very much. Some clarification questions:

The following paragraph should include some citations, so that readers can
better understand why the check works. As written it is too implementation
dependent. There should be a cite to what NTP_PHASE_MAX means and what
ntp_gettime() is expected to return.

      Check whether the system time is in fact unreliable.  If the
      system clock has previously been synchronized since last boot,
      then on operating systems which implement a kernel-based phase-
      locked-loop API, a call to ntp_gettime() should show a maximum
      error less than NTP_PHASE_MAX.  In this case, the clock should be
      considered reliable and certificates can be strictly validated.

In the paragraph below, the term "strictly validated" needs to defined.  Is
this paragraph suggesting validating time with a human? Or somethign else?

      Allow the system administrator to specify that certificates should
      *always* be strictly validated.  Such a configuration is
      appropriate on systems which have a battery-backed clock and which
      can reasonably prompt the user to manually set an approximately-
      correct time if it appears to be needed.

The following two recommendations are so important. I think the draft
should elevate these recommendation to SHOULD and put it the TLS profile
section, rather than bury it in the security considerations section:

        Once the clock has been synchronized, periodically write the
      current system time to persistent storage.  Do not accept any
      certificate whose notAfter field is earlier than the last recorded
      time.

       Do not process time packets from servers if the time computed from
      them falls outside the validity period of the server's
      certificate.

Section 9.4:  (Delay attacks)

I think the following sentence is false:

    However, the maximum error that an adversary
   can introduce is bounded by half of the round trip delay.

Why cannot an adversary delay the query an indefinate amount of time, and
then send it to the server, and then pass on the server's response?  Eg
delay the query 1 hour, then send to the server, then let the response pass
by you unmolested.  The error here would be huge (1 hour on the forward
path, and ms on the reverse path).

Similarly I don't understand why the second paragraph of Section 9.4 is
true.

   [RFC5905] specifies a parameter called MAXDIST which denotes the
   maximum round-trip latency (including not only the immediate round
   trip between client and server but the whole distance back to the
   reference clock as reported in the Root Delay field) that a client
   will tolerate before concluding that the server is unsuitable for
   synchronization.  The standard value for MAXDIST is one second,
   although some implementations use larger values.  Whatever value a
   client chooses, the maximum error which can be introduced by a delay
   attack is MAXDIST/2.

I suggest cutting both of these from the draft. Even if they were correct,
I don't think are important for the draft. It's probably not worth while
for us to argue about them.

Section 9.5, suggested rewording:

    Whenever this draft specifies the use of random numbers, then
cryptographically
    secure random number generation MUST be used. See [RFC4086] for
guidelines concerning
   this topic.

(I am worried about implementations that eg. will use ntp_random() which is
not cryptographically secure.)

Section 10.4

I like the MUST requirement here about implementation of
ntp-data-minimization.  Given the amount of protocol mechanisms and
complexity we have introduced in order to provide unlinkability, its
important to also require that devices adhere to ntp-data-minimization if
they actually want unlinkability.

Also for this paragraph:

   It should also be noted that it could be possible to link devices
   that operate as time servers from their time synchronization traffic,
   using information exposed in (mode 4) server response packets (e.g.
   reference ID, reference time, stratum, poll).  Also, devices that
   respond to NTP control queries could be linked using the information
   revealed by control queries.

Suggested expansion:

   It should also be noted that it could be possible to link devices
   that operate as time servers from their time synchronization traffic,
   using information exposed in (mode 4) server response packets (e.g.
   reference ID, reference time, stratum, poll).  Devices that do not
   wish to be linked in this way SHOULD NOT respond to (mode 3) client
   query packets from unknown IP addresses.

   Also, devices that respond to NTP control queries could be linked using
the information revealed by control queries. Devices that do not
   wish to be linked in this way SHOULD NOT respond to control query
packets
   from unknown IP addresses.

Thanks for reading this far :)

-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp