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

Dan Garcia <dan.garcia@um.es> Fri, 22 January 2021 19:05 UTC

Return-Path: <dan.garcia@um.es>
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 426A83A1428 for <ace@ietfa.amsl.com>; Fri, 22 Jan 2021 11:05:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.38
X-Spam-Level:
X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es
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 fzPs8SwjElvQ for <ace@ietfa.amsl.com>; Fri, 22 Jan 2021 11:05:29 -0800 (PST)
Received: from mx02.puc.rediris.es (outbound3sev.lav.puc.rediris.es [130.206.19.174]) (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 E4B073A142A for <ace@ietf.org>; Fri, 22 Jan 2021 11:05:28 -0800 (PST)
Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by mx02.puc.rediris.es with ESMTP id 10MJ5EY7023134-10MJ5EY8023134; Fri, 22 Jan 2021 20:05:14 +0100
Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id C45AD223E0; Fri, 22 Jan 2021 20:05:14 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon44.um.es
Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RFtqeIPUSyDe; Fri, 22 Jan 2021 20:05:14 +0100 (CET)
Received: from [156.35.171.42] (unknown [156.35.171.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 8D70E27708; Fri, 22 Jan 2021 20:05:08 +0100 (CET)
To: Seitz Ludwig <ludwig.seitz@combitech.se>, Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Ace Wg <ace@ietf.org>
References: <CADZyTkkiqC=x_oAYsc_jHHeiNWhjvXHHvOKEeF=9W3si8Dp3pw@mail.gmail.com> <25210.1611242790@localhost> <919f10b3-7ec5-1575-1893-41e4d4cc25b8@ericsson.com> <ede851121bbe4f31905ae968355937f2@combitech.se>
From: Dan Garcia <dan.garcia@um.es>
Message-ID: <343ea339-16be-67bd-ffdd-078fb5d63bb6@um.es>
Date: Fri, 22 Jan 2021 20:05:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <ede851121bbe4f31905ae968355937f2@combitech.se>
Content-Type: multipart/alternative; boundary="------------394B86DC8D33A3C1B809261D"
Content-Language: es-ES
X-FEAS-SPF: spf-result=pass, ip=155.54.212.171, helo=xenon44.um.es, mailFrom=dan.garcia@um.es
Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of dan.garcia@um.es designates 155.54.212.171 as permitted sender) smtp.mailfrom=dan.garcia@um.es
X-FE-Policy-ID: 2:15:0:SYSTEM
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:mime-version:content-type; bh=hLsDf2JNzptvm1h27z3LPnr0MnjTgOtuqT7Pp2s7+58=; b=vJwwtcKu9kXRUCMq3Umcpd+DuGW2h0VkjCoE+9NYdSNAKbI6GUgI9hgvmPTaiUa/i4olXhV84I9K 30DWb+3FFSzETAINmBQpRrx/Q1cfgFUEbWYx4DGkSrLTed29gPMwyR/XzU2fdK2QEElggnTng+03 7Etm1xoKytcK6OB8jKgFixLAX2P/tmrps6u+cwWPRvdjhzmqIfQ6xuIAGMalyKNOxlGpVH3A08Wi Z6zKRA3MqNbpfX6qbYU0clUY9eNcOftKRf8ftYXpEua3dvCcAc0qUv4pSwkn2tlSvkhARXRTLNNw Qzrxj6v/sMgefvFND2lnO+peKb3KQtOfu/rIMA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ukmHaioHma90RA5YyCNihta2QEQ>
Subject: Re: [Ace] [EXTERNAL] Re: 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: Fri, 22 Jan 2021 19:05:31 -0000

Hi Ludwig,

Basically, to bring the features that EAP has into IoT.

Such as:

- 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.

With regards to the overhead EAP brings, it is a small price to pay 
having into account this benefits. In fact, our work is all about using 
CoAP so the EAP transport is lightweight and we think is worth the effort.

Best Regards,

Dan.


El 22/01/2021 a las 16:17, Seitz Ludwig escribió:
>
> I’d like to second the question Mohit assumes Michael is asking:
>
> What is the benefit, in the context of IoT, to add the overhead of EAP 
> to say TLS?
>
> /Ludwig
>
> *From:*Ace <ace-bounces@ietf.org> *On Behalf Of *Mohit Sethi M
> *Sent:* den 22 januari 2021 15:37
> *To:* Michael Richardson <mcr+ietf@sandelman.ca>ca>; Ace Wg <ace@ietf.org>
> *Subject:* [EXTERNAL] Re: [Ace] call for adoption for 
> draft-marin-ace-wg-coap-eap
>
> Hi Michael,
>
> I guess the question you are asking is: what is the benefit of adding 
> the overhead of EAP. For EAP-TLS, you could directly use TLS. For 
> EAP-pwd (which is a PAKE) one could use any PAKE without the EAP 
> encapsulation overhead?
>
> Is your concern only in the context of IoT or do you think in general 
> we are better off using protocols directly without the EAP framework 
> overhead?
>
> --Mohit
>
> On 1/21/21 5:26 PM, Michael Richardson wrote:
>
>     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  <mailto:mcr@sandelman.ca>   http://www.sandelman.ca/  <http://www.sandelman.ca/>         |   ruby on rails    [
>
>     --
>
>     Michael Richardson<mcr+IETF@sandelman.ca>  <mailto:mcr+IETF@sandelman.ca>    . o O ( IPv6 IøT consulting )
>
>                 Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>     _______________________________________________
>
>     Ace mailing list
>
>     Ace@ietf.org  <mailto:Ace@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/ace  <https://www.ietf.org/mailman/listinfo/ace>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace