[radext] Proposed charter text based on IETF-115 BoF

[Paul Wouters <[e-mail]>]

Hi all,

Based on the inputs and discussions during the BoF at IETF-115 we have
updated the proposed charter text. It can be found at
https://datatracker.ietf.org/doc/charter-ietf-radextra/submit//

I've included it below.

Thanks to Stephen Farrell, Alan deKok and Margaret Cullen and everyone at
the BoF (local and remote!) for their help.

Please let us know of any issues but also let us know if you believe the
proposed charter is ready

Paul


charter-ietf-radextra-00-00

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
<https://datatracker.ietf.org/doc/rfc6421/> where possible.

- Bring RFC 6614 <https://datatracker.ietf.org/doc/rfc6614/>
(RADIUS/TLS), and RFC 7360 <https://datatracker.ietf.org/doc/rfc7360/>
(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.