Subject: [Dtls-iot] Secure Time (again)

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 07 Aug 2015 17:42:06 +0200

Hi all,

I wanted to come back to ticket #31 and #32 about secure time
http://trac.tools.ietf.org/wg/dice/trac/ticket/31
http://trac.tools.ietf.org/wg/dice/trac/ticket/32

Most IoT devices have no real-time clock and even if they have one it
needs to be set at some point in time.

Many security protocols, including DTLS/TLS rely on synchronized clocks.
To check whether a certificate used during the TLS exchange is valid the
expiry time needs to be verified. Other protocols also require
synchronized clocks. For example, a protocol that uses tokens
that contain an expiry time will require some form of synchronized clocks.

It turns out that TLS has a way to communicate time information from the
server to the client as part of the ServerHello message. Of course, it
is not a good idea to trust every server when they return time
information since this allows an adversary to trick the client into
accepting an expired certificate.

It is, however, quite likely that an IoT device will be equipped with
credentials that do not expire (for example those credentials
provisioned during manufacturing) and those will only be used with
dedicated entities, such as authorization / key distribution servers.

Getting time information from those special servers without using yet
another protocol (such as NTP) is obviously desired.

Note that this is not a new idea. I have copied the relevant text from
RFC 4120 (Kerberos) to the end of this mail.

In a previous exchange Carsten (see
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00633.html)
argued that the DTLS/TLS IoT profiles draft is a good place to write
text about this functionality based on text in the TLS specification.

The first question that arises whether we should use a time
synchronization mechanism within TLS / DTLS or deal with this issue
at an application layer protocol.

If we define the functionality in TLS / DTLS we need to be aware of the
recent decision by the TLS working group to remove the unix_time
functionality from the ServerHello message. While this is not a problem
for TLS / DTLS 1.2 it might be a problem in the future.

So, what is your preference?

Ciao
Hannes

----------- Kerberos Time Synchronization Mechanism -----------------

"
Upon validation of the KRB_AS_REP message (by checking the returned
nonce against that sent in the KRB_AS_REQ message), the client knows
that the current time on the KDC is that read from the authtime field
of the encrypted part of the reply. The client can optionally use
this value for clock synchronization in subsequent messages by
recording with the ticket the difference (offset) between the
authtime value and the local clock. This offset can then be used by
the same user to adjust the time read from the system clock when
generating messages [DGT96].

This technique MUST be used when adjusting for clock skew instead of
directly changing the system clock, because the KDC reply is only
authenticated to the user whose secret key was used, but not to the
system or workstation. If the clock were adjusted, an attacker
colluding with a user logging into a workstation could agree on a
password, resulting in a KDC reply that would be correctly validated
even though it did not originate from a KDC trusted by the
workstation.
"

---

From: Michael StJohns <[email-masked]>
Date: Sun, 9 Aug 2015 14:23:12 -0400

> accepting an expired certificate.

I think this has been deprecated and removed for TLS1.3?

Mike

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Aug 2015 12:34:28 +0200

Hi Mike,

yes, there have been discussions about removing this server-provided
time information in TLS 1.3.

Although the current profiles focus on TLS 1.2 this might cause some
problems in the future.

Ciao
Hannes

On 08/09/2015 08:23 PM, Michael StJohns wrote:
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Aug 2015 08:33:40 -0500

> time information in TLS 1.3.

This is already done.

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Aug 2015 16:28:34 +0200

Thanks, Ekr.

> This is already done.

While I understand the reason for removing the functionality from the
ServerHello I still think it is a needed functionality for many IoT
deployments to obtain time information (without having to fall back to NTP).

---

From: Michael StJohns <[email-masked]>
Date: Tue, 11 Aug 2015 10:35:35 -0400

> deployments to obtain time information (without having to fall back to NTP).

Yup - but not all IOT devices will do DTLS or TLS.  And time in DTLS or 
TLS isn't "secure".

I think for this version, you should assume that DTLS and TLS will not 
be a source of time and write accordingly.

Mike

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Aug 2015 16:40:16 +0200

> be a source of time and write accordingly.

That's fair!

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 11 Aug 2015 16:44:44 +0200

> be a source of time and write accordingly.

If falling back to NTP means additional traffic (which I strongly 
suspect) this is not a god thing in the IoT world. The attraction of 
using DTLS/TLS is that you can piggyback the information in the 
handshake (that you have to do anyways).

So is there an alternative? Could we use RFC4680?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Aug 2015 16:46:03 +0200

A possible alternative is to do it like the Kerberos folks did it,
namely by adding it to the key distribution mechanism (which would then
be ACE).

---

From: Michael StJohns <[email-masked]>
Date: Tue, 11 Aug 2015 10:58:27 -0400

> namely by adding it to the key distribution mechanism (which would then

TANSTAFFL - there ain't no such thing as a free lunch.

I don't believe that "secure" time is possible without persistent time 
and that's difficult to do for cheap battery operated IOT nodes (or so 
I've been told).  The best you can do is generally "tell me N times" 
similar to NTP and hope you're part of the mesh hasn't been captured by 
bad data.

There's also the tradeoff between precision and accuracy that needs to 
be considered.  IOT nodes with cheap clock circuitry will drift. If you 
want millisecond precision and 1 part per billion accuracy you're going 
to be disappointed (note that I didn't do the math - I may have meant 
1PPTrillion or 1PPMillion).

Then there's the whole latency thing - you might get a signed time 
object from Kerberos, but that object may have been sent a week ago.  If 
you have no persistent time and you're just coming up..... welcome to 
last week.

I think any system on the mesh is going to require something like NTPs 
tell me N times to work.  I don't think that NTP is a drop in fix though.

Time is not a simple thing.  Secure time is frankly arcane and not meant 
for mere mortals to delve into.  :-)

