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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 21 January 2021 15:26 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 A96A03A1019 for <ace@ietfa.amsl.com>; Thu, 21 Jan 2021 07:26:35 -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 IMg5t8Bxexzh for <ace@ietfa.amsl.com>; Thu, 21 Jan 2021 07:26:33 -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 DF8243A100E for <ace@ietf.org>; Thu, 21 Jan 2021 07:26:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B6D138B9F for <ace@ietf.org>; Thu, 21 Jan 2021 10:28:33 -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 6ECfn6xLLjzO for <ace@ietf.org>; Thu, 21 Jan 2021 10:28:33 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 13E2F38B9E for <ace@ietf.org>; Thu, 21 Jan 2021 10:28:33 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 388194AB for <ace@ietf.org>; Thu, 21 Jan 2021 10:26:30 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ace Wg <ace@ietf.org>
In-Reply-To: <CADZyTkkiqC=x_oAYsc_jHHeiNWhjvXHHvOKEeF=9W3si8Dp3pw@mail.gmail.com>
References: <CADZyTkkiqC=x_oAYsc_jHHeiNWhjvXHHvOKEeF=9W3si8Dp3pw@mail.gmail.com>
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: Thu, 21 Jan 2021 10:26:30 -0500
Message-ID: <25210.1611242790@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/8xDYGk3yA-fFcTzsjhwgUxScEGM>
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: Thu, 21 Jan 2021 15:26:36 -0000

I reviewed the document before, and my concerns were not really answered.

I can not understand what the applicability is.

The document starts off with:

   The goal of this document is to describe an authentication service
   that uses the Extensible Authentication Protocol (EAP) [RFC3748].
   The authentication service is built on top of the Constrained
   Application Protocol (CoAP) [RFC7252] and ALLOWS AUTHENTICATING TWO
   CoAP endpoints by using EAP without the need of ADDITIONAL PROTOCOLS
   TO BOOTSTRAP A SECURITY ASSOCIATION BETWEEN THEM.


...
   The assumption is that the EAP method transported in CoAP MUST
   generate cryptographic material [RFC5247]

This implies use of one of the many EAP-TLS modes, some EAP PAKE
mode, or maybe, in theory some EAP-SIM/AKA mode.

1) TLS modes could just use TLS, or DTLS and omit the extra EAP
   bytes.  If saving those bytes are not important, then
   the use of PANA seems to do the same thing.

2) The EAP PAKE modes could just TLS with some PSK or PAKE
   authentication.

3) The EAP-SIM/AKA modes are not realistic, as they generally depend upon
   being able to talk to a database of SIM/AKA secrets.

So, which modes that generate cryptographic material are envisioned?

The document goes on to say:

   The CoAP client MAY contact
   with a backend AAA infrastructure to complete the EAP negotiation as
   described in the EAP specification [RFC3748].

which is a third party, when the intro told me that no third party was
required.  Even figure 1 show three parties.
And section 5 says there might be five parties, again including an AAA server.

I believe that this entire proposal goes against the ACE architecture,
and should not be adopted by this WG.
This work seems to duplicate the work in LAKE, as well as cTLS, while not
bringing any clear advantage over existing protocols.

If adopted, I don't review the document.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



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