Subject: Re: [saag] NTP security, and thoughts on Hawaii

From: Peter Gutmann <[email-masked]>
Date: Mon, 3 Nov 2014 18:06:34 +0000

Eliot Lear <[email-masked]> writes:

>In particular it requires access to the sky, which in any number of cases is
>not possible.  Perhaps that's beyond the general case, but worth thinking
>about.

It actually requires a lot less access to the sky than that, you don't need a
3D or even 2D lock, just a single satellite will do.  I run my GPS-based NTP
server in a room under a metal roof and it has no problems getting a time-
source lock (although I've never had a 3D lock, and 2D is quite intermittent).
As long as you can get a ceramic patch antenna somewhere near a window you
should be fine.

(Even if your servers are located in, say, an underground bunker, there's no
reason why your NTP server also needs to be there.  Or if you're that worried,
buy a rubidium clock-based one and run your own time reference).

Peter.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Nov 2014 10:09:06 -0800

On 11/3/14, 10:06 AM, Peter Gutmann wrote:
> 3D or even 2D lock, just a single satellite will do.

I understand.  Even that access is not always available in a number of
environments.  In the cases I'm aware of, there is at least one wire out
to an antenna from a strat1 clock.  But you can't expect hundreds of
devices to do that...

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 3 Nov 2014 13:09:19 -0500

I want one of these:
    http://www.npr.org/2014/11/03/361069820/new-clock-may-end-time-as-we-know-it

Move it 1 inch and it reacts to the relativistic effects 
--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Nov 2014 15:02:22 -0500

Peter Gutmann <[email-masked]> wrote:
    > It actually requires a lot less access to the sky than that, you don't
    > need a 3D or even 2D lock, just a single satellite will do.  I run my
    > GPS-based NTP

From my office desk, I can't get any of the USB based GPS receivers to work:
     The windows have the reflective EM coating, and seem to reflect it all.
     I think we have 3G now only because there is a tower literally outside
     the windows at UQO.

    > (Even if your servers are located in, say, an underground bunker,
    > there's no reason why your NTP server also needs to be there.  Or if
    > you're that worried, buy a rubidium clock-based one and run your own
    > time reference).

We tried taping pasting the USB device to the window :-)

{In this case, I was testing the devices for installation at sbrac.org,
where we have no network at all...  while we have a 18M dish up there,
the inside of the turret turns out to also be a really good faraday cage.}

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 7 Nov 2014 14:00:39 -0500

There are really two separate time problems:

1) Accurate time synchronization for lab work, database sync, transactions, etc.
2) Current time to bound replay attacks, stale PKI data etc. for security

The first requires a very high degree of accuracy, frequently to 100ms
or better. If I have more than one clock in a room with a second hand
then I want them all to march in time.

The second requires a high degree of trust but not a high degree of
accuracy. The WebPKI as deployed has to tolerate clock skews of hours.
It would be good if we could reduce the skew to a minute but we don't
need to worry about seconds in a general purpose protocol. If we need
tighter synchronization then we should be using a different approach.

This has important consequences for the secure time protocol design.
It is not a case of slapping security onto NTP. NTP is designed to
solve the lab time problem, not provide a trustworthy input to a
security infrastructure.

It is easy to write a passive protocol that provides proof that we are
past a certain time. NIST and its Iranian cousin both sign time at 60
second intervals. We collect the time from both and can be pretty sure
that the earliest time cited by either has passed.

If we have a TRANS like notary infrastructure, we can obtain a proof
that a certain time has elapsed. We choose a random value, create an
entry in a notary log and then wait to collect the signed
registration. If all the notaries are interconnected, defection
requires defection of a quorum.

I see TRANS and DPRIVE as opening up an opportunity to address this
problem. The folk who want DNS Privacy and the folk who care about
trustworthy time are mostly the same people.

One of the core requirements for DNS Privacy is that you have to
decide to take your DNS service from a trusted source (or sources)
rather than accept service from random providers you don't know. Which
means that you will need a mechanism for authenticating their
responses.