I'm wondering if it might not be a bad idea to invite Dave Mills to come 
to an IETF to do a presentation on secure mesh time and give us his 
thoughts.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Aug 2015 16:31:08 +0100

> to an IETF to do a presentation on secure mesh time and give us his

We could and that'd be a really useful great talk if it happened. But
we also have an active WG on this topic. [1] Maybe starting by asking
there would help?

S.

[1] https://tools.ietf.org/wg/tictoc/

---

From: Michael StJohns <[email-masked]>
Date: Tue, 11 Aug 2015 14:31:01 -0400

> [1] https://tools.ietf.org/wg/tictoc/

Hi Stephen -

 From the tictoc charter:
> The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is
>      concerned with highly accurate time and frequency distribution over
>      native IP and MPLS-enabled IP Packet Switched Networks (PSNs)

I knew about the group, but I didn't think it was a great fit for IOT 
stuff for a lot of reasons including their desire for "highly accurate 
time" against the IOT desire for lightweight.   As I read the charter, 
tictoc is NTP on steroids and what we want is NTP on depressants.  :-)  
They really aren't trying to solve a problem in a manner that would have 
applicability to IOT.

Mike

---

From: [email-masked]
Date: Tue, 11 Aug 2015 19:00:34 +0000

> They really aren't trying to solve a problem in a manner that would have 

Sure. All I meant by 'asking' was, well, asking:-) I fully agree that were work in the IETF on this topic needed we'd have to figure out how/where to best do that but the folks on that list would I guess be better informed (than me anyway:-)

S.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 11 Aug 2015 15:21:18 -0400

> Sure. All I meant by 'asking' was, well, asking:-) I fully agree that were work in the IETF on this topic needed we'd have to figure out how/where to best do that but the folks on that list would I…

Maybe  -but a quick look of WG documents suggests that the science (and 
a lot of the engineering) for this has already been done in the IEEE 
1588  (Precision Time Protocol) group and that what's happening in the 
IETF is only the plumbing to make it work over/with IP.

I guess what I'm saying is that I don't actually know what I'd ask them 
that would be in their wheelhouse and that I couldn't get a better 
answer from Google or Dave Mills or maybe one of his (ex?) grad students.

No worries - I may drop Karen O a note to chat about this.

Mike

---

From: Derek Atkins <[email-masked]>
Date: Wed, 12 Aug 2015 11:17:12 -0400

Michael StJohns <[email-masked]> writes:

> They really aren't trying to solve a problem in a manner that would
> have applicability to IOT.

I actually attended a tictoc meeting a couple IETFs ago and presented
the IoT time sync problem to them.  They were unaware of the issue and
considered it an interesting problem to try to solve.

We should continue to engage them!

> Mike

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

---

From: Michael StJohns <[email-masked]>
Date: Wed, 12 Aug 2015 11:55:07 -0400

> We should continue to engage them!

Charter creep is usually a bad thing.    I'm not saying not to do it, 
but it might actually be better to go to NTP (which Karen also chairs) 
and which is probably a better stepping off point than the IEEE PTP that 
Tictoc is working on.  It's probably that NTPv4 could incorporate IoT 
functionality better than Tictoc.

And for nothing else than a cool acronym, standing up an IOT integration 
working group  (e.g. to have a place to talk about all the pieces and 
how they can come together) might be even a better choice -> Interim 
Designs for the Internet of Things -> idiot.

Later, Mike

---

From: Derek Atkins <[email-masked]>
Date: Thu, 13 Aug 2015 09:36:22 -0400

Michael StJohns <[email-masked]> writes:

> and which is probably a better stepping off point than the IEEE PTP
> that Tictoc is working on.  It's probably that NTPv4 could incorporate
> IoT functionality better than Tictoc.
>
> And for nothing else than a cool acronym, standing up an IOT
> integration working group  (e.g. to have a place to talk about all the
> pieces and how they can come together) might be even a better choice
> -> Interim Designs for the Internet of Things -> idiot.

All I did was attend the meeting and state the "need secure time at boot
time" problem with many IoT devices.  I didn't ask for a charter change,
just for them to think about the problem.  I figured that the tictoc
group probably had the most "time protocol" experts in the IETF.

Unsurprisingly they were completely unaware of this issue and were quite
intrigued by the problem.  Whether or not they work on it, I can't say.
I didn't follow up.

-derek

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Aug 2015 17:57:39 +0200

> Designs for the Internet of Things -> idiot.

That acronym is taken -- it stood for "Improving DTLS for the Internet
of Things" -- the WG that then surprisingly became DICE (i.e., the WG
behind this mailing list).

On a more serious note, if you want to have a discourse about IoT
protocol integration issues, T2TRG may be the right place to talk about
this (before we come up with some specific topics for standardization).

https://www.ietf.org/mailman/listinfo/t2trg

Grüße, Carsten