[ntpwg] Antwort: Comments on various NTS drafts

[[e-mail]]

Hello Florian,
we added some mor questions to your initial comments.





ntpwg-bounces+dieter.sibold=[e-mail] schrieb am 02.04.2015 
11:52:16:

> Von: Florian Weimer <[e-mail]>
> An: [e-mail]
> Datum: 03.04.2015 06:03
> Betreff: [ntpwg] Comments on various NTS drafts
> Gesendet von: ntpwg-bounces+dieter.sibold=[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.

Do I understand it correctly that you're proposing something like:
* do the key exchange via dtls
* the server creates a random client cookie and calculates the client 
specific key from that (using a server secret as well) and sends both to 
the client
* the time sync packets would just send the rand in the request and the 
server can calculate the shared key for the response

> 
> # 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)

The client certificates can just be generated on the fly and don't have to 
be managed by the organization, i.e. they are self-signed. Actually, a 
random public key would be enough at this point, the cert is just there 
since it's easier to handle.


> 
> * 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)

Actually, that is on our To Do list.


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

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg