Subject: [ntpwg] Comments on various NTS drafts

From: Florian Weimer <[email-masked]>
Date: Thu, 02 Apr 2015 11:52:16 +0200

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
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Richard Welty <[email-masked]>
Date: Sun, 05 Apr 2015 12:25:36 -0400

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

thanks for the comments. i will defer to others on the security
considerations; my role here is as an implementer. specifically,
i'm supposed to start on modifications to to the ntpd reference
implementation sometime in the next week or so with an eye towards
reporting massive progress (hopefully completion of the first
version) at the next IETF.

so i have concerns about these kinds of changes in the draft
as they will effectively prevent that effort from starting for
some time. speaking as the developer, i suspect that a DTLS based
version would be easier to write at the end of the day - but it
won't get finished per the current schedule because there is no
spec for it and wouldn't be for a while.

richard

---

From: Florian Weimer <[email-masked]>
Date: Tue, 07 Apr 2015 11:15:12 +0200

On 04/05/2015 06:25 PM, Richard Welty wrote:
> so i have concerns about these kinds of changes in the draft as
> they will effectively prevent that effort from starting for some
> time. speaking as the developer, i suspect that a DTLS based 

I can see that this is a problem.

Do you plan to use the CMS support in OpenSSL, or write it from
scratch (perhaps on top of the OpenSSL ASN.1/DER framework)?

Unfortunately, I don't know how controversial a switch to DTLS would
be.  The downside is that the per-client state the server has to keep
is more visible.  (The current proposal probably needs per-client
state in the form of kernel IP reassembly buffers, too, depending on
what kind of PKI is used.)

---

From: Richard Welty <[email-masked]>
Date: Tue, 07 Apr 2015 20:53:49 -0400

[for some reason, thunderbird sent this originally with wrong
from address; resending from the right one]

> scratch (perhaps on top of the OpenSSL ASN.1/DER framework)?

i was planning to use the support in OpenSSL. it is incompletely
documented, but the developers on openssl-dev are responsive
so that's ok.

richard

---

From: [email-masked]
Date: Fri, 10 Apr 2015 16:53:49 +0200

Thanks for comments. See replies inline.

Florian Weimer <[email-masked]> schrieb am 09.04.2015 13:34:43:

> Von: Florian Weimer <[email-masked]>
> An: [email-masked]
> Kopie: [email-masked]
> Datum: 09.04.2015 13:34
> Betreff: Re: [ntpwg] Comments on various NTS drafts
> 
> On 04/09/2015 12:12 PM, [email-masked] 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).
> 
> > 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.
> 
> > 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.
> 
> > 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.
> 
> > We want to have certificates in order to have a mean to provide 
> > authorization.
> 
> I think it would be best to make them optional.
> 
> > 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.
> 
> > 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.)
> 
> > 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/>
> 
> > What exactly do you mean by cookie protection?
> 
> This is the lack of a Photuris cookie mentioned above.#

Thanks for clarification.

---

From: [email-masked]
Date: Fri, 10 Apr 2015 16:11:39 +0200

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

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

> An: [email-masked]
> Datum: 03.04.2015 06:03
> Betreff: [ntpwg] Comments on various NTS drafts
> Gesendet von: ntpwg-bounces+dieter.sibold=[email-masked]
> 
> with a proper implementation of (D)TLS with ?(D)?.  With DTLS, the

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

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

> UDP fragmentation is fundamentally broken. (D)

Actually, that is on our To Do list.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 10 Apr 2015 16:32:24 +0200

> we added some mor questions to your initial comments.

Thanks.  Note that the NTP WG list at ntp.org appears to be down at the
moment.  I pinged Karen about this because the listmaster address
doesn't seem to work either.

> server can calculate the shared key for the response

Yes, that's the approach I recommend.  You'd have to design something
pretty much similar to DTLS anyway.

> since it's easier to handle.

Good point.  This is actually what happens behind the scenes in DTLS
with the ephemeral DH cipher suites (which are recommended these days
because they provide forward secrecy).

---

From: Florian Weimer <[email-masked]>
Date: Fri, 10 Apr 2015 17:01:13 +0200

> will result in a key refreshment.

I'm not sure if that's what is meant by key refresh.  Anyway, I think
periodic refresh is unnecessary with the moderate data rates used for
time synchronization.

> 3.

Yes, and I find this effort rather heroic.  I hope they will chime in
later, once the mailing list service is restored.

> Also PTB is going to offer this service for a limited number of 
> applications. 

Will it be publicly available, perhaps for a fee, or will access be
restricted to certain industries subject to regulation regarding the
synchronization of business clocks?

