[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG Review: Recharter of RADIUS Extensions Working Group (radext)
I suggest to consider the comments from Magnus during the IESG/IAB
internal review as IETF review comments and address them.
Dan
> -----Original Message-----
> From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On
> Behalf Of IESG Secretary
> Sent: Wednesday, May 14, 2008 1:00 AM
> To: ietf-announce@ietf.org
> Cc: Bernard_Aboba@hotmail.com; d.b.nelson@comcast.net;
> radiusext@ops.ietf.org
> Subject: WG Review: Recharter of RADIUS Extensions Working
> Group (radext)
>
> A modified charter has been submitted for the RADIUS
> Extensions Working Group in the Operations and Management
> Area of the IETF. The IESG has not made any determination as
> yet. The modified charter is provided below for
> informational purposes only. Please send your comments to
> the IESG mailing list (iesg@ietf.org) by May 20, 2008.
>
>
> RADIUS Extensions Working Group (radext)
> ----------------------------------------
> Last Modified: 2008-04-30
>
> Current Status: Active Working Group
>
> Chair(s):
> * Bernard Aboba <Bernard_Aboba@hotmail.com>
> * David Nelson <d.b.nelson@comcast.net>
>
>
> Operations and Management Area Director(s):
> * Dan Romascanu <dromasca@avaya.com>
> * Ronald Bonica <rbonica@juniper.net>
>
>
> Operations and Management Area Advisor:
> * Dan Romascanu <dromasca@avaya.com>
>
>
> Technical Advisor(s):
> * Paul Congdon <paul.congdon@hp.com>
>
>
> Mailing Lists:
> General Discussion: radiusext@ops.ietf.org
> To Subscribe: radiusext-request@ops.ietf.org
> In Body: In Body: subscribe
> Archive: https://ops.ietf.org/lists/radiusext
>
>
> Description of Working Group:
>
> The RADIUS Extensions Working Group will focus on extensions to the
> RADIUS protocol required to define extensions to the standard
> attribute space as well as to address cryptographic algorithm
> agility and use over new transports. In addition, RADEXT will
> work on RADIUS Design Guidelines and define new attributes for
> particular applications of authentication, authorization and
> accounting such as NAS management and local area network (LAN) usage.
>
> In order to enable interoperation of heterogeneous RADIUS/Diameter
> deployments, all RADEXT WG work items MUST contain a Diameter
> compatibility section, outlining how interoperability with
> Diameter will be maintained.
>
> Furthermore, to ensure backward compatibility with existing RADIUS
> implementations, as well as compatibility between RADIUS and Diameter,
> the following restrictions are imposed on extensions considered by the
> RADEXT WG:
>
> - All documents produced MUST specify means of interoperation with
> legacy RADIUS implementations and, if possible, be backward
> compatible with existing RADIUS RFCs, including RFCs 2865-2869,
> 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176.
> Transport profiles should, if possible, be compatible with RFC 3539.
>
> - All RADIUS work MUST be compatible with equivalent facilities in
> Diameter. Where possible, new attributes should be defined so that
> the same attribute can be used in both RADIUS and Diameter without
> translation. In other cases a translation considerations
> section should be included in the specification.
>
>
> Work Items
>
> The immediate goals of the RADEXT working group are to address the
> following issues:
>
> - RADIUS design guidelines. This document will provide guidelines for
> design of RADIUS attributes. It will specifically consider how
> complex data types may be introduced in a robust manner, maintaining
> backwards compatibility with existing RADIUS RFCs, across all the
> classes of attributes: Standard, Vendor-Specific and SDO-Specific.
> In addition, it will review RADIUS data types and associated
> backwards compatibility issues.
>
> - RADIUS Management authorization. This document will define the
> use of RADIUS for NAS management over IP.
>
> -RADIUS attribute space extension. The standard RADIUS attribute
> space is currently being depleted. This document will provide
> additional standard attribute space, while maintaining backward
> compatibility with existing attributes.
>
> -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
> relied on MD5 for both per-packet integrity and authentication as well
> as attribute confidentiality. Given the increasingly successful
> attacks being mounted against MD5, the ability to support
> alternative algorithms is required. This work item will
> include documentation of RADIUS crypto-agility requirements,
> as well as development of one or more Experimental RFCs providing
> support for negotiation of alternative cryptographic algorithms
> to protect RADIUS.
>
> - IEEE 802 attributes. New attributes have been proposed to
> support IEEE 802 standards for wired and wireless LANs. This
> work item will support authentication, authorization and
> accounting attributes needed by IEEE 802 groups including
> IEEE 802.1, IEEE 802.11 and IEEE 802.16.
>
> - New RADIUS transports. A reliable transport profile for
> RADIUS will be developed, as well as specifications for
> Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS.
>
> - Documentation of Status-Server usage. A document
> describing usage of the Status-Server facility will be
> developed.
>
> Goals and Milestones:
>
> Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice
> RFC
> Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed
> Standard RFC
> Sep 2008 RADIUS Crypto-agility Requirements submitted as an
> Informational
> RFC
> Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC
> Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
> Jan 2009 Reliable Transport Profile for RADIUS I-D submitted
> as a Proposed
> Standard RFC
> Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
> Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an
> Experimental
> RFC
> June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
> June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an
> Experimental RFC
>
From: iesg-bounces@iesg.org on behalf of Magnus Westerlund
[magnus.westerlund@ericsson.com]
Sent: Thursday, May 08, 2008 5:50 PM
To: IESG Secretary
Cc: Bernard_Aboba@hotmail.com; d.b.nelson@comcast.net; iab@iab.org;
iesg@ietf.org
Subject: Re: Internal WG Review: Recharter of RADIUS Extensions Working
Group(radext)
Some comments on this charter:
IESG Secretary skrev:
> A new charter for the RADIUS Extensions working group (radext) in the
> Operations and Managemet Area of the IETF is being considered. The
> draft charter is provided below for your review and comment.
>
> Review time is one week.
>
> The IETF Secretariat
>
> RADIUS Extensions Working Group (radext)
> ----------------------------------------
> Last Modified: 2008-04-30
>
> Chair(s):
> * Bernard Aboba <Bernard_Aboba@hotmail.com>
> * David Nelson <d.b.nelson@comcast.net>
>
>
> Operations and Management Area Director(s):
> * Dan Romascanu <dromasca@avaya.com>
> * Ronald Bonica <rbonica@juniper.net>
>
>
> Operations and Management Area Advisor:
> * Dan Romascanu <dromasca@avaya.com>
>
>
> Technical Advisor(s):
> * Paul Congdon <paul.congdon@hp.com>
>
>
> Mailing Lists:
> General Discussion: radiusext@ops.ietf.org To Subscribe:
> radiusext-request@ops.ietf.org In Body: In Body: subscribe
> Archive: https://ops.ietf.org/lists/radiusext
>
>
> Description of Working Group:
>
> The RADIUS Extensions Working Group will focus on extensions to the
> RADIUS protocol required to define extensions to the standard
> attribute space as well as to address cryptographic algorithm agility
> and use over new transports. In addition, RADEXT will work on RADIUS
> Design Guidelines and define new attributes for particular
> applications of authentication, authorization and accounting such as
> NAS management and local area network (LAN) usage.
>
> In order to enable interoperation of heterogeneous RADIUS/Diameter
> deployments, all RADEXT WG work items MUST contain a Diameter
> compatibility section, outlining how interoperability with Diameter
> will be maintained.
>
> Furthermore, to ensure backward compatibility with existing RADIUS
> implementations, as well as compatibility between RADIUS and Diameter,
> the following restrictions are imposed on extensions considered by the
> RADEXT WG:
>
> - All documents produced MUST specify means of interoperation with
> legacy RADIUS implementations and, if possible, be backward compatible
> with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579,
> 3580, 4668-4673,4675, 5080, 5090 and 5176.
> Transport profiles should, if possible, be compatible with RFC 3539.
I kind of find this formulation interesting. So implementations are actually more important then any of the specifications? So if I claim that I have a implementation which doesn't follow the specs for that they still can be used as an argument to affect the new extensions?
>
> - All RADIUS work MUST be compatible with equivalent facilities in
> Diameter. Where possible, new attributes should be defined so that
> the same attribute can be used in both RADIUS and Diameter without
> translation. In other cases a translation considerations
> section should be included in the specification.
>
>
> Work Items
>
> The immediate goals of the RADEXT working group are to address the
> following issues:
>
> - RADIUS design guidelines. This document will provide guidelines for
> design of RADIUS attributes. It will specifically consider how
> complex data types may be introduced in a robust manner, maintaining
> backwards compatibility with existing RADIUS RFCs, across all the
> classes of attributes: Standard, Vendor-Specific and SDO-Specific.
> In addition, it will review RADIUS data types and associated
> backwards compatibility issues.
>
> - RADIUS Management authorization. This document will define the
> use of RADIUS for NAS management over IP.
Please expand NAS.
>
> -RADIUS attribute space extension. The standard RADIUS attribute
> space is currently being depleted. This document will provide
> additional standard attribute space, while maintaining backward
> compatibility with existing attributes.
>
> -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
> relied on MD5 for both per-packet integrity and authentication as well
> as attribute confidentiality. Given the increasingly successful
> attacks being mounted against MD5, the ability to support
> alternative algorithms is required. This work item will
> include documentation of RADIUS crypto-agility requirements,
> as well as development of one or more Experimental RFCs providing
> support for negotiation of alternative cryptographic algorithms
> to protect RADIUS.
>
> - IEEE 802 attributes. New attributes have been proposed to
> support IEEE 802 standards for wired and wireless LANs. This
> work item will support authentication, authorization and
> accounting attributes needed by IEEE 802 groups including
> IEEE 802.1, IEEE 802.11 and IEEE 802.16.
>
> - New RADIUS transports. A reliable transport profile for
> RADIUS will be developed, as well as specifications for
> Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS.
>
I made a quick scan at RFC 2865. Are there any real definition of how
the UDP retransmission timers should look? In addition, is it congestion
problems or the message size that makes one go towards TCP? I wonder if
you need to have some clean up of the UDP based transport rules for
radius when you anyway are in the process?
> - Documentation of Status-Server usage. A document
> describing usage of the Status-Server facility will be
> developed.
>
> Goals and Milestones:
>
> Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice
> RFC
> Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed
> Standard RFC
> Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational
> RFC
> Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC
> Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
> Jan 2009 Reliable Transport Profile for RADIUS I-D submitted as a Proposed
> Standard RFC
> Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
> Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental
> RFC
> June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
> June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an
> Experimental RFC
>
>
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
F?r?gatan 6 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------