Re: [Ace] New Version Notification for draft-navas-ace-secure-time-synchronization-00.txt

Renzo Navas <> Wed, 02 November 2016 10:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A780C129564 for <>; Wed, 2 Nov 2016 03:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9XAc-kgVpBnS for <>; Wed, 2 Nov 2016 03:48:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5ED0F129AB8 for <>; Wed, 2 Nov 2016 03:48:29 -0700 (PDT)
Received: by with SMTP id x190so11063410qkb.0 for <>; Wed, 02 Nov 2016 03:48:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ziVgKt33CnEgHw8YC3S9vLPPDvEVEDaY979llc4aEG0=; b=T1qhRI/p6DXSF8stPVus7hMzgJzvjL9DVplNPA2fZ/txGRDgDIddH4D2YGDW15aqsV dj13IPhMAZcXS844fBWz2p0UzrWFPYsEyePPOS06sLU6b8MNYXbTNU0RjPw54Qjs38dP VlZqoOB83uhAb5bz8pKvOMolaGQvJ8O0YSs6L0q8CeWG4Q0FocUhl4nE+v/fIA9Ar01a 0BDVg81XscWJM9qcMnTR1/lMAbUTJ9swDCrFxTDqVyeFpqaSu5fB3onZXGkJp7wyLwad Pa2UEp9Sba62Moe87HtNZsC2UapPLWJLbyzRL8OT+JnSrMELejUPdYH6BKt/lkamssnS pifw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ziVgKt33CnEgHw8YC3S9vLPPDvEVEDaY979llc4aEG0=; b=LpukEvbHn7L+D3nw3/Vv3oBqW4yAv3NlmKNjvM5T56TXXNr+0rmicAC3p1GrEpnQxc 7run96xb/lxdVfZycIPKmYXr8NJFxYvCmASJJMWArqdr2zf3svWQlaMOCKwW2Ia7EcEs noh7M+c7sK/Tou6JjVCVzC0igDXGX99b77/QhUiHfAIe3VWULVb5HTB1lsRJH/8VAbUb L5Yx2PxtPGLk2m/0dI/6GgHdREMWtB3sTxj3taoK75WluJ2Zq6lXY6JRv+tscu4JjcNw G+ELHpI8ndbK5eaIpo3VQ67mI8czbW4QJnBCae1lD5b1c+ObJXLvutJbnoNJIb6tXX2K aykQ==
X-Gm-Message-State: ABUngvfZY8TxB+3GjWNtd6zxLrrFBJQFpx55fzg5AHVxO/yrod3qOKCSdle47rR09Wo6ZQkKfrjpvyQOQmVqgQ==
X-Received: by with SMTP id j130mr2373495qke.108.1478083708425; Wed, 02 Nov 2016 03:48:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 2 Nov 2016 03:48:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Renzo Navas <>
Date: Wed, 02 Nov 2016 11:48:08 +0100
Message-ID: <>
To: Randy Presuhn <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: ace <>
Subject: Re: [Ace] New Version Notification for draft-navas-ace-secure-time-synchronization-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Nov 2016 10:48:32 -0000

Hi Randy!

Thank you for the pointer, I was not aware of rfc3414.

I am in favor of solutions that do not need a time
protocol/synchronized time; I think we will need both at ACE.
Freshness is what seems to provide the 'Timeliness Module' of rfc3414
(but then I think the module to work needs some sort of  "Time
Synchronization" sec 2.3. which I could not figure out in detail). In
any case I will deep digger on the document.

About the need for time: Internal ACE discussions (clock design team),
that now I hope well be debated publicly, lead to some partial
conclusions; and I think one of them is that a minimal time-sync will
be needed in ACE.
The protocol we are designing, consist on two messages (fundamentally:
two object structures), that where designed to be easily
attached/piggybacked with other messages of the ACE framework. I can
no think about something more minimalistic, other than not using self
containing structures, and using something more compact than
Also I think its good to separate the debate about the  actual time
sync procedure (nonce, what to authenticate, etc), and  the second
issue is how to encode and send those messages within the ACE

I think its an open discussion, so Its good that we are talking about
Time in ACE.

Eager to continue the time-discussion, but now I don' have more time :P


PS: One thing that must be clarified on future versions of draft is
that we will be too pretentious to call a "full-blown" time protocol
our proposal, certainly time precision/accuracy is not one of the

On Tue, Nov 1, 2016 at 7:10 PM, Randy Presuhn
<> wrote:
> Hi -
> On 10/31/2016 11:45 PM, Ludwig Seitz wrote:
>> On 2016-11-01 01:41, Randy Presuhn wrote:
>>> Hi -
>>> On 10/31/2016 7:25 AM, Renzo Navas wrote:
>>> ...
>>>> The need for a secure source of time is getting clearer on ACE (either
>>>> that, or mechanisms to assure freshness of each transaction), and we
>>>> hope that with this protocol we are giving the first step to come up
>>>> with a constrained-resource friendly solution.
>>> ...
>>> Along the way to SNMPv3, we learned that a full-blown time
>>> protocol isn't actually necessary to provide authentication,
>>> timeliness, replay protection, etc.  See RFC 3414 for details
>>> on how to get these properties cheaply, both from protocol
>>> overhead and processing perspectives.
>>> Randy
>> Does your "etc" include expiration of access tokens?
> The standard access control model (VACM, RFC 3415) does not
> rely on "access tokens" - what is (and is not) allowed is
> determined the currently configured permissions on the system
> whose information is being accessed / modified / published,
> and the authenticated identity of the user/entity to which the
> information is being delivered or by which it is being modified.
> This may or may not meet your needs.  The SNMP design was driven
> in part by a requirement for things to work correctly even when
> large portions of the internet infrastructure (such as NTP,
> PKI, DNS, etc.) were malfunctioning, broken, or under attack,
> and to work on systems with minimal (from the perspective
> of the late 1980s and extending into the 1990s) capabilities.
> Again, this might not be necessary here.  It does seem, however,
> that what seems like a shortcut here or there can have large
> impacts on the ultimate complexity and technology footprint
> of a design...
> Randy
> _______________________________________________
> Ace mailing list