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

Mališa Vučinić <malisa.vucinic@inria.fr> Fri, 11 December 2020 18:45 UTC

Return-Path: <malisa.vucinic@inria.fr>
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 A35893A0DD7; Fri, 11 Dec 2020 10:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 WYLXTXad5Cfe; Fri, 11 Dec 2020 10:45:28 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 222BB3A0DCE; Fri, 11 Dec 2020 10:45:26 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.78,412,1599516000"; d="scan'208,217";a="367395883"
Received: from adsl-bb22-l204.crnagora.net (HELO [192.168.1.86]) ([95.155.22.204]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 11 Dec 2020 19:45:24 +0100
User-Agent: Microsoft-MacOutlook/10.11.0.180909
Date: Fri, 11 Dec 2020 19:45:21 +0100
From: =?UTF-8?B?TWFsacWhYQ==?= =?UTF-8?B?IFZ1xI1pbmnEhw==?= <malisa.vucinic@inria.fr>
To: Dan Garcia Carrillo <garciadan@uniovi.es>, Michael Richardson <mcr+ietf@sandelman.ca>, EMU WG <emu@ietf.org>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Message-ID: <6C717866-759B-4544-BA04-50D623CF9EFE@inria.fr>
Thread-Topic: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)
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> <CABONVQZRWa5gcN6Z1pfBKx=UVvOTvi1FjLSv0-T_UTUc3XGG5Q@mail.gmail.com> <HE1PR0702MB367429A9C8921A5252133523F4CE0@HE1PR0702MB3674.eurprd07.prod.outlook.com> <24523.1607378991@localhost> <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es> <2923.1607540144@localhost> <62dad652-8acd-0890-36cd-f7aacde19de2@uniovi.es> <D1AA3C26-4376-409A-A87B-F0D05AD1BAD3@inria.fr> <1fdb134e-54a1-1937-fdd6-3d226c89aea7@uniovi.es>
In-Reply-To: <1fdb134e-54a1-1937-fdd6-3d226c89aea7@uniovi.es>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3690560724_1158425664"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/illP8utQv91J7ZdUSqbkGmIzOYg>
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: Fri, 11 Dec 2020 18:45:31 -0000

Hi Dan,

 

Thanks for the clarification regarding minimal-security. The points that you mention below, e.g. flexible authentication or the fresh generation of the PSK, were never in the design scope of our work. 

 

While I fail to understand what exactly do you plan on using EAP-over-CoAP for, I do not object on this work being done in ACE if you are willing to spend cycles on it. I do have reservations on the lightweight aspect of this, however, considering that the sequence diagram that you depict in Fig. 2 in draft-marin-ace-wg-coap-eap-06 spans 3 pages and consumes 2 round trips just to get things started! Surely, we can do better?

 

Mališa

 

From: Dan Garcia Carrillo <garciadan@uniovi.es>
Date: Friday 11 December 2020 at 18:41
To: Mališa Vučinić <malisa.vucinic@inria.fr>fr>, Michael Richardson <mcr+ietf@sandelman.ca>ca>, EMU WG <emu@ietf.org>rg>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>rg>, "ace@ietf.org" <ace@ietf.org>
Cc: <garciadan@uniovi.es>
Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

Hi Mališa, 

My intention was not to turn this conversation into a criticism of your work. “deficiencies” was not the most appropriate word.

What we had in mind was a way of providing authentication  to the variety of IoT devices with different capabilities, limitations or different types of supported credentials. A way of doing that is to provide different authentication methods. Since in IoT there are different technologies we looked for a link-layer independent solution. Additionally, since some technologies are very constrained, we needed a very constrained protocol to carry out the process.

EAP provides flexible authentication, and it has EAP Key Management Framework which is well specified and working for many years, from which you can generate generate a fresh pre-shared key (MSK) dynamically. This is even possible if you do not want to interact with AAA infrastructures running EAP in standalone mode.  Having said this, another thing that we looked into was to give support to large scale deployments. We can ease this process with EAP and its interaction with a AAA infrastructure, which gains relevance in Industrial IoT and 5G. 

All these characteristics can be provided by the use of EAP, if we of course have a lightweight EAP lower layer to transport EAP from the IoT device. Then we considered the usage of CoAP as EAP lower-layer.

In this sense, we saw minimal security did not fit our view (no potential interaction with AAA , flexible authentication, fresh generation of PSK).  In fact,  the provisioning of the PSK was out of scope. 

At some level, we could even consider the work complementary. EAP over CoAP could be a way of providing the PSK for the work of minimal security. 


Best Regards,
Dan.

El 10/12/2020 a las 18:43, Mališa Vučinić escribió:

Hi Dan,

 

Could you be more specific on the point below, what deficiencies do you have in mind?

 

Mališa 

 

From: core <core-bounces@ietf.org> on behalf of Dan Garcia <garciadan@uniovi.es>
Date: Thursday 10 December 2020 at 10:06
To: Michael Richardson <mcr+ietf@sandelman.ca>ca>, EMU WG <emu@ietf.org>rg>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>rg>, "ace@ietf.org" <ace@ietf.org>
Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

As you comment , draft-ietf-6tisch-minimal-security - offers minimal security and has several deficiencies that can be solved by using EAP and AAA infrastructures. 

-->