Re: [ntpwg] Comments on various NTS drafts

[Florian Weimer <[e-mail]>]

On 04/09/2015 12:12 PM, [e-mail] wrote:

> thanks for your comments and recommendations. We'll carefully look into 
> your comments. We already addressed some of your comments (see inline). 

Thanks.

> Regarding DTLS. Please keep in mind that DTLS requires a layer 3 
> communication. With PTP we also have to consider layer 2 communication 
> channels where DTLS is not applicable.

I think this is based on a misconception.  DTLS requires a datagram
transport, and it has its own fragmentation support, so it should be
perfectly possible to run it on top of a layer 2 transport which has
sufficient frame size (such as Ethernet).

Per-client server-side state would only need to be maintained during the
initial handshake, and not to answer subsequent time queries from
clients (but maintaining such state may be a performance optimization).

>> 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.
> 
> We don't see a problem with this requirement.

You do not periodically refresh asymmetric keys used for the initial
handshake.

> For clarification. Do you propose to abandon key refreshment at all?

Yes, the message rate is not sufficiently high that this would pose a
problem.  You just have to use cryptographic primitives which are not
known to be broken.

>> 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.
> 
> Please note, that 3.2.10 refers to the connection of reference time (such 
> as GPS, Radio transmitter, ...) to the PTP grandmaster or NTP stratum 1 
> server. These are basically non-IP or non-Ethernet connections and 
> therefore out of scope. 

I expect that rather soon, there will be a requirement to import time in
a secure way from one of the national time sources such as PTB or NIST.
 (NIST already offers an authenticated time service.)

I still haven't read the relevant regulation, though, and it's likely
still ambiguous in this regard.

>> * The integrity checks on the server_assoc response are unclear. It is
>> not specified if host name verification is performed. (D)
> 
> This should be ensured via CMS. But we will check this.

Host name checks are out of scope for CMS, so you have to specify
something on your own.

>> * 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)
> 
> We want to have certificates in order to have a mean to provide 
> authorization.

I think it would be best to make them optional.

>> * 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.
>
> Which MAC do you propose?

I'd have to do some research on this matter and will report back.  Not
all technical choices will be acceptable to the IETF.

>> * I have doubts about the use of TESLA.

> For us TESLA seems to be an appropriate approach. Do you know a good 
> alternative?

I'm afraid I do not.  (To be clear: If you do not have operational
experience with TESLA that says otherwise, I suspect it will not work in
practice.)

>> * 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.
> 
> Please describe the problem in more detail.

The existing guidelines for browser CAs discourage signing subscriber
certificates with strange extKeyUsage fields, see these requirements
documents: <https://cabforum.org/baseline-requirements-documents/>

>> # 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)
> 
> What exactly do you mean by cookie protection?

This is the lack of a Photuris cookie mentioned above.

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