dfoxfranke/nts

IETF I-D for Network Time Security

nts's Issues

SM-D-28: Section 9.2

SM:

In addition to dropping
packets and attacks such as those described in Section 9.5, an on-
path attacker can send spoofed kiss-o'-death replies, which are not
authenticated, in response to NTP requests. This could result in
significantly increased load on the NTS-KE server.

Why? I presume this text means that the KoD is a NTS-NAK and client
who sees the NTS-NAK would restart the whole process with the
NTS-KE server. That is optional behavior in Section 5.7 page 23,
and then only "upon forced disassociation" from the server, which
the text does not require of the NTP server that sent an NTS-NAK.

SM-D-27: Section 7.6 page 28

SM:

Applications for new entries SHALL specify the contents of the
Description, Set Critical Bit, and Reference fields as well as which

"Set Critical Bit" is not a field in the registry entries' field
descriptions above and not included in the table below.

Fix privacy leak in anti-amplification scheme

http://lists.ntp.org/pipermail/ntpwg/2016-August/003015.html:

An attacker can infer from the length of the server's encrypted reply
whether the IP address encoded in the request cookie matches the IP
address of the sender. But that means that when an attacker observes a
short reply to a request that came from a particular IP, the attacker
can then repeatedly replay that request from spoofed IPs, enumerating
the entire space of IPv4 addresses if necessary, until a long response
comes back. At that point the attacker can infer that the IP which got
the long response is the one encoded in the cookie, thus linking the
client's old IP address to its new one.

Fix this by creating a new "Cookie placeholder" extension for the client to include in its request, with its body consisting entirely of padding equal in length to a cookie. The number of cookies send back by the server should always be one plus the number of placeholders sent by the client, regardless of IP address.

Use SIV mode for cookies

Replace the AES-CBC-then-HMAC-SHA-256 with AES-SIV (RFC 5297). This will maintain (and improve) resistance to nonce reuse while also improving performance and unifying everything into an RFC 5116 framework.

SM-D-8: Section 4.1.3 page 11, 1

SM:

Clients MUST NOT include Error records in their request.

