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

[Bernard Aboba <[e-mail]>]

A few comments on the Charter:

"- Deprecate the use of insecure transports outside of secure
networks. This work updates RFC 6421
<https://datatracker.ietf.org/doc/rfc6421/> where possible."

[BA] RFC 6421 is the document that governs the process and requirements for
promotion of secure versions of RADIUS to Proposed Standard.  As was
discussed at the BOF, RFC 6421 requires that for publication as a Proposed
Standard, secure successors meets requirements for security as well as for
deployment and interoperability of independent implementations.  Until
RADIUS over (D)TLS can meet the requirements for publication as a Proposed
Standard, it would not be appropriate to deprecate the RADIUS protocol, and
the Charter should not lower the bar established in RFC 6421.

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

[BA] As was discussed at the BOF, RADIUS over IPsec, defined in RFC 3579,
has been deployed for more than 20 years in environments requiring FIPS-140
compliance. To enforce FIPS-140 compliance, RADIUS servers are configured
in "FIPS mode", which leaves them capable of using only FIPS-compliant
cryptographic primitives. As a result, attempts to utilize MD5 in transport
security such as IPsec or (D)TLS, EAP methods, or within the RADIUS
authenticator will fail. Rather than "defining a secure variant of RADIUS",
it is only necessary for the RADIUS over (D)TLS documents to describe how
implementations should behave in the absence of MD5 or other
FIPS-prohibited cryptographic primitives. For example, this would preclude
negotiation of (D)TLS ciphersuites utilizing MD5 or other prohibited
cryptographic operations.





On Mon, Nov 21, 2022 at 12:03 PM Paul Wouters <paul.wouters=
[e-mail]> wrote:

> 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.
>
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
>