[Dtls-iot] Secure Time (again)

[Hannes Tschofenig <[e-mail]>]

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