[ntpwg] Antwort: Re: Comments on various NTS drafts

[[e-mail]]

Thanks for comments. See replies inline.


Florian Weimer <[e-mail]> schrieb am 09.04.2015 13:34:43:

> Von: Florian Weimer <[e-mail]>
> An: [e-mail]
> Kopie: [e-mail]
> Datum: 09.04.2015 13:34
> Betreff: Re: [ntpwg] Comments on various NTS drafts
> 
> 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.

No, not the asymmetric keys but for example a random seed value, which 
will result in a key refreshment.

> 
> > 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.)
>
Time is already disseminated by the national laboratories by means of NTP. 
One of the intention of NTS is to secure this process. Yes, it is true 
that NIST is offering a secured NTP access. But this is done by means of 
the symmetric pre-shared key approach which is available since NTP version 
3. Also PTB is going to offer this service for a limited number of 
applications.  Therefore secure time dissemination of national 
laboratories is not out of scope of this section. But out of scope is the 
cryptographic protections of protocols like GPS, IRIG-B, etc. which are 
often used to provide time information to the national time servers. That 
is what section 3.2.10 is talking about.

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

Thanks for clarification.

> 
> -- 
> Florian Weimer / Red Hat Product Security

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