Re: [Ace] Charter discussion
Daniel Migault <mglt.ietf@gmail.com> Mon, 07 December 2020 13:43 UTC
Return-Path: <mglt.ietf@gmail.com>
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 14A063A13A5 for <ace@ietfa.amsl.com>; Mon, 7 Dec 2020 05:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 TJ4RGRb8Yqug for <ace@ietfa.amsl.com>; Mon, 7 Dec 2020 05:43:40 -0800 (PST)
Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (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 709413A13A3 for <ace@ietf.org>; Mon, 7 Dec 2020 05:43:40 -0800 (PST)
Received: by mail-vs1-xe43.google.com with SMTP id x4so7542206vsp.7 for <ace@ietf.org>; Mon, 07 Dec 2020 05:43:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HZ71sd4CGrFSI/8AEFOEibGvsV3cfyUnHoLiB9Qo+ak=; b=vczPxzVV9cpEnPHsLQ4GKfjozGRUytDESsHIyeD7CldjutMdyPmGje/3rrFMLGPEGH urWCj29ZO/kEoRFoRxYqVsPfvn61cQpbahcsjEJyogR7iJggRSRGEU1ANvro6gU6gmmI Qya4wdC/ZbSd1nTFU6P8ZI9u182nj9cJCoMImBWbOTK6d9Ha10EVO3grhBXja3Xo5pEJ JCi1Qn+0TC9LrBgEijiDIbQ2xTolWrYwU+VwLB1vaKj+1gCvYUCIuzE7bqk4bVcvsPLU Tt8kP6NAti6nz40MyZi+O6p3qz2QEUQV+aeqBqXgs7EWTGoSzP4pNRn8ts7nYoSF85H5 1JwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HZ71sd4CGrFSI/8AEFOEibGvsV3cfyUnHoLiB9Qo+ak=; b=I7OQmLESFC/57BelybjGoP/RMjaSGdJqnNLYdmGXj6ZQCazPfzsZ+g+aoaDdSiQ08n 0FCRTxlxuHnJy8c43LHV7s4gBol7Grmg5LdN6uZ6KxXW9t6Gj2Oyund7xxrRkRSyLijs 1HQNfzV0OEadBjhzc6luCRwdhM4gf84LQyZV5NUljYFkm7mRasX2O7j738+wJoFZgkeX ia7uXgiL60yAt+25CNrbLSbwlWdWHoO2BDCwBPn1JeeLM50dT/pcffNI4FGv/GBRfwNi Rnh4EC1wvj7QhyqrFgsF9rEPTakMieOPCC4Xs+rwBYFyD0dtxG0+/T+W8e5tTJSxutB7 5tlw==
X-Gm-Message-State: AOAM533EnVAQ/0tU+Q7hPueie7xnn+Om5kAw9viEo3fJf46Q1ieCRpVF aD/Wzv6Cq/bIYR/GOK/Ibe2VaaGg5iM0rgYIzes=
X-Google-Smtp-Source: ABdhPJxPyAvn6vTPSG1jQjfJIacuo6BBYABr1yLzHqBdnXzq5qaXR1iTalc16gIU14ITmRMNtwFkNAbZZBcwMSUGgOQ=
X-Received: by 2002:a67:32d4:: with SMTP id y203mr11497322vsy.30.1607348619387; Mon, 07 Dec 2020 05:43:39 -0800 (PST)
MIME-Version: 1.0
References: <CADZyTkmnV_Dhb5iXzykUyEAskLDg7tj=80CbEBGmSyFQNS2FHw@mail.gmail.com> <HE1PR0702MB36740BAAFD7FDA2688564BF7F4E60@HE1PR0702MB3674.eurprd07.prod.outlook.com> <CADZyTkkpLRvqD5Vx704u=qbRvE82o4cKk3Ff2Y2ZXes_B+nRbA@mail.gmail.com> <CADZyTkkSGiUvXf0NoVUwj0Vjf7AQ=pjdEHyHZsDdE67OvfTepw@mail.gmail.com> <20201117234700.GR39170@kduck.mit.edu>
In-Reply-To: <20201117234700.GR39170@kduck.mit.edu>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Mon, 07 Dec 2020 08:43:28 -0500
Message-ID: <CADZyTkmGFsPruMsZCudra7Qs7dUGfGe4TAnYzroLAckZBy6s0Q@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007d278d05b5e00370"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/_sfwG5oopnT-W9aW2umoBAIdojw>
Subject: Re: [Ace] Charter discussion
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 07 Dec 2020 13:43:43 -0000
Hi, Please have a look at the latest version of the charter before we move it forward by the end of the week - December 11. I added a note on potential WG that could host the CMPv2 over CoAP - eventually. I am wondering if we should put a note to these WGs. Yours, Daniel The Authentication and Authorization for Constrained Environments (ace) WG has defined a standardized solution framework for authentication and authorization to enable authorized access to resources identified by a URI and hosted on a resource server in constrained environments. The access to the resource is mediated by an authorization server, which is not considered to be constrained. Profiles of this framework for application to security protocols commonly used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also been standardized. The Working Group is charged with maintenance of the framework and existing profiles thereof, and may undertake work to specify profiles of the framework for additional secure communications protocols and for additional support services providing authorized access to crypto keys (that are not necessarily limited to constrained endpoints, though the focus remains on deployment in ecosystems with a substantial portion of constrained devices). In addition to the ongoing maintenance work, the Working Group will extend the framework as needed for applicability to group communications, with initial focus on (D)TLS and (Group) OSCORE as the underlying group communication security protocols. The Working Group will standardize procedures for requesting and distributing group keying material using the ACE framework as well as appropriated management interfaces. The Working Group will standardize a format for expressing authorization information for a given authenticated principal as received from an authorization manager. The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, as well as a transport for authentication protocols such as EAP, and standardize as needed. [Note that CMPv2 work may also be hosted in LAMPS (which revisits CMPv2), ANIMA ( which defines CMPv2 as an alternative to EST) or IOTPS. EAP work has been coordinated with EMU. In any case, if the work is being considered in ACE, we will make sure the corresponding WG will follow the progress.] On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > Thanks for updating the draft charter at [1], Daniel! > > I note that Michael raised the question of whether some other group might > also be interested in working on CMP-over-coap, so the IESG will be sure to > discuss that if CMP is still in the draft ACE charter when it goes to the > IESG for review. > > -Ben > > On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote: > > Thank you all for the feed backs. For the purpose of driving the charter > > discussion at the IETf 109, I have added the comments into the proposed > > text [1]. > > > > My current understanding is that it seems beneficial to add CMPv2 over > CoAP > > in the charter. I am happy to be contradicted. > > * I have not seen a clear cut to do one or the other. > > * EST and CMPv2 are two protocols that can be used for enrollment or cert > > management while addressing different cases / needs / situations -- maybe > > we can clarify that point. I can see leveraging the existing CMP > > infrastructure, but it seems that is not the only one. > > * I am not convinced that not having CMP over CoAP will not prevent its > > deployment and as such I prefer to have it standardized - this might be a > > personal thought. > > * Adding any piece of work require cycles, but it seems to me that CPM > will > > not have a major impact on the WG progress. The work will probably > include > > other WG such a LAMPS. > > > > Yours, > > Daniel > > > > [1] > > > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing > > > > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <mglt.ietf@gmail.com> > wrote: > > > > > Hi Goran, > > > > > > I added the text to the charter we will discuss later. > > > > > > Yours, > > > Daniel > > > > > > On Fri, Nov 13, 2020 at 10:26 AM Göran Selander < > > > goran.selander@ericsson.com> wrote: > > > > > >> Hi Daniel, > > >> > > >> > > >> > > >> Here’s another input to the charter. > > >> > > >> > > >> > > >> The current group key management solutions addresses the problem of > > >> authorized access to group keys and public keys of group members. > > >> > > >> > > >> > > >> A related problem is authorized access of public keys of other devices > > >> not necessarily part of a security group, in the sense of sharing a > > >> symmetric key used to protect group messages. > > >> > > >> > > >> > > >> Authorized access to raw public keys serves an important function in > > >> constrained settings where public key certificates may not be > feasible due > > >> to the incurred overhead, e.g. for when authenticating using EDHOC > > >> (draft-ietf-lake-edhoc). > > >> > > >> This functionality is thus a subset of what is already supported, but > > >> since the current solution is geared towards groups a different > solution > > >> may be needed (although it is probably possible to reuse parts from > the > > >> existing schemes for provisioning and requesting public keys). > > >> > > >> > > >> > > >> With this in mind, I propose the following change (highlighted in > > >> boldface below): > > >> > > >> > > >> > > >> OLD > > >> > > >> The Working Group is charged with maintenance of the framework and > > >> existing profiles thereof, and may undertake work to specify profiles > of > > >> the framework for additional secure communications protocols (that > are not > > >> necessarily limited to constrained endpoints, though the focus > remains on > > >> deployment ecosystems with a substantial portion of constrained > devices). > > >> > > >> > > >> > > >> NEW > > >> > > >> The Working Group is charged with maintenance of the framework and > > >> existing profiles thereof, and may undertake work to specify profiles > of > > >> the framework for additional secure communications protocols *and > **for > > >> additional **support services **providing* *authorized access to > crypto* *keys > > >> *(that are not necessarily limited to constrained endpoints, though > the > > >> focus remains on deployment ecosystems with a substantial portion of > > >> constrained devices). > > >> > > >> > > >> > > >> Göran > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> On 2020-10-15, 19:50, "Ace" <ace-bounces@ietf.org> wrote: > > >> > > >> Hi, > > >> > > >> I would like to start the charter discussion. Here is a draft of a > > >> proposed charter [1]. > > >> > > >> > > >> > > >> It seems to be that additional discussion is needed with regard to the > > >> last paragraph related certificate management. In particular the > discussion > > >> might revive a discussion that happened in 2017 [2] - when I was not > > >> co-chair of ACE -and considered other expired work such as [3]. > Please make > > >> this discussion constructive on this thread. > > >> > > >> > > >> > > >> The fundamental question is whether we need certificate management at > > >> this stage. If the answer is yes, and we have multiple proposals, it > would > > >> be good to clarify the position of the different proposals and > evaluate > > >> whether a selection is needed or not before validating the charter. > > >> > > >> > > >> > > >> Please provide your inputs on the mailing list before October 30. Of > > >> course for minor edits, you may suggest them directly on the google > doc. > > >> > > >> > > >> > > >> Yours, > > >> > > >> Daniel > > >> > > >> > > >> > > >> [1] > > >> > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing > > >> < > > >> > https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing > > > > >> > > >> > > >> [2] > > >> > https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/ > > >> > > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/ > > >> > > >> > > >> > > >> -- > > >> > > >> Daniel Migault > > >> > > >> > > >> > > >> Ericsson > > >> > > > > > > > > > -- > > > Daniel Migault > > > Ericsson > > > > > > > > > -- > > Daniel Migault > > Ericsson > > > _______________________________________________ > > 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 > -- Daniel Migault Ericsson
- [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Göran Selander
- Re: [Ace] Charter discussion Michael Richardson
- Re: [Ace] Charter discussion Göran Selander
- Re: [Ace] Charter discussion Panos Kampanakis (pkampana)
- Re: [Ace] Charter discussion Brockhaus, Hendrik
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Göran Selander
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Benjamin Kaduk
- [Ace] Proposed charter for ACE Daniel Migault
- [Ace] Proposed charter for ACE (EAP over CoAP?) Dan Garcia
- Re: [Ace] Proposed charter for ACE (EAP over CoAP… Daniel Migault
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Laurent Toutain
- Re: [Ace] [Emu] Proposed charter for ACE (EAP ove… Mohit Sethi M
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Göran Selander
- Re: [Ace] Charter discussion Olaf Bergmann
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Brockhaus, Hendrik
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Michael Richardson
- Re: [Ace] Charter discussion Brockhaus, Hendrik
- Re: [Ace] [Emu] [core] Proposed charter for ACE (… Dan Garcia
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Dan Garcia
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Alexander Pelov
- Re: [Ace] Proposed charter for ACE (EAP over CoAP… Christian Amsüss
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Carsten Bormann
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Michael Richardson
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Dan Garcia
- Re: [Ace] Proposed charter for ACE (EAP over CoAP… Georgios PAPADOPOULOS
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Mališa Vučinić
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Dan Garcia Carrillo
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Mališa Vučinić
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Dan Garcia Carrillo
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Benjamin Kaduk
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Dan Garcia