Subject: WG Review: Recharter of RADIUS Extensions Working Group (radext)

From: IESG Secretary <[email-masked]>
Date: Tue, 13 May 2008 15:00:01 -0700 (PDT)

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 ([email-masked]) by May 20, 2008.

RADIUS Extensions Working Group (radext)
----------------------------------------
Last Modified: 2008-04-30

Current Status: Active Working Group

Chair(s):
*  Bernard Aboba <[email-masked]> 
*  David Nelson <[email-masked]> 

Operations and Management Area Director(s):
*  Dan Romascanu <[email-masked]> 
*  Ronald Bonica <[email-masked]> 

Operations and Management Area Advisor:
*  Dan Romascanu <[email-masked]> 

Technical Advisor(s):
*  Paul Congdon <[email-masked]> 

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
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

--
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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 14 May 2008 14:20:32 +0200

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of IESG Secretary
> Sent: Wednesday, May 14, 2008 1:00 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> 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 ([email-masked]) by May 20, 2008.
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 May 2008 14:58:43 +0200

> internal review as IETF review comments and address them. 
...
> > compatible with existing RADIUS RFCs, ...

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

  Maybe just "... interoperation with legacy RADIUS and, if possible..."

  i.e. delete "implementations".

> I made a quick scan at RFC 2865. Are there any real definition of how
> the UDP retransmission timers should look?

  RFC 5080 Section 2.2.1 defines these timers.

> In addition, is it congestion problems or the message size that makes
> one go towards TCP?

  I think that the main one is message size.  While there may not be a
need to increase the 4k maximum packet size for RADIUS, there are many
broken firewalls and routers out there.  UDP packets that are 4k in size
may be fragmented at the IP layer, and may not make it intact across the
network.  Using TCP for transport means that the RADIUS packets are
fragmented across multiple TCP packets, but that the IP packets are not
fragmented.

  In addition, TCP can have faster feedback than UDP when a connection
goes down.  This can help minimize delays on failover.

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

  Many transport rules for RADIUS were updated in RFC 5080.  I'm not
sure any more changes are required.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 14 May 2008 06:55:07 -0700

>> they still can be used as an argument to affect the new

Interestingly, one of your IESG colleagues recently used precisely that
argument to halt the progress of a draft from the hokey WG: that
non-standard EAP implementations would be unable to handle ERX &
therefore all sorts of limitations needed to be placed on the new
protocol.  I did ask why a purported SDO would care about broken
implementations of a standard protocol, but w/o AFAIK getting any
answer.  So, yes, there seems to be an (unfortunate IMHO) precedent for
this...

Delivery-date: Wed, 14 May 2008 13:59:26 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Alan DeKok'" <[email-masked]>, "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>
Subject: RE: WG Review: Recharter of RADIUS Extensions Working Group (radext)
Date: Wed, 14 May 2008 06:55:07 -0700

>> they still can be used as an argument to affect the new

Interestingly, one of your IESG colleagues recently used precisely that
argument to halt the progress of a draft from the hokey WG: that
non-standard EAP implementations would be unable to handle ERX &
therefore all sorts of limitations needed to be placed on the new
protocol.  I did ask why a purported SDO would care about broken
implementations of a standard protocol, but w/o AFAIK getting any
answer.  So, yes, there seems to be an (unfortunate IMHO) precedent for
this...

Delivery-date: Wed, 14 May 2008 13:05:19 +0000
Date: Wed, 14 May 2008 14:58:43 +0200
From: Alan DeKok <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: Re: WG Review: Recharter of RADIUS Extensions Working Group (radext)

...

  Alan DeKok.

Delivery-date: Wed, 14 May 2008 12:22:45 +0000
Content-class: urn:content-classes:message
Subject: RE: WG Review: Recharter of RADIUS Extensions Working Group (radext) 
Date: Wed, 14 May 2008 14:20:32 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8B5BC.E834039F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I suggest to consider the comments from Magnus during the IESG/IAB
internal review as IETF review comments and address them.=20

