[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT WG re-charter
Some questions on the proposed charter:
>All RADIUS work MUST be backward compatible with existing
> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579,
> 3580, 4668-4673, 4675, 5080, 5090 and 5176.
What does it mean for a new transport to be backward compatible?
> - New RADIUS transports. New secure transports for RADIUS will
> be developed, including TCP/TLS (RADSEC) and UDP/DTLS.
What are we trying to gain by including new transports, especially TCP?
Is it just crypto agility or are there other goals as well? This seems
like a lot of work to gain crypto agility, it would be good to
understand what else we have to gain.
What is the intended status of this work? Experimental? Standards
track?
> -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.
>
Now that we have a separate item for secure transports shouldn't this
explicitly refer to attribute based encryption, message authentication
and key transport?
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Tuesday, April 01, 2008 12:41 PM
> To: radiusext@ops.ietf.org
> Subject: RADEXT WG re-charter
>
> As we discussed at IETF 71, the RADEXT WG is looking at a
> re-charter. A strawman re-charter proposal is enclosed below.
> Once comments from WG participants have been incorporated, we
> will begin a formal WG consensus call on the proposed
> re-charter by the end of the month.
>
> ==================================
>
> 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 secure 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 RADIUS work MUST be backward compatible with existing
> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579,
> 3580, 4668-4673, 4675, 5080, 5090 and 5176.
>
>
> - 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. New secure transports for RADIUS will
> be developed, 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 RC
> Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
> Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
> Mar 2009 RADSEC 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
>
>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>