Re: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est
peter van der Stok <stokcons@xs4all.nl> Fri, 15 September 2017 08:05 UTC
Return-Path: <stokcons@xs4all.nl>
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 DBB14133056 for <ace@ietfa.amsl.com>; Fri, 15 Sep 2017 01:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 8Sm06O-zjkvP for <ace@ietfa.amsl.com>; Fri, 15 Sep 2017 01:05:09 -0700 (PDT)
Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F89313304D for <ace@ietf.org>; Fri, 15 Sep 2017 01:05:09 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud7.xs4all.net with ESMTPA id slcYdTnLAG5oqslcYdsMQ5; Fri, 15 Sep 2017 10:05:07 +0200
Received: from AMontpellier-654-1-184-83.w92-145.abo.wanadoo.fr ([92.145.163.83]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 15 Sep 2017 10:05:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Fri, 15 Sep 2017 10:05:06 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Göran Selander <goran.selander@ericsson.com>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Ace@ietf.org
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <D5DFAADE.87626%goran.selander@ericsson.com>
References: <e5f4cf2f-b394-6466-ea76-7c1a83d1837f@gmx.net> <D5DFAADE.87626%goran.selander@ericsson.com>
Message-ID: <006810ecb742e1a0640528ee78f7c88f@xs4all.nl>
X-Sender: stokcons@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfL37ZV/QDzsk1dOccHQQzaR3DdO25prNA17gR2/UtIB3q3GDPjxiVX0n9zMOUitxffKnCYcDzoFHl8KE29QzqLBz6xFGOwTxcZ2SCBYgvXe1QfiJhMtr TVuR6B10OXK26uDvJQWapivXymSA+lvbmWWbyXbJ0LXl/aB35k761qb9yWVLtSEryrPVPsTWLVs2aMdfWzTY5lvLN/DORR5Eibcn25v5F06ilKI4bJu0gOcZ 6bWArQMo7I5AJqAJV34qkA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/MoFOa-Txw71bP0xJfQoX2LrMdJk>
Subject: Re: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 15 Sep 2017 08:05:13 -0000
Hi Goran and Hannes, Thanks Hannes, for starting the discussion. I am glad to contribute to this discussion, as one of the more interested parties, co-author of est-coaps. Looking at the charter of ACE, the following sentences seemed of interest to me. "As a starting point, the working group will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS. Both resource server and client may be constrained. This access will be mediated by an authorization server, which is not considered to be constrained." " Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained." It clearly states that for the authorization and authentication coap and dtls are the first technologies that are investigated followed by other technologies. Mapping this approach from authorization to certificate management, The same text seems valid to me, and I consider the coap-est draft belonging to the coap-dtls focus and eals draft belonging to other technologies. They are complementary in my view. Currently, many manufacturers are happy to use their "finally" working dtls implementation. They are reluctant to try anything new at this moment. That motivates the writing of the coap-est draft. That does not mean that manufacturers will not go over to new technology in a later stage, once the advantages are clearer, and more experience has been gained. Neither does it mean that all manufacturers are glued to their current DTLS implementation. Although ACE focuses on authentication and authorization, it is the WG that looks after security for constrained devices, using RESTful techniques, CoAP and TLS/DTLS; and as such I hope the "certificate management" drafts fit in. Looking forward to other reactions on this subject. Peter Göran Selander schreef op 2017-09-14 08:47: > Hi Hannes, > > Now for the topic of comparing the certificate enrolment drafts. > draft-vanderstok-ace-coap-est proposes a very natural and significant > optimization of EST adapted to the established security setup for CoAP, > and I fully support that. There are overlapping authors between the > drafts, so clearly the drafts should not be seen in opposition to each > other. > The implicit question posed by draft-selander-ace-eals is the > following: > If we are considering one IoT variant of EST > (draft-vanderstok-ace-coap-est) should we also consider other variants > using the same enrolment procedure, which can be applied to a wider > range > of IoT use cases and/or which are more favourable in settings with > constrained IoT devices? > > Göran > > On 2017-09-13 17:42, "Ace on behalf of Hannes Tschofenig" > <ace-bounces@ietf.org on behalf of hannes.tschofenig@gmx.net> wrote: > >> Hi all, >> >> in previous IETF meetings we had presentations on these two documents >> and it appears that there is an overlap. So far we haven't had a lot >> of >> discussions on these proposals on the list but since there seems to be >> interest from the folks attending the IETF meetings I am recommending >> to >> have a discussion about the direction we should go with this work. >> >> Any thoughts? >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace
- [Ace] draft-selander-ace-eals vs. draft-vandersto… Hannes Tschofenig
- Re: [Ace] draft-selander-ace-eals vs. draft-vande… Göran Selander
- Re: [Ace] draft-selander-ace-eals vs. draft-vande… Cigdem Sengul
- Re: [Ace] draft-selander-ace-eals vs. draft-vande… peter van der Stok
- Re: [Ace] draft-selander-ace-eals vs. draft-vande… Eliot Lear
- Re: [Ace] draft-selander-ace-eals vs. draft-vande… Panos Kampanakis (pkampana)