Having worked on that problem for 4 years now, I know that 95% of the
DNS privacy problem is in working out how you connect to the service
and manage that trust relationship. The actual encryption part is a
trivial bit of packaging and the only thing to make sure about is that
the encrypt/MAC get done in the right order.

Since a DNS resolver service is trusted, why not allow the same
provider to provide trusted time as well?

t would be a separate protocol/service of course. But it should fit
into the same framework so that instead of having to configure
separately for each trusted service it should be possible to plug a
device into one trust provider and not have to configure each service
separately unless you had a reason to.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Nov 2014 18:48:33 -0500

> separately unless you had a reason to.

Well, DNSSEC RRSIG has a signature inception date.  If a DPRIVE provider
simply signs a RR every minute or hour, and you have a pre-existing trust
path to that RR, then doesn't that solve the problem?

And pseudo-randomly/regularly asking for the RR over the private channel,
doesn't that naturally provide for some defeat of traffic analysis for
the DPRIVE?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 7 Nov 2014 21:37:52 -0500

> path to that RR, then doesn't that solve the problem?

If the client has a prenegotiated shared secret with the resolution
service, the client can ask the service what the time is and get an
encrypted/authenticated response.

It doesn't need to be signed. Can just use a MAC with a shared secret
and a protocol with a very simple signature:

Transaction GetTime GetTimeRequest GetTimeResponse
Message GetTimeRequest
Message GetTimeResponse
    DateTime Now

My preference would be to do a completely separate protocol. But we
could easily add in a pseudo RR for it. Could even use a DNS class for
Time!

Signed time doesn't really do much for security I can see. Time
attacks are almost always winding time back into the past. Singing
time tells me that the time I am given has definitely passed but not
that that I was given the current time. So it doesn't help with a post
dating attack anyway unless I get it from a trusted source.

> doesn't that naturally provide for some defeat of traffic analysis for

Might help. But I would rather hide in a larger quantity of natural
traffic like VOIP or whatever.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 09 Nov 2014 07:53:43 -1000

> Transaction GetTime GetTimeRequest GetTimeResponse