What if it does? Does the server drop, respond with an Error, send the
TLS "Close notify" alert, what? If responding with Error, what code -
Bad Request or Internal Error? (I'm not sure format errors fit in the
Bad Request description, tho' they certainly fit the name.)

SM-G-9

SM:
Section 9.4 page 36 - Is there a reference for “NTP_PHASE_MAX?” A web search found only references to this draft and to a “kernel constant” in various *nx man pages.

SM-D-31: Appendix A

SM:
(I wasn't going to note this nit, but since you have a list...)

NTS NAK should be on this list.

Actually, NTS NAK is not defined before it is used. In Section 5.7, page 23
it says "NTS negative-acknowledgment (NAK)" but it does not say
"NTS NAK". So a search for the acronym does not find its definition.

SM-D-16: Section 4.1.7 page 13, 2

SM:

When this record is sent by the client, it indicates that the client
wishes to associate with the specified NTP server.

What if the client wishes to associate with more than one NTP server?
(that's recommended practice, so likely.) Does that mean multiple
requests to the NTS-KE server under the same TLS channel? [Section 4
intro page 8 makes that sound impossible.] does it mean opening
multiple TLS channels to the NTS-KE server?

SM-D-21: Section 5.7 page 21, 3

SM:

Servers MAY implement exceptions to this requirement for
particular extension fields if their specification explicitly
provides for such.

I figure this means something like:


The server MUST discard any unauthenticated extension fields,
UNLESS an exception is implemented for specific extension fields
whose specification explicitly provides for unauthenticated
transmission.

Maybe.

SM-D-2: Section 4, p 8

SM:

in the TLS-protected channel. Then, the server SHALL send a single
response
and
The client's request and the server's response
but
Requests and
non-error responses each SHALL include exactly one NTS Next Protocol
Negotiation record.

Is there a single request and single response, or plural requests
and responses? If there are many, do they have to have the same
Next Protocol?

SM-D-5: Section 4.1.2 page 11, 1

SM:

Protocol IDs listed in the server's response MUST comprise a subset
of those listed in the request and denote those protocols which the
server is willing and able to speak using the key material
established through this NTS-KE session.

It is clear that the server in "server's response" is the NTS-KE server,
but I believe that the server in "server is willing and able to speak" is
the NTP server that the client will eventually contact. Right?

SM-D-25: Section 6 page 24, 2

SM:

Servers should additionally choose a non-secret, unique
value I as key-identifier for K.
...
of this approach is to use HKDF [RFC5869] to derive new keys, using
the key's predecessor as Input Keying Material and its key identifier
as a salt.

RFC5869 says the salt is random. Should the text about choosing the “non-secret, unique” identifier mention random / unpredictable as well?

SM-D-23: Section 5.7 page 23

SM:

If the server is unable to validate the cookie or authenticate the
request, it SHOULD respond with a Kiss-o'-Death (KoD) packet

....

A client MAY automatically re-run the NTS-KE
protocol upon forced disassociation from an NTP server.

Is there a suggestion there that the server may force a disassociation
from the NTP server after sending the NTS NAK? (I don't know what
force that would be, NTP doesn't really have a session-connection-
channel-state on the server side.)

SM-G-8

SM:
On page 21, the caption for Figure 5 should be “NTS-protected NTP Time Synchronization Messages”. It is an NTP exchange, not an NTS exchange.

SM-D-24: Section 6 page 24, 1

SM:
This section uses "should" a lot, not SHOULD, in cases where it seems
to be describing recommended optional behavior and sometimes when it
is describing required behavior.
Perhaps that is because this is non-normative text, but distinguishing
between the required behavior and optional behavior in this text
is desirable, so I suggest deciding which uses of "should" are really
RFC21119 requirements language and make it SHOULD, MUST, SHALL, etc.

SM-D-29: Section 9.4 page 36

SM:

error less than NTP_PHASE_MAX.  In this case, the clock SHOULD be

Is there a reference for the "NTP_PHASE_MAX"? It is not in RFC5905.
A web search finds only hits in this draft and in various *nx man
pages as being a "kernel constant"

Address cookie-management algorithm

http://lists.ntp.org/pipermail/ntpwg/2016-August/003031.html:

On 8/23/16, Aanchal Malhotra <aanchal4 at bu.edu> wrote:
> Also, in section 6.1.6, why SHOULD the server send "eight" cookies?

Since a client SHOULD NOT send the same cookie more than once,
but can only obtain new cookies when the server sends them some,
we want to let the client keep a cache of spare cookies on hand so
that a single dropped packet won't force it to re-run the handshake.
I selected the number eight because it matches the number of times
ntpd will poll a server without response before marking it unreachable.

Incorporate this rationale into the text, and specify that clients SHOULD send
as many Cookie Placeholder extensions (see #2) as is necessary to bring
their supply of unused cookies back up to eight.

Split out "TBD"s

Every instance of [[TBD]] should be replaced with a <cref> describing what should be filled in.

SM-D-9: Section 4.1.3 page 11, 2

SM:

If clients
receive a server response which includes an Error record, they MUST
discard any negotiated key material and MUST NOT proceed to the Next
Protocol.

Does "negotiated key material" mean the TLS negotiated material?

Does the client retry with a new request? (next paragraph would seem to
indicate retries are possible with modification, Section 4 intro pg 8
makes retries sound impossible.)

If the client is discarding the TLS negotiated materials, does the client close the TLS channel and start over from the beginning? That Section 4
intro page 8 makes it sound like the client will be forced start over.

Clarify processing expectations for NAKs

More exposition is needed on why servers should bother sending NAKs and how clients should process them. See http://lists.ntp.org/pipermail/ntpwg/2016-August/003029.html

SM-G-1

SM:
I realize that I did not include one concern about the security considerations. Section 9.7 NTS Stripping talks about the client being deceived into reverting to plain NTP. There’s no discussion of the server being deceived into responding with plain NTP. An adversary who stripped the NTS extensions from the a NTP request would lead the server to reply without the expected NTS extensions in the response. What should/would the client do if it receives a non-NTS enhanced response to a NTS enhanced request?

[Steve Bellovin would frequently suggest that there should be a way for a recipient to know to expect security protections to prevent such downgrade attacks. I don’t think there is a way in this case.]

SM-D-17: Section 4.2 page 14

SM:

Inputs to the exporter function are
to be constructed in a manner specific to the negotiated Next
Protocol. However, all protocols which utilize NTS-KE MUST conform
to the following two rules:

So must all protocols with utilize NTS-KE be time protocols?

There are requirements here about what a Next Protocol must provide.
The cookie construction is another. Should there be a statement
about what a Next Protocol spec must include?

SM-D-18: Section 5.7 page 20 (nit)

SM:

already sent, it SHOULD initiate a re-run the NTS-KE protocol. The

"initiate a re-run of the NTS-KE protocol" or "SHOULD re-run the NTS-KE
protocol"

SM-D-6: Section 4.1.2 page 11, 2

SM:

The request MUST list at least one protocol,
but the response MAY be empty.

If the request is empty, what is the client to do? retry with a
different set of protocols? Close the TLS channel?

[There is text saying the the TLS session has minimal impact because
only one request and one response are exchanged, but retries change
that. And Section 4 intro page 8 says

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.

which makes retries unlikely.]

SM-D-15: Section 4.1.7 page 13, 1

SM:

Servers MUST NOT
send more than one record of this type.

What does the client do if the server does? Choose the first?
Drop the response and retry the request? Close the TLS channel?
Randomly pick one?

SM-D-30: Section 9.4 page 37

SM:

take care not
to cause an inadvertent denial-of-service attack on the NTS-KE
server, for example by picking a random time in the week preceding
certificate expiry to perform the new handshake.

This order makes it sound like the example is about the attack, not the
way to "take care not to cause".

SM-G-5

SM:
I found several cases where I was not sure what the error conditions should be handled, when requirements are not met, when an exchange fails, when an error condition is received, etc. In some sections, the receiver’s action upon receiving one message is explained but for other messages is not.

SM-G-7

SM:
The document sets up an IANA registry for the Protocol ID. Is it necessary to stipulate what a specification of a new Protocol ID must include? Must it include a cookie format, for example?

SM-D-19: Section 5.7 page 21, 1

SM:

          Figure 5: NTS Time Synchronization Messages

The caption should be "NTS-protected NTP Time Synchronization Messages".
The exchange in the figure is of NTP messages, not NTS messages.

SM-D-12: Section 4.1.5, page 12, 2

SM:

Server implementations of NTS extension fields for NTPv4 (Section 5)
MUST support AEAD_AES_SIV_CMAC_256

Does this apply to the client as well? If so, is it advisable for
the client to always include that algorithm? Is it mandatory for the
client to include that algorithm?

SM-G-2

SM:
Section 1 makes it clear that there is an intentional separation between the NTS-KE server and the NTP server, although it is allowed that both services could be resident on the same host. Figure 1 also makes it appear that the NTS-KE server may be associated with a large number of NTP servers, with unspecified means of communicating between them. Reading through, I was struck by how much the NTS-KE server must know about the NTP server - in Section 4.1.5 what algorithms it would support, in Section 6 the keying material it would accept. I was puzzled at how this could work in the post.ntp.org set of volunteer NTP servers. Then in Section 6, I saw a reference to “load-balanced cluster”, which would easily account for the NTS-KE server’s knowledge of the NTP servers’ configurations. More explanations of the supportable (current and potential) architectures would be very helpful.

SM-D-22: Section 5.7 page 22

SM:

In
general, however, the client MUST discard any unauthenticated
extension fields and process the packet as though they were not
present. Clients MAY implement exceptions to this requirement for
particular extension fields if their specification explicitly
provides for such.

Same complaint as on page 21 about "In general, ... the client
MUST discard..... and "MAY implement exceptions"

SM-D-1: Section 1.2, p 6

SM:

supply of cookies along with an IP address to the NTP server for
....
Time synchronization proceeds with one of the indicated NTP servers

The cookies are for one server, what are "the indicated NTP servers"
(plural).

SM-G-3

SM:
I believe it would be helpful for the implementers to have an explicit list of what the NTS-KE server must know about the NTP servers (address, algorithms supported, shared keys in use, cookie construction, protocol IDs accepted, anything else?) and what the communication between the NTS-KE server and the NTP server must provide (what Figure 1 calls “Shared cookie encryption parameters”).

Shorten NTS Next Protocol records

NTS Next Protocol Negotiation uses 16-octet protocol identifiers in imitation of ALPN, but this is rather gratuitous. Shorten them to two octets.

SM-D-7: Section 4.1.2 page 11, 3

SM:
Protocol ID 0 is the only defined protocol now, but is it MTI for
the server to support Protocol ID 0 always?

Switch MTI AEAD algorithm to something with a longer nonce

I started writing the security considerations around avoiding nonce
repetition with AES-GCM and concluded that it just can't be done
reliably. 96 bits is impossibly short in the setting we have to deal
with.

Since the server is stateless, the number of nonces that we need to
able to generate without a repetition isn't limited to the number of
requests that a "reasonable" client would make. An adversary can
capture a request and replay it as many times as the server can keep
up with.

So random nonces are right out: 96 bits means a 2**48 birthday bound
and that's far too low.

If servers run in load balanced clusters that share keys, each server
needs its own "namespace". We don't want to rely on admins to manually
assign a unique number to each server in the cluster, so maybe we
could the MAC address of a network interface. That chews up a lot of
bits right there, but maybe it's still okay.

What happens if a server crashes and loses the state of its nonce
counter? DJB's solution to this (I can't find the cite at the moment)
was to maintain a counter value on disk that's always well ahead of
highest nonce you've used. Make sure an updated value gets flushed to
disk before you reach the old value. But this is highly subject to
administrator error: what if the disk fails and its contents are
restored from backup?

Could we use timestamps? That's brittle too. It means servers can't
serve secure traffic until they've synchronized their clock, which
maybe isn't the worst thing but it's hardly ideal. For clients it's
even dicier.

My conclusion is that we just have to move away from AES_128_GCM and
choose something that has a longer nonce and/or is misuse-resistant.
Our choices, unfortunately are a bit limited.

Here's the list of everything that's been assigned an identifier by
IANA: http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml

All the AES-CCM modes have the same problem as AES-GCM. The AES-OCB
modes have an N_MAX of 15, which means a 2**60 birthday bound. That's
better than 2**48 but still pushing our luck. CHACHA20_POLY1305 has
N_MAX 12, which is particularly gauling, both that XChaCha20 doesn't
seem to be a thing, and that the CFRG chose ChaCha20 rather than
XSalsa20.

That leaves the AES_SIV_CMAC family, which seems to offer all the
properties we want: misuse-resistance and unlimited nonce length. The
construction has a security proof and is well-studied. Unfortunately,
there seem to be very few implementations: the only one I can find is
part of hostapd and I have no idea if it has ever been audited (not
that this would be a huge deal to do -- it's 188 lines of pretty
straightforward code).

As I mentioned to Aanchal earlier today, there's also
https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-01 which provides
similar misuse-resistance properties with better performance. N_MAX is
16, which combined with misuse-resistance is enough to make me
comfortable. But it's still a draft.

So for the time being, AES_SIV_CMAC_256 seems like the best choice
we've got and I am going to update the draft to have it replace
AES_128_GCM as the MTI algorithm. I don't know whether this will be
final. Next week I'll reach out to the CFRG for advice.

SM-D-4: Section 4, page 9

SM:

significant bit of the first octet. In C, given a network buffer

There is a bit called "C" discussed on this page, took me aback a bit.
Probably not a problem, but if there's an opportunity to say "In the C
language", maybe you should.

SM-G-6

SM:
Normative language: There are places where the text says “should” not “SHOULD” and it was not clear the RFC2119 language was intended. In particular, Section 6 uses “should” many times. Perhaps that was intentional since this section is not normative. I’m not sure what should (sic) be the usage in that case. “In general” appears many times, which begs the question of when it is or is not the case. On page 21, the text says “In general, however, the server MUST”. I’m not sure what that means to an implementer. The following language talks about exceptions, so perhaps the “In general” means “where there is no exception”.

SM-D-14: Section 4.1.6 page 13, 2

SM:

Servers MUST send at
least one record of this type

What does the client do if the server does not? Send a new request?

SM-D-26: Section 6 page 24, 3

SM:

Servers should periodically (e.g., once daily) generate a new pair
...
Immediately following each such key rotation,
servers should securely erase any keys generated two or more rotation
periods prior.

Does this mean that a client's cookies to its chosen NTP server will
no longer be usable after two daily rotations? (This presumes it does
no polls in those two days, because any new response would provide
a new cookie.) Must it go back to forming a TLS channel and an NTS-KE exchange? If the NTS-KE server gives it a cookie for a different NTP
server, won't its time synchronization process revert to unsynchronized?

SM-D-10: Section 4.1.3 page 11, 3

SM:

The following error codes are defined:

In all these cases, what does the server do after it sends the Error
code?

SM-D-11: Section 4.1.5, page 12, 1

SM:

It is
empty if the server supports none of the algorithms offered.

If it is empty, what does the client do? retry with a new request?
(yadayada about whether the Section 4 intro page 8 means that can't be)
or declare failure and communicate with the NTP server without NTS protections? should the server send the TLS "Close notify" alert
after sending the empty algorithms list?

Relax requirements for unauthenticated extensions

On 8/23/16, Miroslav Lichvar <mlichvar at redhat.com> wrote:
> In 7.6 there is: "However, the client MUST discard any unauthenticated
> extensions and process the packet as though they were not present.".
> While this makes perfectly sense in the general case, it will be a
> problem when switches and routers are allowed to modify an extension
> field, which the client uses to correct the measured offset for
> queueing and processing delays in the switches and routers. I think
> clients should be allowed to (very carefully) process extension fields
> which by design can't be authenticated.

I'll add in an "unless provided otherwise by the specification for particular
extension fields" escape hatch. And if I'm paying attention when that
extension gets specified, I'll nitpick its security considerations section.
In your example, I'd insist that it includes guidance along the lines of
"if the round trip took 300ms and the switch claims it added 500ms of delay,
don't believe it!".

SM-G-4

SM:
Some of the text concerns the interactions with the NTS-KE server, some concerns the interactions with the NTP server. The word “server” is used throughout. There are cases where it is not clear which type of server is meant from context.

SM-D-3: Section 4, page 9

SM:

  unrecognized Record Type MUST ignore the record if the Critical
  Bit is 0 and MUST treat it as an error if the Critical Bit is 1.

If it is an error, what then? The server can reply with an Error record
type, if so, what would the code be? What would the client do?

SM-D-13: Section 4.1.6 page 13

SM:

Clients MUST NOT send records of this type.

What does the server do if the client does? Send an Error and if
so with what code?

Consolidate and expand privacy considerations

The document currently contains several oblique references to the privacy considerations surrounding cookies and how to prevent them from being used for tracking. Consolidate them all into a Privacy Considerations section and explicitly state the threat model.

SM-D-20: Section 5.7 page 21, 2

SM:

In
general, however, the server MUST discard any unauthenticated
extension fields

I am not sure what "In general, ... the server MUST" could mean,
but given that later text says

SM-G-10

SM:
In Section 6, the identifier “I” is used as a salt. RFC5869 says the salt is random. Should the text about choosing the “non-secret, unique” identifier mention random / unpredictable as well?