IETF Logo Mail Archive

Re: [Emu] Adoption call for eap.arpa

"Yanlei(Ray)" <ray.yanlei@huawei.com> Tue, 12 March 2024 12:38 UTC

Return-Path: <ray.yanlei@huawei.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE69C15108A for <emu@ietfa.amsl.com>; Tue, 12 Mar 2024 05:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.205
X-Spam-Level:
X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGDMytCrO4Xi for <emu@ietfa.amsl.com>; Tue, 12 Mar 2024 05:38:13 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B488EC15108C for <emu@ietf.org>; Tue, 12 Mar 2024 05:37:41 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TvCp873rPz6J9wC for <emu@ietf.org>; Tue, 12 Mar 2024 20:37:20 +0800 (CST)
Received: from lhrpeml100004.china.huawei.com (unknown [7.191.162.219]) by mail.maildlp.com (Postfix) with ESMTPS id C16BA140D1A for <emu@ietf.org>; Tue, 12 Mar 2024 20:37:38 +0800 (CST)
Received: from kwepemm000017.china.huawei.com (7.193.23.46) by lhrpeml100004.china.huawei.com (7.191.162.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 12 Mar 2024 12:37:38 +0000
Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm000017.china.huawei.com (7.193.23.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 12 Mar 2024 20:37:36 +0800
Received: from kwepemm600017.china.huawei.com ([7.193.23.234]) by kwepemm600017.china.huawei.com ([7.193.23.234]) with mapi id 15.01.2507.035; Tue, 12 Mar 2024 20:37:36 +0800
From: "Yanlei(Ray)" <ray.yanlei@huawei.com>
To: EMU WG <emu@ietf.org>
Thread-Topic: Adoption call for eap.arpa
Thread-Index: AQHacOBGGO+N6/K8zkqhhChRjASLArEz/x4w
Date: Tue, 12 Mar 2024 12:37:36 +0000
Message-ID: <ccaa089f2ee34a5e83fe270d2d6adee0@huawei.com>
References: <F1FD786F-D0B1-494B-B384-95BBB4B7790B@akayla.com>
In-Reply-To: <F1FD786F-D0B1-494B-B384-95BBB4B7790B@akayla.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.39.228]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/rw3p1w1X9a-m0Y8e9iEEggL8CMQ>
Subject: Re: [Emu] Adoption call for eap.arpa
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2024 12:38:17 -0000

I think this work is useful for bootstrapping IoT devices. I am in favour of adoption.

There is also a comment.
In Section 5.1 EAP-TLS, " This identifier signals the EAP server that the peer wishes to obtain "peer unauthenticated access" as per [RFC5216] Section 2.1.1 and [RFC9190]. " and " The device SHOULD ignore the EAP server certificate entirely, as the servers identity does not matter. Any verification of servers can be done at the HTTPS layer when the device access the captive portal. "
My understanding here is that the EAP server and client will not authenticate each other in EAP-TLS, and all the authentication will be done in the " captive portal ". So why recommend EAP-TLS as a provisioning method? Just send the identifier "portal@eap.arpa" and then jump to a " captive portal ". Is that OK?

Regards,
Lei YAN

-----Original Message-----
From: Emu <emu-bounces@ietf.org> On Behalf Of Peter Yee
Sent: Friday, March 8, 2024 6:38 AM
To: emu@ietf.org
Subject: [Emu] Adoption call for eap.arpa

This is an adoption call for the eap.arpa Internet-Draft (draft-dekok-emu-eap-arpa). This is an ancillary draft that Alan DeKok briefed during the Prague (IETF 118) meeting. Seeing as it primarily exists as a forward-looking extraction of certain descriptive material and IAB .arpa domanrequests from other EMU documents, we consider it within the scope of the WG charter. Alan did a recent minor update to the document and will speak briefly about it during IETF 119.

With that said, your WG chairs would appreciate hearing your feedback on whether this document is adopted or not. While it's not critical to adopt, it really simplifies the domain registration for things like TLS-POK and would have been great back when we did EAP-NOOB.

We are particularly interested in hearing from parties who are willing to review the specification. So, if you've got interest in seeing the work adopted, please formalize that by responding to the EMU mailing list with your position. 

The deadline for feedback is March 21st. Yes, that's during IETF
119 but after the EMU time slot, so hopefully you will have formed an opinion by then, if not sooner. We hope to hear from lots of you!

Joe and Peter

1) https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa/


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

v2.23.0 | Report a Bug | By Email