Re: [radext] BoF request for IETF 115
Stefan Winter <stefan.winter@restena.lu> Fri, 09 September 2022 12:56 UTC
Return-Path: <stefan.winter@restena.lu>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E7FC15256D for <radext@ietfa.amsl.com>; Fri, 9 Sep 2022 05:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 CNHD8fzPy8JF for <radext@ietfa.amsl.com>; Fri, 9 Sep 2022 05:56:05 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 A2163C15256B for <radext@ietf.org>; Fri, 9 Sep 2022 05:56:04 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id B8169302895 for <radext@ietf.org>; Fri, 9 Sep 2022 12:56:01 +0000 (UTC)
Received: from [IPV6:2001:a18:1:10:53d1:ce29:f611:824a] (unknown [IPv6:2001:a18:1:10:53d1:ce29:f611:824a]) by smtprelay.restena.lu (Postfix) with ESMTPSA id AD72C30288B for <radext@ietf.org>; Fri, 9 Sep 2022 12:56:01 +0000 (UTC)
Message-ID: <4bff8903-3f3c-71bb-3df3-70d25ec0de20@restena.lu>
Date: Fri, 09 Sep 2022 14:56:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
From: Stefan Winter <stefan.winter@restena.lu>
To: radext@ietf.org
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AV-Checked: ClamAV using ClamSMTP
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/v3imfuOLxWTbLYVCTMvqeAp_GqA>
Subject: Re: [radext] BoF request for IETF 115
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2022 12:56:08 -0000
Hello! I believe it is useful to execute the work Alan sketched in his mail. From what we see in production use of RADIUS/TLS as specified right now in RFC6613/RFC6614: in almost all aspects, it is a good stop-gap measure to overcome RADIUS/UDP's privacy and crypto agility limitations. In practice, it is much more wide-spread than the current document track "EXP" woud suggest. At least two world-wide roaming consortia make ample use of it: eduroam and WBA OpenRoaming. Brushing up the protocols towards newer crypto, FIPS compliance etc. makes perfect sense given that RADIUS is here to stay for extended amounts of time. One thing we struggle with: PKI is really hard to do right; but if one doesn't need dynamic discovery as per RFC7585, TLS-PSK can be a drop-in replacement for RADIUS shared secrets. The work done here should stress that PSK ciphersuites are a perfectly viable option for most deployments and provide a low barrier of entry for upgrading to the better protocol. I hope I can attend a possible BoF in person, should it be approved. Greetings, Stefan Winter -- This email may contain information for limited distribution only, please treat accordingly. Fondation Restena, Stefan WINTER Chief Technology Officer 2, avenue de l'Université L-4365 Esch-sur-Alzette
- [radext] BoF request for IETF 115 Alan DeKok
- Re: [radext] BoF request for IETF 115 Bernard Aboba
- Re: [radext] BoF request for IETF 115 Stefan Winter
- Re: [radext] BoF request for IETF 115 josh.howlett
- Re: [radext] BoF request for IETF 115 klaas@wierenga.net
- Re: [radext] BoF request for IETF 115 Margaret Cullen
- Re: [radext] BoF request for IETF 115 Bernard Aboba
- Re: [radext] BoF request for IETF 115 Alan DeKok
- Re: [radext] BoF request for IETF 115 Alexander Clouter
- Re: [radext] BoF request for IETF 115 Bernard Aboba
- Re: [radext] BoF request for IETF 115 Peter Deacon
- Re: [radext] BoF request for IETF 115 Alan DeKok
- Re: [radext] BoF request for IETF 115 Alexander Clouter
- Re: [radext] BoF request for IETF 115 Alan DeKok
- Re: [radext] BoF request for IETF 115 josh.howlett
- Re: [radext] BoF request for IETF 115 Peter Deacon
- Re: [radext] BoF request for IETF 115 Alan DeKok
- Re: [radext] BoF request for IETF 115 Bernard Aboba
- Re: [radext] BoF request for IETF 115 Stefan Winter
- Re: [radext] BoF request for IETF 115 Alan DeKok
- Re: [radext] BoF request for IETF 115 Karri Huhtanen
- Re: [radext] BoF request for IETF 115 josh.howlett
- Re: [radext] BoF request for IETF 115 Alan DeKok
- Re: [radext] BoF request for IETF 115 josh.howlett
- Re: [radext] BoF request for IETF 115 Alan DeKok
- Re: [radext] BoF request for IETF 115 josh.howlett
- Re: [radext] BoF request for IETF 115 Margaret Cullen
- Re: [radext] BoF request for IETF 115 Jan-Frederik Rieckers
- Re: [radext] BoF request for IETF 115 Alan DeKok