WG Action: Rechartered RADIUS EXTensions (radext)
The IESG <iesg-secretary@ietf.org> Fri, 10 July 2015 15:46 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E701B29D8; Fri, 10 Jul 2015 08:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APlxnmjug67j; Fri, 10 Jul 2015 08:46:33 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1800E1B2A01; Fri, 10 Jul 2015 08:46:33 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Action: Rechartered RADIUS EXTensions (radext)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150710154633.29053.42049.idtracker@ietfa.amsl.com>
Date: Fri, 10 Jul 2015 08:46:33 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-announce/5NV5Flq23pzCYGr8bL91-A_x3fI>
Cc: radext WG <radext@ietf.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2015 15:46:35 -0000
The RADIUS EXTensions (radext) working group in the Operations and Management 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: Stefan Winter <stefan.winter@restena.lu> Lionel Morand <lionel.morand@orange.com> Assigned Area Director: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.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: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol pending approval of the new work from the Area Director and clarify its usage and definition. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restriction is imposed on extensions considered by the RADEXT WG: 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 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. The WG will review its existing RFCs' document track categories and where necessary or useful change document tracks, with minor changes in the documents if needed. Any changes to document tracks require approval by the responsible Area Director. Work Items The immediate goals of the RADEXT working group are to address the following issues: - CoA proxying. RFC 5176 permits proxying of CoA and Disconnect messages, but makes no provisions for how that is done in a roaming environment. This work item will provide descriptions of how to use the Operator-Name attribute in a roaming environment to proxy CoA packets in a way that ensures only authorized proxies can send these packets to the home CoA server. - Encoding Rules for EAP-Response/Identity packets over RADIUS. Neither EAP (RFC3748) nor EAP over RADIUS (RFC3579) demand specific character encoding and normalisation rules for EAP Identity responses. RADIUS (RFC2865) requires User-Name attributes to be encoded in UTF-8. When a NAS simply performs an exact copy of an EAP-Identity into a User-Name, invalid packets might be produced. This document will suggest restrictions on EAP Identities 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 later documents do not use those types in a consistent way. This work item will define data types, and update the IANA RADIUS Attribute Type registry so that each attribute has a data type. Where necessary, it will correct issues with previous specifications. - Larger Packets. Support RADIUS packets greater than 4096-octets over RADIUS transports with this capability. - RADIUS Attributes for IP Port Configuration and Reporting. These attributes are used by devices that implement IP port ranges to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behaviors. These attributes can be used in the context of address sharing (e.g., NAT44 [RFC3022], Dual-Stack Lite AFTR [RFC6333], CGN [RFC6888], NAT64 [RFC6146], Provider WLAN (e.g., [TR-146]), etc.). Milestones: Done - Dynamic Discovery I-D submitted as a Proposed Standard RFC Done - RFC 4282bis submitted as a Proposed Standard RFC Done - RADIUS packet fragmentation submitted as an Experimental RFC Nov 2015 - Larger Packets for RADIUS over TCP I-D submitted as an Experimental RFC Nov 2015 - Submit CoA Proxying as Standards Track RFC Mar 2016 - IP Port RADIUS Extensions as Standards Track RFC Nov 2016 - Submit Populating EAP Identity as BCP RFC Nov 2016 - Data Types as Informational RFC