Dan

 =20

> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of IESG Secretary
> Cc: [email-masked]; [email-masked];=20
> [email-masked]
> Subject: WG Review: Recharter of RADIUS Extensions Working=20
> Group (radext)=20
>=20
> A modified charter has been submitted for the RADIUS=20
> Extensions Working Group in the Operations and Management=20
> Area of the IETF.  The IESG has not made any determination as=20
> yet.  The modified charter is provided below for=20
> informational purposes only.  Please send your comments to=20
>=20
>=20
>=20
>=20
> *  David Nelson <[email-masked]>=20
>=20
>=20
> *  Dan Romascanu <[email-masked]>=20
> *  Ronald Bonica <[email-masked]>=20
>=20
>=20
> *  Dan Romascanu <[email-masked]>=20
>=20
>=20
> Technical Advisor(s):
> *  Paul Congdon <[email-masked]>=20
>=20
>=20
> Mailing Lists:
>=20
>=20
> Description of Working Group:=20
>=20
> work on RADIUS Design Guidelines and define new attributes for=20
> particular applications of authentication, authorization and=20
> accounting such as NAS management and local area network (LAN) usage.=20
>=20
>=20
>=20
> legacy RADIUS implementations and, if possible, be backward=20
> compatible with existing RADIUS RFCs, including RFCs 2865-2869,=20
> Transport profiles should, if possible, be compatible with RFC 3539.=20
>=20
>=20
>=20
>=20
>=20
>=20
> use of RADIUS for NAS management over IP.=20
>=20
>=20
> -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally=20
>=20
>=20
> RADIUS will be developed, as well as specifications for=20
>=20
>=20
>=20
> Sep 2008 RADIUS Crypto-agility Requirements submitted as an=20
> Informational
> RFC
> Jan 2009 Reliable Transport Profile for RADIUS I-D submitted=20
> as a Proposed
> Standard RFC
> Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an=20
> Experimental
> RFC
>=20

------_=_NextPart_001_01C8B5BC.E834039F
Content-Type: text/plain;
	name="Re Internal WG Review Recharter of RADIUS Extensions Working Group(radext).txt"
Content-Transfer-Encoding: base64
Content-Description: Re Internal WG Review Recharter of RADIUS Extensions Working Group(radext).txt
Content-Disposition: attachment;
	filename="Re Internal WG Review Recharter of RADIUS Extensions Working Group(radext).txt"

------_=_NextPart_001_01C8B5BC.E834039F--

Delivery-date: Wed, 14 May 2008 11:57:16 +0000
Content-class: urn:content-classes:message
Subject: FW: WG Review: Recharter of RADIUS Extensions Working Group (radext) 
Date: Wed, 14 May 2008 13:54:38 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Wednesday, May 14, 2008 1:00 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: WG Review: Recharter of RADIUS Extensions Working Group
(radext)=20

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 ([email-masked]) by May 20, 2008.

Chair(s):
*  Bernard Aboba <[email-masked]>
*  David Nelson <[email-masked]>=20

Operations and Management Area Director(s):
*  Dan Romascanu <[email-masked]>=20
*  Ronald Bonica <[email-masked]>=20

Operations and Management Area Advisor:
*  Dan Romascanu <[email-masked]>=20

Technical Advisor(s):
*  Paul Congdon <[email-masked]>=20

Mailing Lists:

Description of Working Group:=20

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=20
particular applications of authentication, authorization and=20
accounting such as NAS management and local area network (LAN) usage.=20

- All documents produced MUST specify means of interoperation with
legacy RADIUS implementations and, if possible, be backward=20
compatible with existing RADIUS RFCs, including RFCs 2865-2869,=20
3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176.
Transport profiles should, if possible, be compatible with RFC 3539.=20

Work Items

- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.=20

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally=20

- New RADIUS transports. A reliable transport profile for
RADIUS will be developed, as well as specifications for=20
Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS.

