[ntpwg] Comments on various NTS drafts

[Florian Weimer <[e-mail]>]

Here are a few comments on those drafts.  I hope they are useful.

I strongly recommend reusing (D)TLS instead of implementing your own
cryptographic protocol.  I have marked the issues which would go away
with a proper implementation of (D)TLS with “(D)”.  With DTLS, the
server could just send the client cookie and the HMAC key, disregarding
the client certificate.

# RFC 7384 compliance

First of all, the proposed protocol fails to implement the requirements
of RFC 7384.  This is mostly due to the fact that several of its
requirements are *impossible* to implement:

Section 5.1.2 is likely bogus because it is not implementable in
practice (end-to-end security makes intermediate clocks obsolete).

Section 5.6.1 requires frequent key refresh. This is impossible to
implement in practice (ultimate keys cannot be refreshed without
operator intervention), and not necessary as long as sufficiently strong
cryptographic primitives (non-broken algorithms) are used.

Section 5.9 is impossible to implement. There is no protection against
DoS from MITM attacks. Protection against low-rate message spoofing
without knowledge of the keys seems reasonable, though.

In addition, RFC 7384, Section 3.2.10 indicates that securing the time
source of an entire organization from an external source is out of
scope. However, this is likely the most common application of a security
time protocol.

# draft-ietf-ntp-network-time-security-08

* The client host name in the client_assoc is an unnecessary information
leak.

* The client_assoc message needs a mechanism to select the server
certificate. This is desirable for metrics and required for server key
rollover without locking out the existing clients. Without this
mechanism, it is necessary to use multiple IP addresses. (D) via SNI.

* The integrity checks on the server_assoc response are unclear. It is
not specified if host name verification is performed. (D)

* In a trivial UDP-based implementation, the server_assoc response is
computed before two-way communication with the client IP address has
been proven, resulting in a denial of service vulnerability (CPU
overload due to signature computation for spoofed clients, traffic
amplification due to larger server response). This also affects the
server_cook message generation. Photuris cookies would address this. (D)

* The server_cook message uses non-hybrid asymmetric encryption. With
ECC, this does not work because the provided payload space is not large
enough. The usual hybrid scheme should be used instead. This means that
an additional cryptographic primitive has to be negotiated. (D)

* Client certificate management is a red flag for many organizations. It
would be better if the protocol would not use a client certificate at
all, and some other key agreement scheme (e.g., application key
extraction with TLS/DTLS, without client certificates, or a TLS response
containing an encrypted session key). (D)

* With a server without per-client state, the HMAC key setup has to be
performed on each response.  This is quite costly.  A different MAC
could be quite a bit cheaper in terms of CPU overhead.

* I have doubts about the use of TESLA.

  . Is there sufficient operational experience with this protocol?

  . It is never stated explicitly, but reading the protocol
descriptions, it is expected that TESLA is secure against malicious
recipients.

  . TESLA uses a race condition for security, which seems inherently risky.

  . The use of time for security purposes interacts in a complex way
with using TESLA for time synchronization.

# draft-ietf-ntp-cms-for-nts-message-02

* DER is used even for fast-path time synchronization messages (not just
for the handshake).  This seems unnecessary.

* Requiring a new OID in the Extended Key Usages attribute of
certificates (section 4) means that the browser PKI cannot be used to
authenticate hosts. This seems quite wrong.

* Not all CMS algorithm parameters are negotiated at the NTS layer, as
suspected. (D)

# draft-ietf-ntp-using-nts-for-ntp-00

* There is no cookie protection of server_assoc/server_cook responses,
as explained above. This is quite bad. (D)

* The proposed protocol does not address UDP message size limitations.
UDP fragmentation is fundamentally broken. (D)

-- 
Florian Weimer / Red Hat Product Security
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg