IETF Logo Mail Archive

Re: [Emu] Adoption call for eap.arpa

Jan-Frederik Rieckers <rieckers@dfn.de> Tue, 12 March 2024 14:45 UTC

Return-Path: <rieckers@dfn.de>
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 42CA2C14F6AE for <emu@ietfa.amsl.com>; Tue, 12 Mar 2024 07:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=dfn.de
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 Qhc33KXA4gAk for <emu@ietfa.amsl.com>; Tue, 12 Mar 2024 07:45:20 -0700 (PDT)
Received: from b1004.mx.srv.dfn.de (b1004.mx.srv.dfn.de [IPv6:2001:638:d:c302:acdc:1979:2:58]) (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 53EB9C14F680 for <emu@ietf.org>; Tue, 12 Mar 2024 07:45:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dfn.de; h= content-type:content-type:in-reply-to:organization:from:from :references:content-language:subject:subject:user-agent :mime-version:date:date:message-id:received; s=s1; t=1710254714; x=1712069115; bh=HboYZK6mtegDrGSbqEKGfoKaOG43pYNYtbyhzxJpXH8=; b= RYo3cCDmtIVFjcpb8Vm8q5ROAXHSHfsyQIaCk37C+4/78g4P9bv84VneyrEnEHOj BORJJK/bvtq+ROWPHiu8+Cef53OgXMZeHKs8m6cN8TQHvxgPSL6lUY0U3lcVtI0E 01OQ/5JbSeSVHw9B+mvYaif6ZiS2sBmt/7ILjf4YTbo=
Received: from mail.dfn.de (mail.dfn.de [IPv6:2001:638:d:c102::150]) by b1004.mx.srv.dfn.de (Postfix) with ESMTPS id C36BA2200CB for <emu@ietf.org>; Tue, 12 Mar 2024 15:45:14 +0100 (CET)
Received: from [192.168.179.26] (unknown [79.140.117.242]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mspool2.in.dfn.de (Postfix) with ESMTPSA id A61193D6 for <emu@ietf.org>; Tue, 12 Mar 2024 15:45:14 +0100 (CET)
Message-ID: <7cbce6da-bc18-4c5b-a812-9de4f94bebb9@dfn.de>
Date: Tue, 12 Mar 2024 15:45:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: emu@ietf.org
References: <F1FD786F-D0B1-494B-B384-95BBB4B7790B@akayla.com> <ccaa089f2ee34a5e83fe270d2d6adee0@huawei.com> <2a07a31a-b9ff-4640-a348-cd36b270e63a@app.fastmail.com>
From: Jan-Frederik Rieckers <rieckers@dfn.de>
X-Enigmail-Draft-Status: N11222
Organization: DFN e.V.
In-Reply-To: <2a07a31a-b9ff-4640-a348-cd36b270e63a@app.fastmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms060308060900090108030804"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/6Gj-DXrHDVA_ElXR6if_EJDzeq8>
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 14:45:25 -0000


On 12.03.24 13:45, Alexander Clouter 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.

Cheers,
Janfred
-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieckers@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822

v2.23.0 | Report a Bug | By Email