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

Benjamin Kaduk <kaduk@mit.edu> Tue, 12 January 2021 19:05 UTC

Return-Path: <kaduk@mit.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 3F8BD3A1034 for <ace@ietfa.amsl.com>; Tue, 12 Jan 2021 11:05:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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 HBIc0XgAchWh for <ace@ietfa.amsl.com>; Tue, 12 Jan 2021 11:05:24 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 812C83A1033 for <ace@ietf.org>; Tue, 12 Jan 2021 11:05:24 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10CJ5GnM013140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jan 2021 14:05:21 -0500
Date: Tue, 12 Jan 2021 11:05:16 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Dan Garcia Carrillo <garciadan@uniovi.es>
Cc: "ace@ietf.org" <ace@ietf.org>
Message-ID: <20210112190516.GR161@kduck.mit.edu>
References: <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> <6C717866-759B-4544-BA04-50D623CF9EFE@inria.fr> <238e2b03-a9b3-918a-2a9b-fbb66b84ddbf@uniovi.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <238e2b03-a9b3-918a-2a9b-fbb66b84ddbf@uniovi.es>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/EHDzrrSaIZwD6yJ9TpUIFKVxN50>
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: Tue, 12 Jan 2021 19:05:27 -0000

Hi Dan,

Sorry to reply to such an old message...

On Sat, Dec 12, 2020 at 06:36:53PM +0100, Dan Garcia Carrillo wrote:
> Hi Mališa,
> 
> 
> El 11/12/2020 a las 19:45, Mališa Vučinić escribió:
> >
> > 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?
> >
> Yes, we will submit an updated version of the draft.

When you do, I suggest putting in some discussion of the relative
size/overhead for CoAP as EAP lower-layer vs the EAP payloads themselves.
I note that the IESG recently approved draft-ietf-emu-eaptlscert that
discusses some pathological cases with TLS-based EAP methods and very large
certificate chains.  While I assume that you're not planning to do
EAP-over-CoAP with such long TLS certificate chains, giving reviewers a
sense for how big of an improvement this mechanism can be will presumably
be helpful.

Thanks,

Ben