Without a nonce, isn't this vulnerable to replay attacks?  If i ever see
you request the time (and see your server's response) at time T, i
shouldn't be allowed to wind time back to T for you just because i
control the network.

        --dkg

---

From: Watson Ladd <[email-masked]>
Date: Sun, 9 Nov 2014 11:01:07 -0800

> shouldn't be allowed to wind time back to T for you just because i

All motherboards contain a RTC. There is a standard, host-based,
security measure for NTP that prevents running the clock backwards.
This measure is not used. Yes, it really is as simple as removing an
argument from a boot script.

Sincerely,
Watson Ladd

>
>         --dkg
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Nov 2014 09:58:56 +0000

Watson Ladd <[email-masked]> wrote:
>
> All motherboards contain a RTC.

You should look at the Raspberry Pi or some Internet of Things devices.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth, Biscay: Southwesterly 4 or 5, backing southeasterly 6 to
gale 8, perhaps severe gale 9 later in Plymouth, then becoming variable 4
later in Plymouth and northwest Biscay. Rough or very rough, but moderate at
first in Portland. Rain or thundery showers. Moderate or good, occasionally
poor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Nov 2014 10:56:35 -0500

> shouldn't be allowed to wind time back to T for you just because i

Sorry, yes you do need a nonce, and that gets added in automatically
in my presentation layer. Forgot to mention it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Nov 2014 10:59:46 -0500

> argument from a boot script.

No, they don't.

Where is the real time clock on an Arduino? How about a Smothieboard
or a TinyG? And those are quite high spec boards costing over $50.
Raspberry Pis don't have an RTC either.

The last is pretty important given that Raspberry Pi is a likely
candidate for any security involving disposable one time use machines.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 10 Nov 2014 08:13:49 -0800

>> argument from a boot script.

The vulnerable machines include laptops and desktops which do have an
RTC. We can't even solve the easy problem.

Embedded devices will need a secure time protocol that works. But if
you don't understand why Autokey doesn't work, you'll make proposals
that don't work either. Anyone can join pool.ntp.org: you cannot have
a single key for all pool.ntp.org servers.

Saying we should use ISP provided servers leaves out the question of
finding those servers. It's trivial to design a protocol that can work
through NAT. It's not trivial to make one suitable for the current
situation, where almost everyone uses a pool of servers anyone can
join for the correct time because this avoids all sorts of discovery
and longevity problems.

Sincerely,
Watson Ladd

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Nov 2014 10:41:43 -0600

I agree: stepping the RTC backwards should never be taken lightly
(prompt the user if you can; do not step back if you can't prompt).
For devices without an RTC but with stable storage, they should
periodically write the last known time and never step backwards over
it.  But of course, without an RTC there's no real good way to prevent
stepping backwards if the device was powered off for a long time
coincident with a compromise of time distribution keys (or the trust
infrastructure for them).

For the internet of things it might be nice if homes could have a
local trusted time source, but that involves joining those devices to
a home network, so that's a no-go.

Perhaps we should be reaching this conclusion: the time infrastructure
is as critical as a PKI's roots.

Nico
--

---

From: Erik Nygren <[email-masked]>
Date: Mon, 10 Nov 2014 07:58:39 -1000

While there may be no solution for devices powered off for a long time
with neither RTC nor long-term storage, we should explore leveraging
existing PKI roots to ensure monotonic coarse-grained time.
For example, if some intermediary of the PKI roots and DNSSEC TLD roots
periodically signed "current time" and made it available somewhere,
clients could fetch some number of these and update a time floor
(minimum allowable time) if over some number of trusted roots agreed.
This time floor could be stored in local storage.  Fine-grained
synchronization
could still use less trusted NTP as long as it couldn't go below the floor.
If the signed current time is updated daily or every few days, this could
at least help with the sort of time roll-back attacks that started this
thread
(although by itself might not help against replay attacks with shorter time
bounds).

Threat-wise, we also need to protect against accidents or attacks that might
trick clients into thinking that the time floor is in the future as that
might
be very hard to recover from.  As such, clients would presumably not want
to rely on a single trust root for advancing this.

    Erik

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Nov 2014 12:09:50 -0600

Another point is that devices with no writable stable storage cannot
receive updates, not even of trust anchors in the event of PKI root
compromises.  Such devices had better have trivial roles with no
significant security considerations!

For devices with significant security considerations we should expect
at least a modicum of writable stable storage for things like "last
known time" and trust anchors.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Nov 2014 12:12:02 -0600

On Mon, Nov 10, 2014 at 11:58 AM, Erik Nygren <[email-masked]> wrote:
> [...]

This strikes me as a good idea.  Attacks involving moving the time
into the far future are always going to be a problem on RTC-less
devices, and that means that a UI will be needed (even if it's just a
hard reset button).

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: Mon, 10 Nov 2014 15:17:30 -0500

Watson,

> argument from a boot script.

You're thinking too big.  Perhaps all x86_64-level motherboards contain
an RTC.  But not all *systems* contain an RTC, and they most definitely
don't always have a battery to maintain it across reboots.  You don't
even have to get very small to get into this level of system; many ARM
SoC systems fall into this category.  Moreover, once you get into even
smaller systems you're more likely to hit this situation.

For example, when my Wandboard (ARM SoC running Linux) boots up it comes
up at January 1, 1970, until it contacts the network and obtains a time
(usually about 10-30 seconds after power-up).

So it behooves us to have a way to securely obtain a current time
reference, because these levels are systems are the major growing
category.

> Watson Ladd

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Derek Atkins <[email-masked]>
Date: Mon, 10 Nov 2014 15:21:12 -0500

> (prompt the user if you can; do not step back if you can't prompt).

So you've never had a system whose clock ran fast?

-derek

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Nov 2014 14:27:50 -0600

> So you've never had a system whose clock ran fast?

I have.

There needs to be some tolerance (what Kerberos calls max skew).
Beyond that tolerance you need user input.  If an RTC runs way too
fast then the user can change the tolerance on that system, or else
return the busted system and get a new one.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 10 Nov 2014 21:35:24 -0500 (EST)

> is as critical as a PKI's roots.

I don't know if I'm confident enough to say "as critical as", but it does
seem pretty critical.

CT is all about signed timestamps; lots of things can go wonky if the
different actors have different ideas of the current time.  (Corrupting
a log server's idea of the current time will probably render that log
useless!)

If I remember correctly, Chrome brands a build timestamp into official
builds and disables certain behavior if that time is too far from the
current time.

I'm sure there are other places.

-Ben

---

From: Watson Ladd <[email-masked]>
Date: Mon, 10 Nov 2014 19:48:17 -0800

> reference, because these levels are systems are the major growing

You would think this is why NTP security exists. And indeed there is a
protocol claiming to secure NTP.

But that protocol doesn't work for many uses. And a revision is being
proposed that still doesn't work.

It's not really a SAAG issue, but an NTP issue. The SAAG issue I want to
talk about is structural:

Why do drafts go through the process when they don't solve the problem they
are supposed to solve? Why do we see changes to protocols made for "extra
security" not coupled with effective action to remove the old insecure
versions? Why do we see old attacks get new life again and again?

If you want to make usable, secure, cryptography, the IETF is not the
place. No one sees any benefit to making OTR into an RFC, or the recent
work on asynchronous forward secure messaging. We're not getting
interoperable standards which we need if we want to encrypt every packet.
Instead we're excited by authenticating public keys with RSA-1024, and the
real work happens elsewhere, and doesn't become ubiquitous.

Sincerely,
Watson Ladd

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Nov 2014 11:47:58 +0000

Erik Nygren <[email-masked]> wrote:

> existing PKI roots to ensure monotonic coarse-grained time. For example,
> if some intermediary of the PKI roots and DNSSEC TLD roots periodically
> signed "current time" and made it available somewhere, clients could
> fetch some number of these and update a time floor (minimum allowable
> time) if over some number of trusted roots agreed.

You could perhaps get this information from the RRSIG records on TLD
zones. They aren't great for this purpose since a lot of them have a 24h
TTL, but you could plausibly use the maximum inception time from several
RRSIGs, possibly after discarding outliers. (And note that most of the
TLDs set their inception time to an hour in the past to allow for some
clock skew.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Rockall, Malin, Hebrides, Bailey: Easterly or southeasterly 5 to 7,
occasionally gale 8. Rough or very rough. Rain or showers. Good, occasionally
moderate.

---

From: Derek Atkins <[email-masked]>
Date: Tue, 11 Nov 2014 18:24:49 -0500

Watson Ladd <[email-masked]> writes:

> You would think this is why NTP security exists. And indeed there is a protocol
> claiming to secure NTP.
>
> But that protocol doesn't work for many uses. And a revision is being proposed
> that still doesn't work.

It doesn't work in the general case.  It could certanly work in many
cases.  For example, I *do* run a couple NTP servers on my home network,
so I *could* set up secure NTP to my devices that need it.

> It's not really a SAAG issue, but an NTP issue. The SAAG issue I want to talk
> about is structural:
>
> Why do drafts go through the process when they don't solve the problem they are
> supposed to solve? Why do we see changes to protocols made for "extra security"
> not coupled with effective action to remove the old insecure versions? Why do
> we see old attacks get new life again and again?

Well, this is a loaded question.  What problem was it *supposed* to
solve?  The problem we're talking about here, secure loose time
coordination (e.g. +/- 5s coordination) is definitely NOT the problem
that the SNTP group took on.

You could ask the question "why didn't they take it on", but that's not
a SAAG question, that's a question for the relevant WG and possibly the
IESG.

You could ask the question "why hasn't anyone taken this on", and that
would also not be a SAAG question but one again directed at the IESG.

-derek

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Nov 2014 18:22:48 -0600

On Tue, Nov 11, 2014 at 5:24 PM, Derek Atkins <[email-masked]> wrote:
>> [...]?

Another fair question would be "should we take this on?", but that
might require actually making a stab at a specification, a BoF, an
implementation.  It'd be nicer if we could nudge the NTP WG to take it
on.

Nico
--