Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

Laurent Toutain <Laurent.Toutain@telecom-bretagne.eu> Thu, 03 December 2020 19:01 UTC

Return-Path: <Laurent.Toutain@telecom-bretagne.eu>
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 EAF703A067A; Thu, 3 Dec 2020 11:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.076
X-Spam-Level:
X-Spam-Status: No, score=-2.076 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, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telecom-bretagne.eu
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 vC46gYcX0NzB; Thu, 3 Dec 2020 11:01:29 -0800 (PST)
Received: from zproxy120.enst.fr (zproxy120.enst.fr [IPv6:2001:660:330f:2::c1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A8F3A064B; Thu, 3 Dec 2020 11:01:27 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 37ACD80D57; Thu, 3 Dec 2020 20:01:25 +0100 (CET)
Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id hbqJ2crASlQQ; Thu, 3 Dec 2020 20:01:24 +0100 (CET)
Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 363378080D; Thu, 3 Dec 2020 20:01:24 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr 363378080D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-bretagne.eu; s=CFDC2CFA-4654-11E5-AACD-7BCC68B6580D; t=1607022084; bh=PwiDt1aSyP6yxRqp7KLM/IdAF58HYfKpGOPJ5cyhe4I=; h=MIME-Version:From:Date:Message-ID:To; b=TuvQp6zcL8BvBrDHmT6BM62YCTOcjpQpaODjcqZdzowt5UNkIdEhgCgNCz300TGWK Q+iA0/KF8OIKIbUgo3w+yTiGI+CN2jqR4Pv0lUGjD7KBC1AWLY5qS+CdgCUN1ct+sE FEjeN5is5GXjo0F3q88rr9TEqqcywez/eeEOVLoU=
X-Virus-Scanned: amavisd-new at zproxy120.enst.fr
Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id IoFMnGYxcV6E; Thu, 3 Dec 2020 20:01:24 +0100 (CET)
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by zproxy120.enst.fr (Postfix) with ESMTPSA id B675980D57; Thu, 3 Dec 2020 20:01:23 +0100 (CET)
Received: by mail-io1-f41.google.com with SMTP id q137so3173903iod.9; Thu, 03 Dec 2020 11:01:23 -0800 (PST)
X-Gm-Message-State: AOAM533fW5iEPD/sAyYRW35Kr3739DF/xblqwHftPoFo65xbTZdUvcv+ 4QXM3yGCo+RV+UIIDfejxUS8e1T5qWt0HAwedO8=
X-Google-Smtp-Source: ABdhPJy5mefNbUhkstUmgpWiWp6Lp1f4PHQAUEsrCY3F55voNZLYdoQ/TfHj5B9ieJkIZR2PAM6SXhU7QGgHqZb/zDA=
X-Received: by 2002:a5d:9a8e:: with SMTP id c14mr807929iom.178.1607022082534; Thu, 03 Dec 2020 11:01:22 -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> <CADZyTknej3DUbbKbRxdfi0HqVR7G7qkAh5htu3w9yFjE09sOtg@mail.gmail.com> <b78c1176-ffa0-9ad5-847e-94e9134b4212@um.es> <DM6PR15MB2379308BD779061F6F46233EE3F20@DM6PR15MB2379.namprd15.prod.outlook.com>
In-Reply-To: <DM6PR15MB2379308BD779061F6F46233EE3F20@DM6PR15MB2379.namprd15.prod.outlook.com>
From: Laurent Toutain <Laurent.Toutain@telecom-bretagne.eu>
Date: Thu, 3 Dec 2020 20:00:44 +0100
X-Gmail-Original-Message-ID: <CABONVQZRWa5gcN6Z1pfBKx=UVvOTvi1FjLSv0-T_UTUc3XGG5Q@mail.gmail.com>
Message-ID: <CABONVQZRWa5gcN6Z1pfBKx=UVvOTvi1FjLSv0-T_UTUc3XGG5Q@mail.gmail.com>
To: Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>
Cc: Dan Garcia <dan.garcia@um.es>, "ace@ietf.org" <ace@ietf.org>, EMU WG <emu@ietf.org>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000060341a05b593fca0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/-ZAccIQ6-gglr1DV4fZ6IIZR3qo>
Subject: Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)
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: Thu, 03 Dec 2020 19:01:34 -0000

Hi,

I think it is important to have EAP on top of CoAP, as Dan said it fit well
with the last charter item.

Laurent

On Thu, Dec 3, 2020 at 2:20 PM Daniel Migault <daniel.migault=
40ericsson.com@dmarc.ietf.org> wrote:

> CCing emu, core
>
> It seems ACE to me that ACE could be home for such a document. I am
> wondering if emu core or any other WG believe there is a better place for
> it.
>
> Regarding ACE I am wondering what is the WG opinion about adding this item
> to the ACE charter.
>
> Yours,
> Daniel
> ------------------------------
> *From:* Ace <ace-bounces@ietf.org> on behalf of Dan Garcia <
> dan.garcia@um.es>
> *Sent:* Thursday, December 3, 2020 6:10 AM
> *To:* ace@ietf.org <ace@ietf.org>
> *Subject:* [Ace] Proposed charter for ACE (EAP over CoAP?)
>
>
> Dear all:
>
> Regarding the new charter, since ACE is considering the definition of CoAP
> transport for CMPv2 (
> https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), we
> were wondering whethere it could also consider specifying EAP (Extensible
> Authentication Protocol) over CoAP.
>
> In this sense, we proposed this some time ago and we have implementations
> about this.
>
> https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06
> https://www.mdpi.com/1424-8220/16/3/358
> https://www.mdpi.com/1424-8220/17/11/2646
>
> The usage of CoAP can provide a very light and link-layer independent (we
> even tested in LoRa networks) EAP lower-layer (transport for EAP) suitable
> for IoT enviroment. We believe this would be really useful since EAP
> provides flexibility for the authentication and it is a well-known protocol.
>
> Therefore, we would like to propose the following modification to the
> charter:
>
> "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 them as needed."
>
> This modification does not necessarily mean the adoption of our draft.
> After all, we completely understand that this would happen only if there is
> an interest in the WG. Nevertheless, we would like to avoid that the
> charter is a barrier later if there is interest in the WG to work in this
> transport of EAP over CoAP:
>
> Any opinion about this?
>
> Best Regards.
> El 18/11/2020 a las 8:08, Daniel Migault escribió:
>
> Hi,
>
> Please find the proposed charter we agreed on during the interim meeting.
> If you would like to propose any change, please use the following URL by
> November 25:
>
>
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing
> <https://protect2.fireeye.com/v1/url?k=f9dc6551-a6475d83-f9dc25ca-866132fe445e-9c25a5c257a23470&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
>
> 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, and standardize as needed.
>
>
> 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
> <https://protect2.fireeye.com/v1/url?k=a01e017d-ff8539af-a01e41e6-866132fe445e-7268e18ca0e30ad7&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> >
> > 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=2eaaeb96-7131d344-2eaaab0d-866132fe445e-7e515f25c81762b8&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> > >> <
> > >>
> 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 mailing listAce@ietf.orghttps://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>


-- 
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit
:
| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
http://class.touta.in
| Laurent@Touta.in         | Laurent.Toutain@Telecom-Bretagne.eu    |
+--------------------------+----------------------------------------+