Goals and Milestones:

Sep 2008 RADIUS Crypto-agility Requirements submitted as an
Informational
Jan 2009 Reliable Transport Profile for RADIUS I-D submitted as a
Proposed

Delivery-date: Tue, 13 May 2008 22:02:22 +0000
From: IESG Secretary <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: WG Review: Recharter of RADIUS Extensions Working Group (radext) 
reply-to: [email-masked]
Date: Tue, 13 May 2008 15:00:01 -0700 (PDT)

Chair(s):

Technical Advisor(s):

Mailing Lists:

Work Items

Goals and Milestones:

Delivery-date: Thu, 08 May 2008 18:21:45 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D Action:draft-ietf-radext-crypto-agility-requirements-00.txt 
Date: Thu, 8 May 2008 14:20:31 -0400
Organization: Elbrys Networks, Inc.

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the RADIUS EXTensions 
> Working Group of the IETF.
>
> 	Title           : Crypto-Agility Requirements for Remote Dial-In
> User Service (RADIUS)
> 	Author(s)       : D. Nelson
> 	Filename        : draft-ietf-radext-crypto-agility-requirements-
> 00.txt
> 	Pages           : 8
> 	Date            : 2008-05-08

This draft contains fixes for a number of typos (spelling) and an
acknowledgement that the RADEXT Charter is in the process of revision.
Otherwise, there are no changes from the individual draft we reviewed during
IETF-71.

During the debate on the re-chartering, we discussed issues that have a
direct impact on this document, with regard to key-wrap attributes.  I will
point out that the current RADEXT crypto-agility requirements draft says
nothing about using NIST approved algorithms, nor anything about special
algorithms and modes for key-wrap, as distinct from general purpose
encryption.  If the consensus of the WG is that these items ought to be part
of the requirements, we should propose some added text.

Further thoughts?

Delivery-date: Thu, 08 May 2008 17:47:28 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-00.txt 
Date: Thu,  8 May 2008 10:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)
	Author(s)       : D. Nelson
	Filename        : draft-ietf-radext-crypto-agility-requirements-00.txt
	Pages           : 8
	Date            : 2008-05-08

This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-crypto-agility-requirements-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Thu, 08 May 2008 01:57:27 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RE: Consensus call:  Changes to Extended Attributes document
Date: Wed, 7 May 2008 18:56:21 -0700

--_b974a386-fc09-4f65-98f7-b69e1b8a5413_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

FWIW, I agree with the RADEXT WG consensus call results at IETF 71:
=20
1. ADOPT the change from 1 octet to 2 for the Ext-Type field.=20
2. REJECT support for standard RADIUS attributes within the Extended Attrib=
utes format.=20

From: [email-masked]: [email-masked]: Consensus=
 call: Changes to Extended Attributes documentDate: Wed, 7 May 2008 18:48:0=
5 -0700

At IETF 71, a consensus call was taken regarding changes made in the -01 ve=
rsion of theExtended Attributes document, as compared with -00.   The chang=
es made were as follows:1. Ext-Type field was changed to 2 octets rather th=
an 1. 2. The RADIUS Extended Attribute format in -01 applied to existing st=
andard RADIUS attributes,  not just extended ones. In the RADEXT WG meeting=
 at IETF 71, the consensus call was as follows: Change #1 was ADOPTED by a =
margin of 7-1. Change #2 was REJECTED by a margin of 6-2.  We are now issui=
ng a Consensus Call on the RADEXT WG mailing list in order to verify the co=
nsensus of the room at IETF 71.  This Consensus Call will last until  May 2=
1, 2008.  Please send email to the list, explicitly stating your position o=
n changes #1 and #2, indicating whether you desire to ADOPT or REJECT each =
change.  For reference, -00 is available here:http://www.watersprings.org/p=
ub/id/draft-ietf-radext-extended-attributes-00.txt -01 is available here:ht=
tp://www.waterspring.org/pub/id/draft-ietf-radext-extended-attributes-01.tx=
t   =

