[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RADEXT WG re-charter


> What does it mean for a new transport to be backward compatible?
I think it means that it is possible to write a transport proxy that goes to/from 
RADIUS as it exists today (e.g. over UDP) and encapsulates it to/from the
new transport, with minimal (ideally no) changes to the RADIUS packet.


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?


The contemplated work includes both DTLS/UDP and TLS/TCP
transports.   The arguments for the former relate primarily to
security;  the arguments for the later relate to both security
and transport considerations.   The benefits in both areas
have been laid out in presentations to the RADEXT WG
over the last year and a half.

Transport issues were examined in detail in the AAA WG,
which described AAA requirements (including transport) in
RFC 2989.   Reliable transport was chosen, as a result of
concerns over accounting reliability as well as experience
with the drawbacks of the undefined transport behavior
of RADIUS (discussed in RFC 5080 Section 2.2.1).

The behavior of AAA over reliable transport was analyzed in
RFC 3539, which also develops a transport profile and
suggests failover and load balancing algorithms.

Together, these documents provide a response to
RFC 2865 Section 2.4, which lays out four reasons why
RADIUS uses UDP:

  1. If the request to a primary Authentication server fails, a
     secondary server must be queried.
  2. The timing requirements of this particular protocol are
     significantly different than TCP provides.
  3. The stateless nature of this protocol simplifies the use of UDP.
  4. UDP simplifies the server implementation.

RFC 3539 provides  for failover and load balancing (1 & 2).
Since RADIUS was first standardized in the mid 1990s,
implementations have grown in sophistication and the
underlying hardware has increased by several orders of magnitude
in performance.   As a result, considerations 3 and 4 have lessened
in importance.


What is the intended status of this work?  Experimental? Standards
track?


The transport documents are slated for Experimental status
(as stated in the charter).


Now that we have a separate item for secure transports shouldn't this
explicitly refer to attribute based encryption, message authentication
and key transport?


The detailed requirements are going to be developed in a separate
document.  However, as discussed in the HOKEY WG meeting, the
focus of the RADEXT WG will be on providing a generic security
solution, including confidentiality, and message integrity/authentication.
As discussed in the HOKEY WG meeting, key management attributes
specific to ERX will be developed in HOKEY WG and will be independent
of the specific RADIUS crypto-agility mechanism.


-----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/>