IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 09 December 2020 18:55 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 3648E3A16F9; Wed, 9 Dec 2020 10:55:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ck3Y2vIcFDeB; Wed, 9 Dec 2020 10:55:51 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68D83A16F8; Wed, 9 Dec 2020 10:55:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 75E76389B6; Wed, 9 Dec 2020 13:58:04 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 63AalG54iDPk; Wed, 9 Dec 2020 13:57:59 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CA4E23897F; Wed, 9 Dec 2020 13:57:59 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 45DEA4CE; Wed, 9 Dec 2020 13:55:44 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Dan Garcia <dan.garcia@um.es>, EMU WG <emu@ietf.org>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>, "ace@ietf.org" <ace@ietf.org>
In-Reply-To: <3a4e4b59-3712-7eb9-23b2-8160ad14b6aa@um.es>
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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 09 Dec 2020 13:55:44 -0500
Message-ID: <2923.1607540144@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/T9VcSTHtUji5J3r30m20ABu9zNE>
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: Wed, 09 Dec 2020 18:55:53 -0000

Dan Garcia <dan.garcia@um.es> wrote:
    > EAP can be used in the context of IoT for authentication.

But, to what end?

1) If it is onboarding a new device, then there is no connectivity until after authentication.
   so you can't use CoAP, you have to use 802.1x, or some equivalent, or
   create a system such as draft-ietf-6tisch-minimal-security.
   Which does use CoAP and OSCORE already.

2) If it for application authentication, then you need to use EAP to setup
   MSK for later use by a context.
   We do this in IKEv2, (D)TLS already.

So the only left would be OSCORE, yet you write "could", as if it was an afterthought.

Tell me what is your application?  What will be impossible if we don't do
this work?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email