Re: [Ace] call for adoption for draft-marin-ace-wg-coap-eap

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 23 January 2021 00:29 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 3730A3A161C for <ace@ietfa.amsl.com>; Fri, 22 Jan 2021 16:29:52 -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 jmuqgcjebDzX for <ace@ietfa.amsl.com>; Fri, 22 Jan 2021 16:29:49 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4FD3A1625 for <ace@ietf.org>; Fri, 22 Jan 2021 16:29:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2F5173899D; Fri, 22 Jan 2021 19:31:37 -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 TTThCE5wr1il; Fri, 22 Jan 2021 19:31:36 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7DDA838994; Fri, 22 Jan 2021 19:31:36 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6F5B3B2; Fri, 22 Jan 2021 19:29:28 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Dan Garcia Carrillo <garciadan@uniovi.es>, Ace Wg <ace@ietf.org>
In-Reply-To: <05c2ada5-69d8-e6aa-f658-efbac839d414@uniovi.es>
References: <CADZyTkkiqC=x_oAYsc_jHHeiNWhjvXHHvOKEeF=9W3si8Dp3pw@mail.gmail.com> <25210.1611242790@localhost> <919f10b3-7ec5-1575-1893-41e4d4cc25b8@ericsson.com> <29623.1611333484@localhost> <05c2ada5-69d8-e6aa-f658-efbac839d414@uniovi.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: Fri, 22 Jan 2021 19:29:28 -0500
Message-ID: <22573.1611361768@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Vr-iYvkc5x-2repE7QX4l9sKMuA>
Subject: Re: [Ace] call for adoption for draft-marin-ace-wg-coap-eap
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: Sat, 23 Jan 2021 00:29:58 -0000

Dan Garcia Carrillo <garciadan@uniovi.es> wrote:
    > I hope the last email answered your questions.

Are you talking about this answer:

> - Well known protocol thas provides flexible authentication with diffrent methods and counting.
> - It integrates well with AAA.
> - It has a standard and very well known Key Management Framework.

because it continues to not be answer.

These are all features of EAP.
How does EAP-over-CoAP benefit?

EAP can be used inside (D)TLS (and maybe even cTLS) without CoAP having to carry EAP.
I guess you want to be able to key OSCORE.
So, I would guess that this must involve not using EAP-TLS* (or TEAP, or
TTLS, etc.), so I think that reduces to some kind of EAP-PAKE situation,
or EAP-SIM/AKA.

Do both peer talk to the same AAA server?

In that case, then they must have already established a secure relationship
with the AAA server. (Because, radius demands it).
If you have that, then you can just use the ACE framework to get OSCORE keys,
treating the AAA server as the AS or RS.

If they don't talk to the same AAA server, then how are the AAA servers related?

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