--_b974a386-fc09-4f65-98f7-b69e1b8a5413_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
FWIW, I agree with the RADEXT WG consensus call results at IETF 71:<BR>
&nbsp;<BR>
1. ADOPT the change from 1 octet to 2 for the Ext-Type field. <BR>
2. REJECT support for standard RADIUS attributes within the Extended Attrib=
utes format. <BR><BR><BR>
<BLOCKQUOTE>
<HR>
From: [email-masked]<BR>To: [email-masked]<BR>Subject: C=
onsensus call: Changes to Extended Attributes document<BR>Date: Wed, 7 May =
2008 18:48:05 -0700<BR><BR>
<META content=3D"Microsoft SafeHTML" name=3DGenerator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
At IETF 71, a consensus call was taken regarding changes made in the -01 ve=
rsion of the<BR>Extended Attributes document, as compared with -00.&nbsp; <=
BR>&nbsp;<BR>The changes made were as follows:<BR>1. Ext-Type field was cha=
nged to 2 octets rather than 1. <BR>2. The RADIUS Extended Attribute format=
 in -01 applied to existing standard RADIUS attributes, &nbsp;not just exte=
nded ones.<BR>&nbsp;<BR>In the RADEXT WG meeting at IETF 71, the consensus =
call was as follows:<BR>&nbsp;<BR>Change #1 was ADOPTED by a margin of 7-1.=
 <BR>Change #2 was REJECTED by a margin of 6-2. <BR>&nbsp;<BR>We are now is=
suing a Consensus Call on the RADEXT WG mailing list in order to verify the=
 consensus of the room at IETF 71. <BR>&nbsp;<BR>This Consensus Call will l=
ast until&nbsp; May 21, 2008.&nbsp; Please send email to the list, explicit=
ly stating your position on changes #1 and #2, indicating whether you desir=
e to ADOPT or REJECT each change. <BR>&nbsp;<BR>For reference, -00 is avail=
able here:<BR><A href=3D"http://www.watersprings.org/pub/id/draft-ietf-rade=
xt-extended-attributes-00.txt" target=3D_blank>http://www.watersprings.org/=
pub/id/draft-ietf-radext-extended-attributes-00.txt</A><BR>&nbsp;<BR>-01 is=
 available here:<BR><A href=3D"http://www.waterspring.org/pub/id/draft-ietf=
-radext-extended-attributes-01.txt" target=3D_blank>http://www.waterspring.=
org/pub/id/draft-ietf-radext-extended-attributes-01.txt</A><BR><BR>&nbsp;<B=
R>&nbsp;<BR>&nbsp;<BR></BLOCKQUOTE></body>
</html>=

--_b974a386-fc09-4f65-98f7-b69e1b8a5413_--

Delivery-date: Thu, 08 May 2008 01:50:31 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Consensus call:  Changes to Extended Attributes document
Date: Wed, 7 May 2008 18:48:05 -0700

--_454428cf-93cc-4ca2-8843-32dccfa224ad_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At IETF 71, a consensus call was taken regarding changes made in the -01 ve=
rsion of the
Extended Attributes document, as compared with -00. =20
=20
The changes made were as follows:
1. Ext-Type field was changed to 2 octets rather than 1. 2. The RADIUS Exte=
nded Attribute format in -01 applied to existing standard RADIUS attributes=
,  not just extended ones.
=20
In the RADEXT WG meeting at IETF 71, the consensus call was as follows:
=20
Change #1 was ADOPTED by a margin of 7-1.=20
Change #2 was REJECTED by a margin of 6-2.=20
=20
We are now issuing a Consensus Call on the RADEXT WG mailing list in order =
to verify the consensus of the room at IETF 71.=20
=20
This Consensus Call will last until  May 21, 2008.  Please send email to th=
e list, explicitly stating your position on changes #1 and #2, indicating w=
hether you desire to ADOPT or REJECT each change.=20
=20
For reference, -00 is available here:
http://www.watersprings.org/pub/id/draft-ietf-radext-extended-attributes-00=
.txt
=20
-01 is available here:
http://www.waterspring.org/pub/id/draft-ietf-radext-extended-attributes-01.=
txt
=20
=20
 =

