[Sandbox-mailoutput] [Django development] Internal WG Review: RADIUS EXTensions (radext)

The attached message would have been sent, but the tracker is in development mode.
It was not sent to anybody.

A new IETF WG is being considered in the IETF. The draft charter for this WG
is provided below for your review and comment.

Review time is one week.

The IETF Secretariat

RADIUS EXTensions (radext)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Margaret Cullen <mrcullen42@gmail.com>
  Valery Smyslov <valery@smyslov.net>

Assigned Area Director:
  Paul Wouters <paul.wouters@aiven.io>

Operations and Management Area Directors:
  Warren Kumari <warren@kumari.net>
  Robert Wilton <rwilton@cisco.com>

Mailing list:
  Address: radext@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/radext
  Archive: https://mailarchive.ietf.org/arch/browse/radext/

Charter: https://sandbox.ietf.org/doc/charter-ietf-radext/

The RADIUS Extensions (RADEXT) Working Group is chartered to carry
out specific maintenance tasks for the RADIUS protocol as described
below.

To ensure backward compatibility with existing RADIUS implementations,
all documents produced must specify means of interoperation with legacy
RADIUS and, if possible, be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675,
5080, 5090, 5176, 5997, 6158, 6613, 6614, 6929, 7360, 7585, 8044, and 8559.

The WG may revisit the status of existing RADIUS RFCs, possibly changing
document track categories with minor changes in the documents as needed.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- Deprecate the use of insecure transports outside of secure
networks. This work updates RFC 6421 where possible.

- Bring RFC 6614 (RADIUS/TLS), and RFC 7360 (RADIUS/DTLS) to
Standards track.

- Define best practices for RADIUS roaming, and roaming consortia
based on experience with RADIUS/TLS.

- Improve operations for multi-hop RADIUS networks: e.g. loop detection
and prevention, a multi-hop Status-Server equivalent with ability to
Trace the proxy steps a RADIUS message will follow.

- Extend the 8-bit RADIUS ID space to allow more than 256 "in flight"
packets across one connection.

- Allow for CoA / Disconnect packets to be sent in "reverse" down a
RADIUS/TLS or RADIUS/DTLS connection. This functionality assists with
transit of NATs.

- Defining a secure variant of RADIUS which can be used in a FIPS-140
compliant environment.

There is an external timeline that affects this work: completion by 2024
would enable WG outputs to be included in the planned WiFi 8 release. The
WG will aim to meet that deadline.

Adopting work items not described above will require a re-charter.

Milestones: