[radext] WG Action: Rechartered RADIUS EXTensions (radext)
The IESG <iesg-secretary@ietf.org> Mon, 21 September 2026 18:14 UTC
Received: by mx.ietf.org (Postfix) id 0C4F830; Mon, 21 Sep 2026 18:14:26 +0000 (UTC)
Received: from [10.244.9.193] (gaia.k8s.ietf.org [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id AC800139A4A88; Mon, 21 Sep 2026 11:14:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.76.0
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <179001446551.280018.11995458657396047437@dt-datatracker-fffdbdc97-wjd6q>
Date: Mon, 21 Sep 2026 11:14:25 -0700
Message-ID-Hash: MMUZ5LCBUBNUBT5W24HPABBN62GLPJIX
X-Message-ID-Hash: MMUZ5LCBUBNUBT5W24HPABBN62GLPJIX
X-MailFrom: iesg-secretary@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-radext.ietf.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: The IESG <iesg@ietf.org>, radext-chairs@ietf.org, radext@ietf.org
X-Mailman-Version: 3.3.10
Subject: [radext] WG Action: Rechartered RADIUS EXTensions (radext)
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/aFrec_BskkROSGLaotZuPsfiaTc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Owner: <mailto:radext-owner@ietf.org>
List-Post: <mailto:radext@ietf.org>
List-Subscribe: <mailto:radext-join@ietf.org>
List-Unsubscribe: <mailto:radext-leave@ietf.org>
The RADIUS EXTensions (radext) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. RADIUS EXTensions (radext) ----------------------------------------------------------------------- Current status: Active WG Chairs: Margaret Cullen <mrcullen42@gmail.com> Valery Smyslov <valery@smyslov.net> Assigned Area Director: Christopher Inacio <stndrds-inacio@andrew.cmu.edu> Security Area Directors: Deb Cooley <debcooley1@gmail.com> Christopher Inacio <stndrds-inacio@andrew.cmu.edu> Mailing list: Address: radext@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/radext Archive: https://mailarchive.ietf.org/arch/browse/radext/ Group page: https://datatracker.ietf.org/group/radext/ Charter: https://datatracker.ietf.org/doc/charter-ietf-radext/ The RADIUS Extensions (RADEXT) Working Group is responsible for maintaining the RADIUS protocol, including defining extensions or making modifications to the RADIUS protocol and related specifications, as needed. The WG is also responsible for publishing best practices or other guidance, as needed, to encourage the security, privacy, stability and reliability of RADIUS deployments. The radext WG will publish: * minor RADIUS extensions as proposed standard * RADIUS roaming and interoperability guidance with regards to historical implementations as informational or best practices * clarifications as informational To ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, all documents produced must specify means of interoperation with legacy RADIUS. Any non-backwards compatibility changes with existing RADIUS RFCs, including the RadSec RFC (when published) must be justified. Transport profiles should be compatible with RFC 3539, with any non-backwards compatibility changes justified. The goals of the RADEXT working group are to: * Define and publish minor extensions to RADIUS, such as new attribute definitions. * Define best practices for RADIUS roaming, and roaming consortia. * Improve operations for multi-hop RADIUS networks, including: + loop detection and prevention. + a multi-hop Status-Server equivalent with ability to Trace the proxy steps a RADIUS message will follow. + improve client-server signaling, and replace non-security requirements to "silently discard" of packets with explicit signaling that a packet (or a set of packets) cannot be processed. + improve signaling of reasons for Access-Reject, including the ability to signal explicit refusal of certain authentications. Milestones: May 2026 - PS Deprecating Insecure Practices in RADIUS draft to IESG May 2026 - PS Review of RADIUS Security and Privacy draft to IESG Aug 2026 - PS RADIUS Connect-Info attribute draft to IESG Aug 2026 - PS RADIUS attributes for National Security and Emergency Preparedness draft to IESG Aug 2026 - INF Carrying location objects with uncertainty in RADIUS draft to IESG Aug 2026 - PS RADIUS Proxy Load Balancing draft to IESG Aug 2026 - PS RADIUS Congestion Control draft to IESG Dec 2026 - PS RADIUS Status-Realm and Loop Prevention draft to IESG