IETF Logo Mail Archive

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

Randy Presuhn <randy_presuhn@alumni.stanford.edu> Tue, 01 November 2016 00:41 UTC

Return-Path: <randy_presuhn@alumni.stanford.edu>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70192129467 for <ace@ietfa.amsl.com>; Mon, 31 Oct 2016 17:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcKcuIX_c-js for <ace@ietfa.amsl.com>; Mon, 31 Oct 2016 17:41:24 -0700 (PDT)
Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com [209.85.192.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7655120726 for <ace@ietf.org>; Mon, 31 Oct 2016 17:41:24 -0700 (PDT)
Received: by mail-pf0-f169.google.com with SMTP id n85so84974281pfi.1 for <ace@ietf.org>; Mon, 31 Oct 2016 17:41:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4+7E356JMG6FTKxJAH8bvawrD9nJnrrk8dk/9GK0Q4A=; b=ffJedETfJbWV21RB9HOW0bKRPdndIsPh339CKBibsBlvseUh/vRHpravfcQNF0wrAY UYnFCGQgHWgCxvK5fEB16FWU1DDPWCiCyL5PoqR43tyNCw7+yD30lDT/Oit2Vjer5Isq xb5gMWfqJc9wvmZ7ehfI+99ZjuS/220aWVWsDAMMjhhLFXjOsJU3JP891EIDrKZI1jZN VaK6JPKdPZba+5C8HsFyHB80Au765ZeDa/ftcQVVjeyBgZMHmjiyjk+OHqnYDTv//nB2 CrAlPxTm4nlkOyk4XvtP0A6W7DSAal8rgPRpweria4S16IJ47C5GZK4j1KzQioM8IP3k 5mGg==
X-Gm-Message-State: ABUngvexoP4WtiIC+3v/RMMeGSZB3FwOaLoceBK/zgSi6FrhEulC5KeHlZdRPuJl3BgaDLjB
X-Received: by 10.98.150.79 with SMTP id c76mr53917805pfe.154.1477960883993; Mon, 31 Oct 2016 17:41:23 -0700 (PDT)
Received: from [192.168.1.101] (c-67-164-110-148.hsd1.ca.comcast.net. [67.164.110.148]) by smtp.gmail.com with ESMTPSA id ak3sm38103954pad.19.2016.10.31.17.41.22 for <ace@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 17:41:23 -0700 (PDT)
To: ace@ietf.org
References: <CAD2CPUHYGqgzjK7OkC5oc5cSZUKYQP=m=-SuJ1+u20rustCTOw@mail.gmail.com>
From: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Message-ID: <a6f70376-ba13-b6ed-4275-7544608655be@alumni.stanford.edu>
Date: Mon, 31 Oct 2016 17:41:22 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAD2CPUHYGqgzjK7OkC5oc5cSZUKYQP=m=-SuJ1+u20rustCTOw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/7ohLi2KITFKLzes2Hga6sJcgn3s>
Subject: Re: [Ace] New Version Notification for draft-navas-ace-secure-time-synchronization-00.txt
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2016 00:41:27 -0000

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

v2.23.0 | Report a Bug | By Email