[Dtls-iot] Secure Time (again)

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 07 August 2015 15:42 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A80FB1B2E48 for <dtls-iot@ietfa.amsl.com>; Fri, 7 Aug 2015 08:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bkCF3R5i5mPi for <dtls-iot@ietfa.amsl.com>; Fri, 7 Aug 2015 08:42:36 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83C81B2E5A for <dtls-iot@ietf.org>; Fri, 7 Aug 2015 08:42:15 -0700 (PDT)
Received: from [] ([]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MbOrg-1Z4yRe0sUe-00Iir6 for <dtls-iot@ietf.org>; Fri, 07 Aug 2015 17:42:14 +0200
Message-ID: <55C4D1CE.6010802@gmx.net>
Date: Fri, 07 Aug 2015 17:42:06 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: "dtls-iot@ietf.org" <dtls-iot@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lIt27JuBCETwU96XP3FFp3jwcBtHUCc9D"
X-Provags-ID: V03:K0:8S60pAkataGY0xHJE4Kxmtcd5XrASXmiY7+F9RrhKumBY5uVuZQ n1iyVYCBmOggeNEZmZTE0/HocDl6egOdu+VnPenqSHvEPVYjtrTcAZWEjGEybhkWlGliwOf q2eAT1/5SNn0dBfoye63nc/XvY29MU6jX5lUZsGPbXFzckc19amIfxyAbZhJtB4CpjXS0yH VXOcs998LbLfjcPlNZpeQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:apqdod3LMBM=:u5WN0UsVRlCD6gvC23TDNv O6CK8fEkerldngbgUsJT7h2MYrttcTo0UdKcdW3qniy5+9ITz4cfgCWF6Sqt0f4bmhPZNKfhx kqFa8XLTWi4hVgYa2v0J3vHiaS75wpk2ULP+H6D/UlMTVaQux9tY0rkFsub95Sz13hjiujJPH Nrz9lDiy55Kql03/I4ZQzLASaflKLvF61V1RTrDkuoR2Hc4XtShEvF1/IrtgBgrLpogdKUauF c4mv3Adj2DPMAHkg9MewDVJoZ32I03vwlDndbpRlIVK5imeunuSPvpvGWLSOSxzwFPXg0aBXy p4swSgi2T09UHHs6uIUD7oWhZJA6BjEGRfpX4e/90bCH46Th1CRSCUSaGnTQXpUxL686pPm3q Gj+II8o3oxWvVZAIq0QwjaoS94sjk5Cy7engdaKUytDvt/Z7M3jlpAhWTaBUAlNXgrKJfkL+M U4tMxkSTZfKi+eTtbu6Lfev8ImNQsmm9zNKCKjn9TfOZXha6alOXKcE3rnztUbWcngyVtqGTg FXkgbiXCVdjtlJ9lw2mLs22f2FalxsKp4014pyoPAKlxY8Hv/NanaEEyL6TcaiCJaUQ6/PGVg qquVKGsjhRrLR1zbr3T3UqLsFih5HC6zS6hUXP/90d2VTHt3ZFD8RXSN8Jf3EcWB6agdH1Fvf N2Lfb7hW3dDLewR8W72CAc8jTaLWC+E+STgxSX+ORcxkGZ+8Sq2+lsCYNCnJqjMFjpmX1O+/F 68emiVROk/Ww/Iww
Archived-At: <http://mailarchive.ietf.org/arch/msg/dtls-iot/hHxQvwoLUCDgW1oianMJYbNJDMI>
Subject: [Dtls-iot] Secure Time (again)
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2015 15:42:38 -0000

Hi all,

I wanted to come back to ticket #31 and #32 about secure time

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


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