--_454428cf-93cc-4ca2-8843-32dccfa224ad_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
At IETF 71, a consensus call was taken regarding changes made in the -01 ve=
rsion of the<BR>
Extended Attributes document, as compared with -00.&nbsp; <BR>
&nbsp;<BR>
The changes made were as follows:<BR>
1. Ext-Type field was changed to 2 octets rather than 1. <BR>2. The RADIUS =
Extended Attribute format in -01 applied to existing standard RADIUS attrib=
utes, &nbsp;not just extended ones.<BR>
&nbsp;<BR>
In the RADEXT WG meeting at IETF 71, the consensus call was as follows:<BR>
&nbsp;<BR>
Change #1 was ADOPTED by a margin of 7-1. <BR>
Change #2 was REJECTED by a margin of 6-2. <BR>
&nbsp;<BR>
We are now issuing a Consensus Call on the RADEXT WG mailing list in order =
to verify the consensus of the room at IETF 71. <BR>
&nbsp;<BR>
This Consensus Call will last until&nbsp; May 21, 2008.&nbsp; Please send e=
mail to the list, explicitly stating your position on changes #1 and #2, in=
dicating whether you desire to ADOPT or REJECT each change. <BR>
&nbsp;<BR>
For reference, -00 is available here:<BR>
<A href=3D"http://www.watersprings.org/pub/id/draft-ietf-radext-extended-at=
tributes-00.txt">http://www.watersprings.org/pub/id/draft-ietf-radext-exten=
ded-attributes-00.txt</A><BR>
&nbsp;<BR>
-01 is available here:<BR>
<A href=3D"http://www.waterspring.org/pub/id/draft-ietf-radext-extended-att=
ributes-01.txt">http://www.waterspring.org/pub/id/draft-ietf-radext-extende=
d-attributes-01.txt</A><BR>
<BR>&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR></body>
</html>=

--_454428cf-93cc-4ca2-8843-32dccfa224ad_--

Delivery-date: Wed, 07 May 2008 15:54:50 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Consensus Call Summary: Adoption of Crypto-Agility Requirements Document as a RADEXT WG Work Item
Date: Wed, 7 May 2008 08:52:57 -0700

--_12f2c3d4-c9fc-4959-85cf-108f299af2c7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At IETF 71, we had a consensus call on adoption of the Crypto-Agility Requi=
rements Document as a RADEXT WG work item.  Since there was consensus in th=
e room for adoption, we followed up on the mailing list with a RADEXT WG co=
nsensus call which completed on May 6.=20

Based on the mailing list responses (which consisted entirely of favorable =
responses), our determination is that consensus exists for adoption of the =
document as a WG work item.=20

--_12f2c3d4-c9fc-4959-85cf-108f299af2c7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
At IETF 71, we had a consensus call on adoption of the Crypto-Agility Requi=
rements Document as a RADEXT WG work item.&nbsp; Since there was consensus =
in the room for adoption, we followed up on the mailing list with a RADEXT =
WG consensus call which completed on May 6. <br><br>Based on the mailing li=
st responses (which consisted entirely of favorable responses), our determi=
nation is that consensus exists for adoption of the document as a WG work i=
tem. <br></body>
</html>=

--_12f2c3d4-c9fc-4959-85cf-108f299af2c7_--

Delivery-date: Wed, 07 May 2008 03:57:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Consensus call:  Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item
Date: Tue, 6 May 2008 20:56:20 -0700
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

