IETF Logo Mail Archive

Re: [Emu] Adoption call for eap.arpa

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 13 March 2024 13:51 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 27822C151068 for <emu@ietfa.amsl.com>; Wed, 13 Mar 2024 06:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 pviMij5BMyqA for <emu@ietfa.amsl.com>; Wed, 13 Mar 2024 06:51:22 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C0DC14F69F for <emu@ietf.org>; Wed, 13 Mar 2024 06:51:21 -0700 (PDT)
Received: from dyas.sandelman.ca (unknown [104.129.158.24]) by relay.sandelman.ca (Postfix) with ESMTPS id EF8F91F449; Wed, 13 Mar 2024 13:51:19 +0000 (UTC)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.b="GATy9Wyd"; dkim-atps=neutral
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 5931CA00FA; Wed, 13 Mar 2024 09:51:18 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1710337878; bh=DjROmar/JdJcK3DlfSMXTeov6wB0fUB6y+czdZGHcWc=; h=From:To:Subject:In-reply-to:References:Date:From; b=GATy9Wydh+d4vxrqZM+sS4atIAhbVpuDLNRWVela5qcJNZmyaPo37Mh7ZiP0mvKoN AhD9ci91CnEASbJMdttCJ+cZUgqis21s6tihRJPuYUfWhXUJA3+0bkxmC+Yap9PrsX vNzCuex20EFXiuhW5Mgy1/mVden2JQEI7da5ckIkHcyi5bNtJf/q9oHMQgAae0v7OT cnT7FqkSHvmwSowGvoloppSpDhAGhaIzgCMj5CmF9i+mSdha22AMxRE8xpKq7JzVP+ Ba0U3MGqIBM1WzVm5FQnMudD3oSLx6nmQd9RdioZKFsfxhV7ruaKiO7EuPyFDW51L/ vXLYuStM+qFfA==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 56399A00F9; Wed, 13 Mar 2024 09:51:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alexander Clouter <alex+ietf@coremem.com>, EMU WG <emu@ietf.org>
In-reply-to: <11f28e4b-1f21-4cf1-950e-43fdc620447f@app.fastmail.com>
References: <F1FD786F-D0B1-494B-B384-95BBB4B7790B@akayla.com> <ccaa089f2ee34a5e83fe270d2d6adee0@huawei.com> <2a07a31a-b9ff-4640-a348-cd36b270e63a@app.fastmail.com> <7cbce6da-bc18-4c5b-a812-9de4f94bebb9@dfn.de> <11f28e4b-1f21-4cf1-950e-43fdc620447f@app.fastmail.com>
Comments: In-reply-to "Alexander Clouter" <alex+ietf@coremem.com> message dated "Tue, 12 Mar 2024 15:55:41 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 13 Mar 2024 09:51:18 -0400
Message-ID: <1233533.1710337878@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/MD_Bn8kpALu-2JRigqYhuv9ZY3w>
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: Wed, 13 Mar 2024 13:51:26 -0000

Alexander Clouter <alex+ietf@coremem.com> wrote:
    >>> On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote:
    >>>> 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?
    >>>
    >>> So for OOB provisioning (ie. get an IP to access a captive portal)
    >>> the conversation would be:
    >>>
    >>> >>> EAP-Identity Request <<< EAP-Identity Response[portal@eap.arpa]
    >>> >>> EAP-Success
    >>>
    >>> Sounds sensible.
    >>
    >> I don't think it's that straight forward.  For Enterprise-WiFi we
    >> still need cryptographic keys for the WiFi 4-way handshake, so
    >> establishing a TLS-Tunnel is needed to derive the WPA keys.

    > Nice catch.

Doing this is significantly better than either unencrypted wifi (w/portal),
or encrypted WPA-PSK wifi.

So yes, we always want to run EAP-TLS to generate keys.
This document is related to
https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/, (which
I'll repost on Saturday), but modularizes the work into smaller pieces.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

v2.23.0 | Report a Bug | By Email