Re: [radext] the future of RADEXT

lionel.morand@orange.com Wed, 09 February 2022 09:53 UTC

Return-Path: <lionel.morand@orange.com>
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 03D563A0D29 for <radext@ietfa.amsl.com>; Wed, 9 Feb 2022 01:53:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 4Fu72D7S0V5A for <radext@ietfa.amsl.com>; Wed, 9 Feb 2022 01:52:55 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0704F3A1372 for <radext@ietf.org>; Wed, 9 Feb 2022 01:52:55 -0800 (PST)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr23.francetelecom.fr (ESMTP service) with ESMTPS id 4JtwD516KBz5vl5; Wed, 9 Feb 2022 10:52:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1644400373; bh=CTUuNQ3EMv/GgV3xZrARfl/yMADr4tScqT+4GckIU5U=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=WKvvMu2N+QFCu/iCpxYpZQ6x4uagf3EFcCws6V3cKulWMrAV4IbFCsfccdHk+ll4B syKcXTKCpWAOXU0m9LMxXKZ6c8X9kLOevVL1V7hdAC3cyImEO4S+Q6OlK832sQNwlL iIZa/qdrU0Q1KDs4GtRay0LRLSHPSIvrzlaqMsytn56i5wIKYNbmt+YnsRBpk9GZtR NyYHk0PGZx8DgI469ehl3FFscvOe6SMq3NvW/USk73n1qZb6ch8A5ozDUlJJ2nNYNv 8OeezSntUgC4Lq0tqbRrmo7aka5fFKP1MN7cD37jpOK9925ReY8YS30dWYtzWSQOqa 4brJBx/yim5QQ==
From: lionel.morand@orange.com
To: Bernard Aboba <bernard.aboba@gmail.com>, Alan DeKok <aland@deployingradius.com>
CC: "radext@ietf.org" <radext@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Thread-Topic: [radext] the future of RADEXT
Thread-Index: AQHYHR4HkL4CufpIm0iFwo1+Uy3aUayJ+F2AgAAOlICAAPRTEA==
Date: Wed, 09 Feb 2022 09:52:52 +0000
Message-ID: <24556_1644400373_62038EF5_24556_70_1_a640e7a651304caba8267c4e50566d54@orange.com>
References: <20220208185920.GK48552@kduck.mit.edu> <46636323-221D-4CBE-9E97-8425A82F2460@deployingradius.com> <CAOW+2duwKw-hnF+rzD9-4dG0Bq989Y8BALmOfuTdEZZzQv-WFA@mail.gmail.com>
In-Reply-To: <CAOW+2duwKw-hnF+rzD9-4dG0Bq989Y8BALmOfuTdEZZzQv-WFA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-09T09:52:51Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-02-09T09:52:50Z
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 2903193f-21e1-4009-b6e0-9101179f056c
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0
x-originating-ip: [10.115.27.53]
Content-Type: multipart/alternative; boundary="_000_a640e7a651304caba8267c4e50566d54orangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/Psy8kE_LRV9rWOfkzMdiB-ht-a4>
Subject: Re: [radext] the future of RADEXT
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 09 Feb 2022 09:53:00 -0000

I would be happy to contribute.

Lionel



Orange Restricted
De : radext <radext-bounces@ietf.org> De la part de Bernard Aboba
Envoyé : mardi 8 février 2022 21:18
À : Alan DeKok <aland@deployingradius.com>
Cc : radext@ietf.org; Benjamin Kaduk <kaduk@mit.edu>
Objet : Re: [radext] the future of RADEXT

Alan said:

"It would be useful to standardize RFC 6613, 6614, and 7360.  Along with updating them for TLS 1.3, and adding things like Server Name Indicator."

[BA] RFC 6421 laid out the process for developing a crypto-agile version of RADIUS.  The last phase of that roadmap (selection of standardization candidates) remains outstanding, and needs to be completed.

"I suspect, however, that there is limited interest, even though such work would be useful."

[BA] A secure version of RADIUS will not be easy to deploy, but it's an important task nevertheless. The information that flows unprotected over networks via RADIUS includes information on the control and management of network devices as well as information that can be used to determine the location of users.  From a cryptographic standpoint, the RADIUS protocol was substandard in the 1990s, and now, 30 years later it represents a major weakness in critical infrastructure.  That's the kind of problem that governments may want to take an interest in fixing.








On Tue, Feb 8, 2022 at 11:26 AM Alan DeKok <aland@deployingradius.com<mailto:aland@deployingradius.com>> wrote:
On Feb 8, 2022, at 1:59 PM, Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
> As such, I believe that we should close the RADEXT WG and continue to
> redirect further RADIUS work to OPSAWG, including solutions for the
> Identifier problem if energy appears to work on them.

  I think that's reasonable.

> Please let me know (on list is fine) if you have concerns about this plan
> by 22 February 2022, along with any alternative proposals that might
> address those concerns.  However, in order to demonstrate that there is
> energy to keep the WG open and make progress on our remaining chartered
> item, I would need to see interest from multiple individuals in pursuing
> such a course of action, along with an estimate for when such work would
> ultimately be completed (that would function as a deadline for re-assessing
> the WG's progress and possibly closing the WG if insufficient progress is
> being made).

  I'm happy to work on RADIUS things.  It would be useful to standardize RFC 6613, 6614, and 7360.  Along with updating them for TLS 1.3, and adding things like Server Name Indicator.

  I suspect, however, that there is limited interest, even though such work would be useful.

> This is by no means a failure outcome; the WG has produced a lot of good
> work and we should be proud of what we have accomplished even as we look
> forward to what might be done in OPSAWG in the future.

  I agree.

  Alan DeKok.

_______________________________________________
radext mailing list
radext@ietf.org<mailto:radext@ietf.org>
https://www.ietf.org/mailman/listinfo/radext

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.