Subject: Summary: Consensus call on RADEXT WG re-charter

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Apr 2008 15:03:19 -0700

The consensus call on the RADEXT WG re-charter ended on April 28.  After going over the RADEXT WG mailing list discussion,  I believe that WG consensus was achieved on the 
proposed charter, modified to take into account the proposed change to the 
backwards compatibility language proposed by Glen Zorn:
 
"- All documents produced MUST specify means of interoperation withlegacy 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."
 
Here is my summary of the opinions expressed on the list:
 In favor (6)Alan DeKok: http://ops.ietf.org/lists/radiusext/2008/msg00221.htmlStefan Winter: http://ops.ietf.org/lists/radiusext/2008/msg00232.htmlMauricio Sanchez: http://ops.ietf.org/lists/radiusext/2008/msg00248.htmlMudit Goel: http://ops.ietf.org/lists/radiusext/2008/msg00258.htmlMike McCauley: http://ops.ietf.org/lists/radiusext/2008/msg00234.htmlSteve Hanna: http://ops.ietf.org/lists/radiusext/2008/msg00206.html No explicit opinion expressed: (2)Avi Lior: http://ops.ietf.org/lists/radiusext/2008/msg00268.htmlMatt Holdredge: http://ops.ietf.org/lists/radiusext/2008/msg00240.htmlAgainst (2):Glen Zorn (many postings)Joe Salowey: http://ops.ietf.org/lists/radiusext/2008/msg00211.html  The full text of the modified charter is enclosed below: 
=======================================================
Description of Working Group:
The RADIUS Extensions Working Group will focus on extensions to theRADIUS protocol required to define extensions to the standardattribute space as well as to address cryptographic algorithmagility and use over new secure transports. In addition, RADEXT willwork 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/Diameterdeployments, all RADEXT WG work items MUST contain a Diametercompatibility section, outlining how interoperability withDiameter will be maintained.Furthermore, to ensure backward compatibility with existing RADIUSimplementations, as well as compatibility between RADIUS and Diameter,the following restrictions are imposed on extensions considered by theRADEXT WG:
 
- All documents produced MUST specify means of interoperation withlegacy 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.- All RADIUS work MUST be compatible with equivalent facilities inDiameter. Where possible, new attributes should be defined so thatthe same attribute can be used in both RADIUS and Diameter withouttranslation. In other cases a translation considerationssection should be included in the specification. Work ItemsThe immediate goals of the RADEXT working group are to address thefollowing issues:- RADIUS design guidelines. This document will provide guidelines fordesign of RADIUS attributes. It will specifically consider howcomplex data types may be introduced in a robust manner, maintainingbackwards compatibility with existing RADIUS RFCs, across all theclasses of attributes: Standard, Vendor-Specific and SDO-Specific.In addition, it will review RADIUS data types and associatedbackwards compatibility issues. - RADIUS Management authorization. This document will define theuse of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attributespace is currently being depleted. This document will provideadditional standard attribute space, while maintaining backwardcompatibility with existing attributes.-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as wellas attribute confidentiality. Given the increasingly successfulattacks being mounted against MD5, the ability to supportalternative algorithms is required. This work item willinclude documentation of RADIUS crypto-agility requirements,as well as development of one or more Experimental RFCs providingsupport for negotiation of alternative cryptographic algorithmsto protect RADIUS.- IEEE 802 attributes. New attributes have been proposed tosupport IEEE 802 standards for wired and wireless LANs. Thiswork item will support authentication, authorization andaccounting attributes needed by IEEE 802 groups includingIEEE 802.1, IEEE 802.11 and IEEE 802.16.- New RADIUS transports. New secure transports for RADIUS willbe developed, including TCP/TLS (RADSEC) and UDP/DTLS.- Documentation of Status-Server usage. A documentdescribing usage of the Status-Server facility will bedeveloped.Goals and Milestones:Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFCJun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standard RFCSep 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFCSep 2008 Extended Attributes I-D submitted as a Proposed Standard RFCDec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFCMar 2009 Status-Server I-D submitted as a Proposed Standard RFCMar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFCJune 2009 RADIUS over DTLS I-D submitted as an Experimental RFCJune 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC

---

From: Stefan Winter <[email-masked]>
Date: Wed, 30 Apr 2008 07:46:14 +0200

Hello,

one suggested correction: over the course of the discussion, it seemed
that splitting TCP transport into an own document was deemed worthwhile.

Such a document should be added to the milestones. Since the document
probably makes use of Status-Server, and the TCP+TLS work in turn uses
the TCP transport document, it should have an intermediate place in the
timeline. Like

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
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC

Mar 2009 Non-UDP Transport Considerations I-D submitted as Proposed
Standard(?) RFC

Apr 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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 30 Apr 2008 12:54:41 +0700

...

> one suggested correction: over the course of the discussion,
> it seemed that splitting TCP transport into an own document
> was deemed worthwhile.
> 
> Such a document should be added to the milestones. Since the
> document probably makes use of Status-Server, and the TCP+TLS
> work in turn uses the TCP transport document, it should have
> an intermediate place in the timeline. 

I agree.

...

---

From: "Matt Holdrege" <[email-masked]>
Date: Tue, 29 Apr 2008 23:00:39 -0700

...

>I agree.

Me 2.

-Matt

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 30 Apr 2008 14:33:16 +0200

Are there volunteers to write this document? 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Winter
> Sent: Wednesday, April 30, 2008 8:46 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: Summary: Consensus call on RADEXT WG re-charter
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> an intermediate place in the timeline. Like
> 
> 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 Mar 2009 Status-Server I-D submitted as 
> a Proposed Standard RFC
> 
> Apr 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
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.4-svn0 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
> 
> iD8DBQFIGAem+jm90f8eFWYRAj/cAJ4kNB2JNz9Z/A4ufpc/GOaW3kgIJACcDPwc
> uj+tmcB6Eminto3/2sjhDyw=
> =Xg8K
> -----END PGP SIGNATURE-----
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 30 Apr 2008 14:41:05 +0200

> Are there volunteers to write this document? 

  TCP transport?

  I volunteer.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Wed, 30 Apr 2008 14:46:49 +0200

Hi,

| Are there volunteers to write this document?

Parts of it are in the current RadSec I-D. I volunteer to continue
working on it when it's a standalone document.

Greetings,

Stefan Winter