> Therefore secure time dissemination of national 
> laboratories is not out of scope of this section.

Good to know.

> But out of scope is the 

That wasn't immediately apparent to me.  Thanks for the clarification.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 09 Apr 2015 13:34:43 +0200

On 04/09/2015 12:12 PM, [email-masked] wrote:

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

Thanks.

> 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 

> What exactly do you mean by cookie protection?

This is the lack of a Photuris cookie mentioned above.

---

From: [email-masked]
Date: Tue, 14 Apr 2015 18:23:42 +0200

into 
inline). 

> sufficient frame size (such as Ethernet).

Okay, I didn't know this. Do you know if there are implementations 
available to use DTLS over Ethernet?

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 15 Apr 2015 08:11:24 +0200

>>> Florian Weimer <[email-masked]> schrieb am 10.04.2015 um 17:01 in Nachricht
> periodic refresh is unnecessary with the moderate data rates used for

Does it make a difference that the data transferred is mostly known?

Regards,
Ulrich

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Apr 2015 13:07:57 +0200

> Does it make a difference that the data transferred is mostly known?

There is a general belief within the IETF that you absolutely have to
change secrets regularly because every time you use them, you invariably
leak some information.  However, if the cryptographic primitive requires
rekeying for secure operation, it is generally quite broken and should
be replaced.

A good example is RC4.  You can thwart the known attacks by discarding
the first few hundred bytes of the stream, and re-key periodically after
a few dozen megabytes.  But that's a losing proposition: Over time, as
attacks get better, you'll have to discard more and more bytes at the
start (increasing setup costs) and rekey more often (making encryption
more expensive).  The initial discard also needs algorithm parameter
changes which are not negotiated by the protocol, so a new code point
and software updates are needed each time (it's also the reason why
there is no initial discard in TLS).

All this effort is a bit pointless if you can just use AES in counter
mode, or various of the other AES modes.

So in short, rekeying as a means to keep old implementations on life
support, without code changes, does not seem to work in practice, as we
have seen with RC4.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Apr 2015 13:14:46 +0200

> available to use DTLS over Ethernet?

According to Matt Caswell, one of the OpenSSL core developers, it should
be possible with OpenSSL and some custom BIO code:

  <http://marc.info/?l=openssl-users&m=142904263719101>

Figuring out the details will still require quite a bit of work, but it
will still be less effort than to reimplement large pieces of DTLS for
the security features you need.

---

From: [email-masked]
Date: Fri, 17 Apr 2015 10:23:33 +0200

"ntpwg" <ntpwg-bounces+kristof.teichel=[email-masked]> schrieb am 
15.04.2015 13:07:57:

> An: Ulrich Windl <[email-masked]>, 
[email-masked]
> Datum: 15.04.2015 13:09
> Betreff: Re: [ntpwg] Antw: Re: Antwort: Re: Comments on various NTS 
drafts
> Gesendet von: "ntpwg" 
<ntpwg-bounces+kristof.teichel=[email-masked]>
> >>> will result in a key refreshment.

Yes, the key that we explicitly wish to refresh periodically is the server 
seed, which is used for the generation of MAC keys (which therefore 
implicitly need to be refreshed as well after every seed refresh).

> rekeying for secure operation, it is generally quite broken and should

I am not sure how to understand your point. Are you saying it is 
unnecessary, or are you saying it would be detrimental to re-key and must 
be avoided? I have made myself familiar with the arguments for why 
re-keying should be unnecessary from a cryptographic point of view, but I 
still fail to see how it would be hurtful to include a possibility for 
re-keying (as opposed to being unable to re-key even after years of usage 
of a key).

> a few dozen megabytes. 

Side note: our thoughts were more along the lines of re-keying after a 
given period of time.

> But that's a losing proposition: Over time, as

Best regards,
Kristof Teichel

---

From: Florian Weimer <[email-masked]>
Date: Fri, 17 Apr 2015 16:02:01 +0200

> re-keying (as opposed to being unable to re-key even after years of usage 

It drives up complexity considerably.  The client needs to detect that a
rekeying has happened or is to happen soon.  Preferably, this
notification should be itself cryptographically secured, and this is a
bit tricky because you want to get rid of the key.

On the other hand, the same logic is needed to implement server restart
(which potentially discards the secret used for the cookie -> HMAC key
mapping).  But server restart should be a rare event, so this case does
not have to be handled as reliably.

> Side note: our thoughts were more along the lines of re-keying after a 

The only reason I can see for that is to implement revoking the service
(i.e., client authenticates, but policy changes in some way, and it
would no longer be welcome).