Charter for Working Group

The RADIUS Extensions Working Group will focus on extensions to theRADIUS protocol pending approval of the new work from the Area Directorand clarify its usage and definition.

Furthermore, to ensure backward compatibility with existing RADIUSimplementations, as well as compatibility between RADIUS and Diameter,the following restriction is imposed on extensions considered by theRADEXT WG:All documents produced must specify means of interoperation with legacyRADIUS and, if possible, be backward compatible with existing RADIUSRFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675,5080, 5090, 5176 and 6158. Transport profiles should, if possible, becompatible with RFC 3539.

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

- CoA proxying. RFC 5176 permits proxying of CoA and Disconnectmessages, but makes no provisions for how that is done in a roamingenvironment. This work item will provide descriptions of how to usethe Operator-Name attribute in a roaming environment to proxy CoApackets in a way that ensures only authorized proxies can send thesepackets to the home CoA server.

- Encoding Rules for EAP-Response/Identity packets over RADIUS. NeitherEAP (RFC3748) nor EAP over RADIUS (RFC3579) demand specific characterencoding and normalisation rules for EAP Identity responses. RADIUS(RFC2865) requires User-Name attributes to be encoded in UTF-8. When a NASsimply performs an exact copy of an EAP-Identity into a User-Name, invalid packets might be produced. This document will suggest restrictions on EAPIdentities so that transport over AAA becomes correct under all circumstances (UTF-8) and deterministic (normalisation).

- Data Types. RFC 2865 defines a number of data types, but laterdocuments do not use those types in a consistent way. This work itemwill define data types, and update the IANA RADIUS Attribute Typeregistry so that each attribute has a data type. Where necessary, itwill correct issues with previous specifications.