[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT WG re-charter
Thanks for the detailed explanation.
With respect to the key transport item, I don't recall this discussion
on the HOKEY list. I might have missed it. In any case I don't think
this is the right approach. Key transport is a general problem that can
be solved with a general solution.
> > 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
> > 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: email@example.com
> >> [mailto:firstname.lastname@example.org] On Behalf Of Bernard Aboba
> >> Sent: Tuesday, April 01, 2008 12:41 PM
> >> To: email@example.com
> >> Subject: RADEXT WG re-charter
> >> As we discussed at IETF 71, the RADEXT WG is looking at a
> >> 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
> >> 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,
> >> 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
> >> attacks being mounted against MD5, the ability to support
> >> 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
> >> 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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.