I think the document provides a good basis for crypto-agility
requirements for RADIUS and should be adopted as a working group item. =20
=20

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Sunday, April 20, 2008 3:55 PM
> To: [email-masked]
> Subject: Consensus call: Adoption of RADIUS Crypto-Agility=20
> Requirements document as a RADEXT WG work item
>=20
> At IETF 71, we discussed adopting the document=20
> "Crypto-Agility Requirements for Remote Dial-In User Service=20
> (RADIUS)"=20
> as a RADEXT WG work item.  In the room, the vote was 11-0 in=20
> favor of this.=20
> =20
> We are now following up with a mailing list consensus call. =20
> The document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-nelson-radext-crypto
> -agility-requirements-00.txt
> =20
> Please post to the mailing list providing your opinion on=20
> whether this document should be adopted as a working group work item.=20
> =20
> The Consensus call will last until May 6, 2008.=20
>=20

Delivery-date: Tue, 06 May 2008 19:33:25 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [Geopriv] Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diame
Date: Tue, 6 May 2008 12:31:46 -0700

--_cdd54010-9c24-489d-8214-d4773a5f8fef_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Glen Zorn said:
"This "all a matter of implementation" stuff is just a cop-out: thisdocumen=
t needs to clearly specify all the entities involved, howeverskeletal that =
specification may be: if the RADIUS server gets thelocation information fro=
m another server which subsequently validatesthe response, that's fine.  If=
 the RADIUS server does it, that's fine; Idon't really care but 'fuzziness'=
 has no place in standards, IMHO."
=20
[BA] I would agree.  My assumption had been that theRADIUS server was merel=
y looking for the presence/absence ofattributes and writing location data t=
o a backend store,so that it was not required to be "location aware".
=20
However, you have pointed out statements in the document whichappear to imp=
ly something more than this - such as the abilityof a RADIUS server to pars=
e and understand location data.
  Given that two readers have come to such widely differing interpretations
of the same text, I'd suggest that these ambiguities need to be cleared up.=
=20
=20
Glen Zorn also said this:
"As I understand the development cycle of an Internet-Draft, there's nosuch=
 thing as 'too late to make a change'.  The following text appearsin every =
single I-D published:  "Internet-Drafts are draft documentsvalid for a maxi=
mum of six months and may be updated, replaced, orobsoleted by other docume=
nts at any time."  Seems pretty clear to me.I'm sure that someone will ment=
ion at this point that 3GPP87 or somesuch has already implemented this draf=
t; fortunately, this is prettymuch taken care of by the next sentence (that=
 also appears in everysingle I-D): "It is inappropriate to use Internet-Dra=
fts as referencematerial or to cite them other than as "work in progress."
=20
[BA] In this particular case there is ambiguity, so that it is notclear wha=
t the current document is actually requiring.  Assumingthat is cleared up, =
we can then address the issue of what changesare needed.  I don't believe t=
here is any "statute of limitations"on addressing ambiguities.
=20
Furthermore, Glen Zorn said this:
"So are you saying that good design practices aren't good designpractices u=
ntil they have an RFC number?"=20
=20
[BA] Since this document was developed alongside the Design Guidelinesdocum=
ent, and the Guidelines were developed in part in response toissues raised =
by this document, it is hard to argue that it shouldbe exempt, regardless o=
f the state of the Design Guidelines document.=

--_cdd54010-9c24-489d-8214-d4773a5f8fef_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
Glen Zorn said:<BR>
"This "all a matter of implementation" stuff is just a cop-out: this<BR>doc=
ument needs to clearly specify all the entities involved, however<BR>skelet=
al that specification may be: if the RADIUS server gets the<BR>location inf=
ormation from another server which subsequently validates<BR>the response, =
that's fine.&nbsp; If the RADIUS server does it, that's fine; I<BR>don't re=
ally care but 'fuzziness' has no place in standards, IMHO."<BR>
&nbsp;<BR>
[BA] I would agree.&nbsp; My assumption had been that the<BR>RADIUS server =
was merely looking for the presence/absence of<BR>attributes and writing lo=
cation data to a backend store,<BR>so that it was not required to be "locat=
ion aware".<BR>
&nbsp;<BR>
However, you have pointed out statements in the document which<BR>appear to=
 imply something more than this - such as the ability<BR>of a RADIUS server=
 to parse and understand location data.<BR>
