[radext] Proposed new charter text
Stefan Winter <stefan.winter@restena.lu> Fri, 13 March 2015 10:13 UTC
Return-Path: <stefan.winter@restena.lu>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3656A1A1BE0 for <radext@ietfa.amsl.com>; Fri, 13 Mar 2015 03:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] 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 RJzLgT4LUt5B for <radext@ietfa.amsl.com>; Fri, 13 Mar 2015 03:13:12 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435041A1BD2 for <radext@ietf.org>; Fri, 13 Mar 2015 03:13:12 -0700 (PDT)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id EE66443976 for <radext@ietf.org>; Fri, 13 Mar 2015 11:13:10 +0100 (CET)
Message-ID: <5502B836.5000100@restena.lu>
Date: Fri, 13 Mar 2015 11:13:10 +0100
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="biGo81oSPPFe1oSP2u7cW34w6tbSklqV9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/gkY3dDaCTlUkGZaTT2uYnZ5ADtA>
Subject: [radext] Proposed new charter text
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2015 10:13:15 -0000
Hello, as you may recall, we discussed new charter text at IETF91, which was unanimously accepted in the room. We still need to verify consensus on the list, so below is the proposed updated charter text. This mail starts a two week comment period on the charter text. Please send your comments to the list until 2015-03-27 2400 UTC. You'll notice that there is specific text for "data types", "CoA proxy" and "Populating EAP identity" in the draft charter's Work Items. Judging from the mailing list traffic and prior discussions at the last IETF meeting, I believe there is consensus that the working group wants to work on these problem. As soon as the charter is approved, I will issue an adoption call for the individual drafts which go in that direction. We should also adjust milestones (some items to be marked as Done, some new target dates for the ongoing work). These are not formally part of the charter update, but they fit nicely into this mail nontheless. For the completion dates, some authors have indicated a very short timeframe for completion, but I've set everything at least to "2 meetings ahead" -> November 2015; simply because our working group has a certain track record of always being slower than anticipated :-) Here is the text, see the IETF91 slides for a rationale of the changed bits: "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. It will also define a new attribute which defines an opaque NAS identifier which can be used to uniquely identify a visited NAS, and whose value will not be modified when proxying, as is done with NAS-Identifier and NAS-IP-Address. - 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. Where a NAS is required to verbatimly copy 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. This will be a standards track document. - 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 (mark RFC4282bis as Done [RFC Editor Queue now]) (mark RADIUS packet fragemntation as Done [in RFC Editor Queue now]) (mark Dynamic Discovery as Done [in IETF LC now]) Nov 2015 - Submit CoA Proxying as Standards Track RFC Nov 2016 - Submit Populating EAP Identity as BCP RFC Nov 2015 - Data Types as Informational RFC Nov 2015 - Larger Packets for RADIUS over TCP as Experimental RFC Mar 2016 - IP Port RADIUS Extensions as Standards Track RFC Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
- Re: [radext] Proposed new charter text Peter Deacon
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Peter Deacon
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Peter Deacon
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Peter Deacon
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Peter Deacon
- Re: [radext] Proposed new charter text Sam Hartman
- Re: [radext] Proposed new charter text Stefan Winter
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Sam Hartman
- Re: [radext] Secure COA Sam Hartman
- Re: [radext] Secure COA Alan DeKok
- Re: [radext] Secure COA Sam Hartman
- Re: [radext] Proposed new charter text Peter Deacon
- [radext] Proposed new charter text Stefan Winter
- Re: [radext] Proposed new charter text Stefan Winter
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Stefan Winter