&nbsp; <BR>Given that two readers have come to such widely differing interp=
retations<BR>
of the same text, I'd suggest that these ambiguities need to be cleared up.=
 <BR>
&nbsp;<BR>
Glen Zorn also said this:<BR>
"As I understand the development cycle of an Internet-Draft, there's no<BR>=
such thing as 'too late to make a change'.&nbsp; The following text appears=
<BR>in every single I-D published:&nbsp; "Internet-Drafts are draft documen=
ts<BR>valid for a maximum of six months and may be updated, replaced, or<BR=
>obsoleted by other documents at any time."&nbsp; Seems pretty clear to me.=
<BR>I'm sure that someone will mention at this point that 3GPP87 or some<BR=
>such has already implemented this draft; fortunately, this is pretty<BR>mu=
ch taken care of by the next sentence (that also appears in every<BR>single=
 I-D): "It is inappropriate to use Internet-Drafts as reference<BR>material=
 or to cite them other than as "work in progress."<BR>
&nbsp;<BR>
[BA] In this particular case there is ambiguity, so that it is not<BR>clear=
 what the current document is actually requiring.&nbsp; Assuming<BR>that is=
 cleared up, we can then address the issue of what changes<BR>are needed.&n=
bsp; I don't believe there is any "statute of limitations"<BR>on addressing=
 ambiguities.<BR>
&nbsp;<BR>
Furthermore, Glen Zorn said this:<BR>
"So are you saying that good design practices aren't good design<BR>practic=
es until they have an RFC number?" <BR>
&nbsp;<BR>
[BA] Since this document was developed alongside the Design Guidelines<BR>d=
ocument, and the Guidelines were developed in part in response to<BR>issues=
 raised by this document, it is hard to argue that it should<BR>be exempt, =
regardless of the state of the Design Guidelines document.<BR></body>
</html>=

--_cdd54010-9c24-489d-8214-d4773a5f8fef_--

Delivery-date: Tue, 06 May 2008 13:50:50 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Glen Zorn'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Geopriv] Last Call: draft-ietf-geopriv-radius-lo(CarryingLocation Objects in RADIUS and Diameter) to Pr
Date: Tue, 6 May 2008 09:48:46 -0400

Glen Zorn writes...

> There's just one big difference: EAP is, in fact, a separate protocol,
> distinct from RADIUS.

We're talking about EAP messages tunneled in RADIUS Attributes.  That's what
qualifies for the "opaque blob" exception.

> We're talking about RADIUS attributes here, and the document states that
> the RADIUS server bases a decision upon these attributes.

Yes, I tend to agree with you.  The consensus position, as I understand it,
is that these are "semi-opaque blobs" because the contents are derived from
a separate protocol (a DHCP option, I think, but I may be mistaken).

> There isn't anything I can find in the draft that even suggests the
> existence of some "plug-in".

Nor would I expect you to.  That would be one of those infamous
"implementation specific details".

> Very little about the operation of a RADIUS server has to do with the
> on-the-wire protocol.

Eh?

> This "all a matter of implementation" stuff is just a cop-out: this
> document needs to clearly specify all the entities involved, however
> skeletal that specification may be: if the RADIUS server gets the
> location information from another server which subsequently validates
> the response, that's fine.  If the RADIUS server does it, that's fine; I
> don't really care but 'fuzziness' has no place in standards, IMHO.

The "fuzziness" I was talking about was the applicability of the "opaque
blob" exception in the RADIUS Attribute Design Guidelines. It is claimed to
apply in this case, and I, like you, don't quite buy it.  However, the
consensus position of the GEOPRIV and RADEXT WGs (from WGLC) is that it does
apply.

> So are you saying that good design practices aren't good design
> practices until they have an RFC number?

No.  I'm simply saying that two dissenting opinions do not a rough consensus
break.  :-)